Webアプリケーションの攻撃対策

Webアプリケーションの攻撃対策とは、利用者の入力や通信内容を悪用して、アプリケーションに不正な処理をさせる攻撃を防ぐための考え方と手段の総称である。攻撃は入力の解釈、セッション管理、通信内容の検査など経路ごとに仕組みが異なるため、対策も攻撃の仕組みに合わせて選ぶ必要がある。本単元では、スクリプトの混入、OSコマンドの注入、セッションの乗っ取り、WAFによる防御の四つの観点から整理する。

攻撃の仕組みと対策の対応

クロスサイトスクリプティング（XSS）は、入力値などに悪意のあるスクリプトを混入させ、そのページを閲覧した利用者のブラウザ上で実行させる攻撃である。フォームの入力欄に悪意のあるJavaScriptを含むデータを入力する手口は、この攻撃の典型例である。

XSSが成立する原因は、アプリケーションが利用者の入力を、HTMLとして解釈される形のまま画面に出力してしまう点にある。そのため対策では、出力データがHTMLタグとして解釈されないように処理することが基本となる。HTML本文で「<」を「&lt;」に変換するといったエスケープが代表例である。

OSコマンドインジェクションは、アプリケーションがシェルを起動する言語機能に利用者の入力を渡した結果、入力内容がコマンドとして解釈されて意図しないOSコマンドが実行される攻撃である。したがって、シェルを起動する機能を使う実装を避けることが、この攻撃に対する有効な対策になる。

セッションの乗っ取りへの対策

セッションの乗っ取りとは、攻撃者がセッションIDなどを入手し、そのセッションを使って正当な利用者になりすまして情報にアクセスする攻撃である。ログアウト後もサーバ側でセッションIDが有効なままだと、入手されたIDで再びアクセスされるおそれがあるため、ログアウト時にはWebサーバ側でセッションIDを無効にする処理が必要になる。

この処理がブラウザ側の操作より確実である理由は、乗っ取りに使われるのがサーバが有効と判断しているIDだからである。ブラウザのキャッシュを消去したり、セッションIDをブラウザのディスク内に保存したりしても、サーバ側で有効なIDが残っていれば、盗まれたIDによるアクセスは防げない。

さらに、セッションIDをURLに含めると、閲覧履歴やアクセスログ、リンク経由などから漏れるおそれがあるため、避けるべき実装となる。

判断の基準

対策を選ぶ際は、攻撃が何を悪用しているかを基準にする。TLSによる通信の暗号化は、盗聴や改ざんを防ぐ効果はあるが、すでに盗まれたセッションを攻撃者が使う行為を止めることはできない。

入力値の扱いでは、入力サイズの制限が過大なリクエストによる負荷や資源消費を抑える効果を持つ点を押さえる。ただし、入力内容がスクリプトとして解釈されるXSSの原因そのものは取り除けない。