URLデコード

ツールには決められないあいまいさ

デコードの仕組みは単純です。% の後に16進数が2桁続く箇所を探してバイトに戻し、そのバイト列をUTF-8として読むだけです。本当の意味であいまいな点はただ1つ。プラス記号はスペースを意味することも、プラスそのものを意味することもあります。送信されたフォームでは、Web自体のURL仕様より古い慣習によってスペースを意味します。パスの一部では文字どおりの記号です。テキスト自体にはどちらなのかが書かれていないため、このページは片方を選んで気付かれないまま間違えるのではなく、両方の読み方を表示します。これが最も効いてくるのは、プラスが本物のデータであるメールアドレスやBase64の値の場合です。

ASCII以外のテキストは、1文字あたり複数のパーセント表記になります。エンコードは文字単位ではなくUTF-8のバイト単位で行われるからです。アクセント付きの文字は2つ、ほとんどの記号は3つ、絵文字は4つになります。有効なUTF-8ではない並びをデコードすると置換文字になります。これはたいてい、テキストが別の文字コードでエンコードされたか、文字の途中で切れてしまったことを示しています。

二重デコードは単なるミスではなく、セキュリティ上のバグです。値をデコードしてチェックし、その後もう一度デコードすると、攻撃者はチェックから文字を隠せてしまいます。%252e%252e%252f は「../」を探すフィルターを通過します。1回デコードした時点ではまだ %2e%2e%2f だからです。そして2回目のデコードで、フィルターが防ぐはずだったディレクトリトラバーサルになります。デコードはちょうど1回だけ行い、その後に検証してください。順番を逆にしてはいけません。

エンコードされていないテキストは崩れることなくそのまま返されます。文字列にデコードが必要かどうか分からないときに便利な動作です。後ろに16進数が2桁続かないパーセント記号は、エラーとして扱わずにそのまま残します。それは文字どおりのパーセント記号で、エンコードされたのではなく貼り付けられたテキストによく見られます。

ほかの目的には

コードでは、デコーダーをエンコーダーに合わせるべきです。JavaScriptには decodeURIComponent があり、Pythonはまさにプラス記号の問題のために unquote と unquote_plus を分けています。PHPに rawurldecode と urldecode があるのも同じ理由です。さらに良いのは、URL型やクエリ文字列パーサーに任せることです。ほとんどのフレームワークはパラメーターをデコードしてくれるので、その後にもう一度デコードすると、上で説明した二重デコードのバグが生まれます。

値をデコードするのではなく長いURLを調べたいなら、デコーダーよりパーサーが向いています。python -c "import urllib.parse,sys; print(urllib.parse.urlparse(sys.argv[1]))" はアドレスを部分ごとに分解するので、何もデコードする前にどの部分が何なのかを確認できます。リンクがおかしな動作をするとき、本当に知りたいのはたいていそこです。