リダイレクト処理にまつわる脆弱性
書籍を読んで
こちらの書籍を読んでWebアプリケーションを作る際に重要な要点を自分用としてアウトプットします。
リダイレクト処理にまつわる脆弱性
Webアプリケーションには、外部から指定したURLにリダイレクトするものがある
典型的には、ログインページのパラメータにURLを指定しておき、ログイン成功後にそのURLにリダイレクトするサイトです。
代表的なリダイレクト処理に際して発生する脆弱性
オープンリダレクト脆弱性
脆弱性が生まれる原因
- リダイレクト先のURLを外部から指定できる
- リダイレクト先のドメイン名のチェックがない
これらは両方があてはまる場合のみオープンリダレクト脆弱性となるので、どちらか一方の条件を当てはまらないようにすれば脆弱性はなくなる
対策
- リダレクト先のURLを固定にする
- 外部から指定するのではなく、固定のURLに遷移させる
- リダレクト先のURLを直接指定せず番号指定にする
- ページ番号の形で指定する
- ページ番号とURLの対応表は、外部から見えないスクリプトソースやファイル、データベースなどで管理する
- リダレクト先のドメイン名をチェックする
- 番号指定出来ない場合は任意ドメインへの遷移を防止する
- このチェックは落とし穴が多いので、上記2点での方法による実装が推奨
HTTPヘッダ・インジェクション
脆弱性が生まれる原因
- HTTPレスポンスヘッダはテキスト形式で1行に1つのヘッダが定義出来る。
- すなわち、ヘッダとヘッダは改行で区切られる事になる。
この性質を悪用して、リダレクト先URLやクッキー値として設定されるパラメータ中に改行を挿入した場合に、改行がそのままレスポンスとして出力されることが、HTTPヘッダ・インジェクション脆弱性の原因となる
対策
もっとも確実な対策
外部からのパラメータをHTTPレスポンスヘッダとして出力しない
以下の方針に従ってリダイレクトとクッキー生成を行う
- リダイレクト先をURLとして直接指定するのではなく、固定にするか番号などで指定する
- Webアプリケーション開発ツールの提供するセッション変数を使ってURLを受け渡す
設計段階から、外部からのパラメータをHTTPレスポンスヘッダとして出力しないことを検討する必要がある
どうしても外部からのパラメータをHTTPレスポンスヘッダとして出力しなければならない場合
- リダイレクトやクッキー生成を専用APIに任せる
- ヘッダ生成するパラメータの改行文字をチェックする
①はPHPなどのライブラリの機能を利用する
①だけでは完全には対策しきれないので、②を自衛としてアプリケーション側で対処する必要がある
- URL中の改行はエラーとする
- クッキー値の改行はパーセントエンコードする
ライブラリでクッキー値がエンコードされる場合もあるので、エンコードされるかどうかを開発前に調査する必要がある。
