Webアプリケーションの脆弱性対策

Webアプリケーションの脆弱性対策とは、利用者の入力、画面への出力、セッションの管理、通信の経路などに潜む弱点を攻撃者に突かれないよう、複数の仕組みを組み合わせて守ることをいう。Webアプリケーションは外部から受け取った入力を処理して応答を返すため、入力の扱いを誤ると、OSのコマンドやデータベースの問合せ、ブラウザ上のスクリプトが攻撃者の意図どおりに動いてしまう。試験では、攻撃の仕組みと対策の対応関係を正しく説明できるかが問われる。

攻撃が成立する仕組み

Webアプリケーションを狙う代表的な攻撃は、利用者の入力が本来のデータとしてではなく、命令の一部として解釈されることで成立する。OSコマンドインジェクションは、シェルを起動できる言語機能に入力値を渡すと、入力に含まれた内容がコマンドとして解釈され、意図しないOSコマンドが実行されるおそれがあるために起きる。この攻撃を防ぐには、そのような言語機能を利用した実装を避けることが対策になる。

クロスサイトスクリプティング（XSS）は、入力データがWebページに出力される際にHTMLタグやスクリプトとして解釈され、閲覧者のブラウザ上で攻撃用のスクリプトが動く攻撃である。フォームの入力欄に悪意のあるJavaScriptを含むデータを入力する手口は、この攻撃の典型的な入口となる。一方、プレースホルダを使ってSQL文の構造と入力値を分けるのはSQLインジェクションへの対策であり、OSコマンドインジェクションの対策とは対象が異なる。

XSSは、攻撃者が掲示板などに攻撃用のスクリプトを書き込み、それがサイトに保存された状態で後から閲覧した利用者のブラウザで実行される格納型と、細工したリンクから送られた入力が応答にそのまま反映される反射型に分けられる。格納型は保存された内容が複数の利用者に繰り返し表示される点が特徴であり、保存を介さない反射型とは仕組みが異なる。反射型の手口は、リンクを利用者にクリックさせることで成立する点にも注意が必要である。

対策の判断基準

XSS対策の基本は、入力データを画面に出力する際に、HTMLタグとして解釈されない形へ変換することである。HTML本文へ出力する場合には、「<」のような特殊文字を文字参照に置き換えるHTMLエスケープを行うことで、入力内容がタグやスクリプトとして解釈されることを防げる。出力先がHTML本文か、属性値か、スクリプトの内側かによって必要な変換が異なるため、判断にあたっては出力の文脈を確認することが欠かせない。

入力データのサイズ制限は、過大な入力による負荷や資源の消費を抑えるうえで有効である。しかし、サイズを制限しても、入力内容がスクリプトとして解釈される問題そのものは解消されない。このため、サイズ制限は出力時の無害化の代わりにはならないと判断する。

セッションの乗っ取りへの対策では、利用者がログアウトした時点でサーバ側のセッションIDを無効にすることが判断の基準になる。サーバに保存しているだけではIDが有効なまま残るため、第三者がIDを取得すれば利用されるおそれがある。ブラウザのキャッシュを消去しても、サーバ側のIDが有効なままであれば、盗まれたIDによるアクセスは防げない。

重要な情報を送信する直前にパスワードで再認証させる対策は、セッションIDだけを盗んだ攻撃者による情報の閲覧を抑え、被害の拡大を防ぐ。通信をTLSで暗号化することは盗聴や改ざんの防止には有効だが、すでに盗まれたセッションを攻撃者が使うことは防げないため、両者の役割を区別して考える必要がある。