引き続き、体系的に学ぶ 安全なWebアプリケーションの作り方を読んだので、覚えたい部分を記事にしていく。
リダイレクト処理
オープンリダイレクト
パラメータにより指定したURLにリダイレクトできる機能を備えるものがあり、任意のドメインにリダイレクトできる脆弱性のことを、オープンリダイレクト脆弱性と呼ぶ。
オープンリダイレクト脆弱性の原因は、
- リダイレクト先のURLを外部から指定できる
- リダイレクト先のドメインのチェックができない
上記二点に当てはまること。
ただ、もともと外部のドメインに遷移する仕様や、外部ドメインに遷移することが自明である場合は、脆弱性ではない。
対策は、
- リダイレクト先のURLを固定にする
- リダイレクト先のURLを直接指定せずに番号指定にする
- リダイレクト先のドメイン名をチェックする
HTTPヘッダインジェクション
リダイレクトやクッキー発行など、外部からのパラメータをもとにHTTPレスポンスヘッダを出力する際に発生する脆弱性。
脆弱性の原因は、HTTPレスポンスヘッダはテキスト形式で1行に1つのヘッダが定義できる。
つまり、ヘッダとヘッダは改行で区切られることになる。
この性質を悪用することで、ヘッダを誤認させること。
対策は、
- 外部からパラメータをHTTPレスポンスヘッダとして出力しない
- リダイレクトやクッキー生成をAPIに任せる。かつ、ヘッダ生成するパラメータの改行文字をチェックする
クッキー
クッキーの不適切な利用
クッキーはセッション変数と違い、利用者が値を変更することができる。
なので、保存すべきでない情報（書き換えられると困る情報）を保存することにより脆弱性が生じる。
クッキーのセキュア属性不備
クッキーにはSecure属性があり、これを指定するとHTTPSの場合のみブラウザからサーバーに送信される。
この属性を指定していない場合は、HTTPS通信を利用していても、平文で送信されることがある。
原因としては、
- 開発者がセキュア属性について知らない
- セキュア属性をつけるとアプリケーションが動作しない
対策は、クッキーにセキュア属性をつけること。
メール送信
メールヘッダ・インジェクション
宛先や件名などのメールヘッダを外部から指定する際、改行文字を使ってメールヘッダや本文を追加・変更することで生じる脆弱性。
原因は、以下の通り。
ヘッダの各フィールドは改行で区切られている。
そのため、アプリケーションが改行をチェックしていない場合に、ヘッダや本文を追加・変更できることになる。
対策は、メール送信には専用ライブラリを使用する
プラスで、
- 外部からのパラメータをメールヘッダに含ませないようにする
- 外部からのパラメータには開業を含まないようにメール送信時にチェックする
ファイルアクセス
ディレクトリ・トラバーサル
ファイル名に対するチェックが不十分であると、アプリケーションの意図しないファイルに対して、閲覧や改ざん等ができる脆弱性。
原因は
- ファイル名を外部から指定することができる
- ファイル名として、絶対パスや相対パスの形で異なるディレクトリを指定できる
- 組み立てたファイル名に対するアクセスの可否をチェックしていない
対策は、
- 外部からファイル名を指定できる仕様を避ける
- ファイル名にディレクトリ名が含まれないようにする
- ファイル名を英数字に限定する
意図しないファイルの公開
原因は、
- ファイルが公開ディレクトリに置かれている
- ファイルに対するURLを知る手段がある
- ファイルに対するアクセス制限がかかってない
対策は
- アプリケーション設計時に、ファイルの安全な格納場所を決める
- レンタルサーバを契約する場合は、非公開ディレクトリが利用できることを確認する