2017-03-12
ディレクトリトラバーサルについて考える
今更ですが、ある案件で認証はあるもののファイルのアップロード作成があったので、改めて考えてみる。「ディレクトリトラバーサル」
HTTPのリクエストURIで../../etc/xxx等としてもこれはHTTPサーバーが400のBad Requestを返却する。RFC2616でリクエストURIは絶対パスと定義されているので、相対パスを指定した事で400のエラーステータスになる。
これをブラウザで試すと、ブラウザはHTTPのリクエストURIは、絶対パスでなければならないことをわかって作られているので、絶対パスに置き換えられてHTTPサーバーにリクエストを行うので、絶対パスが一致すれば200で応答し、一致しなければ404で応答が変えることになる。
ですので、通常はあまり意識することはないと思います。
しかし、ファイルのアップロード或いは引数からのファイルオープンの場合は、十分注意しなければならない。
ファイルのアップロードの場合は、おそらく配置するトップディレクトリーは決めているでしょうから、相対パス指定の../は絶対パスに置き換える（正規化）という操作は絶対に必要になる。
或いは、仕様で相対パスを許可しないようにして ../が見つかったらエラーとする。そして、このパスをアップロード先として決めてあるディレクトリーから構築する。
UPLOAD_DIR + 正規化されたパス
ディレクトリトラバーサルとは関係ないが、会員しかアクセスできないWEB公開ディレクトリーだったとしても、HTTPクライアントから送られてきたファイル名を無条件でそのまま使う事はあってはならない。例えば、PHPスクリプトが実行できる環境でxxx.phpというファイルをそのまま公開ディレクトリーに置いたら、xxx.phpが実行できることになり、間違いなくそのサイトは踏み台サイトとして利用されることになるでしょう。
また、引数のチェックはからなず、URLデコードした後に処理しないと../を見過ごすことになる。
URLデコードのタイミングやWEBで利用している言語仕様に依存することになるが、例えばPHPの場合に、引数を$_GETや$_POSTから参照する場合は、URLデコードされた値が入っているが、
$_SERVER['REQUEST_URI']から直接引数を取得するような処理がある場合、この値はURLデコードはされていないソースがそのままセットされていることを考慮しなければならない。
ディレクトリトラバーサルについてはいろいろなサイトで仕組みや危険性、対策方法を挙げているので、今更という感じもしますが、どんな場合も、サイトに送られてくるデータの解析と処理には作成言語の仕様をよく理解して処理しなければならないという事が疎かなっている傾向があるように思い、もう一度基本に戻って考えてみました。