IPAの「安全なウェブサイトの作り方」を読み進める第6回！
※この記事は上記の文書を個人的にまとめた防備録となるので注意。
この文書の目次は以下。
1) SQL インジェクション
2) OS コマンド・インジェクション
3) パス名パラメータの未チェック/ディレクトリ・トラバーサル
4) セッション管理の不備
5) クロスサイト・スクリプティング
6) CSRF(クロスサイト・リクエスト・フォージェリ)
7) HTTP ヘッダ・インジェクション
8) メールヘッダ・インジェクション
9) アクセス制御や認可制御の欠落
前回はCSRF:クロスサイト・リクエスト・フォージェリについて学んだ。
今回は「HTTPヘッダ・インジェクション」について。
1.HTTPヘッダ・インジェクションとは
HTTPリダイレクションの実装として、パラメータから取得したジャンプ先の URL情報を、Locationヘッダのフィールド値に使用する場合や、掲示板等において入力された名前等を Set-Cookieヘッダのフィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで、HTTPレスポンスヘッダの出力処理に問題がある場合、攻撃者は、レスポンス内容に任意のヘッダフィールドを追加したり、任意のボディを作成したり、複数のレスポンスを作り出すような攻撃を仕掛ける場合があります。
HTTPヘッダ・インジェクションとは、動的にHTTPヘッダを生成する機能の不備をついて、悪意のあるヘッダ行を挿入することで不正な動作を行なわせる攻撃手法のこと。
「挿入」するってことはクロスサイト・スクリプティング攻撃と同様に、エスケープ処理をしたらいいのか。
ヘッダ関係の知識がなさ過ぎてつらい。記事書こう。
エスケープ文字の対象は「改行コード」。
各ヘッダは改行コードで終了し、それ以降は新たなヘッダとして処理されるため。
発生しうる脅威は以下。
・クロスサイト・スクリプティング攻撃により発生しうる脅威と同じ脅威
・任意のCookie 発行
・キャッシュサーバのキャッシュ汚染
注意が必要なウェブサイトは以下。
・外部から渡されるパラメータの値から動的に生成するウェブアプリケーション
2.HTTPヘッダ・インジェクションの対策
ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用API を使用する
ヘッダの構造は継続行が許される等単純なものではありませんので、実行環境に用意されたヘッダ出力用のAPI を使用することをお勧めします。
PHPでは header()関数などを使うときに気をつけるべき。
徳丸本を読まなければ・・・
改行コードを適切に処理するヘッダ出力用API を利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する
例えば、改行の後に空白を入れることで継続行として処理する方法や、改行コード以降の文字を削除する方法、改行が含まれていたらウェブページ生成の処理を中止する方法等が考えられます。
保険的対策
・外部からの入力の全てについて、改行コードを削除する
解決策を概念的に示されてもプログラム上どうしたらいいか。
ただ文書を写すだけの作業になってきてるので反省。
一回読んで徳丸本と読み合わせてもう一回読むみたいな作戦のほうがいいのだろうか。
コメント