最近よく聞く「クロスサイトスクリプティング」って？

反射型攻撃を防止することと同様に、格納型攻撃からサイトを保護する際の鍵となるのは、送信されたすべてのデータが、表示前に表示エンティティに変換されるようにすることだ。これにより、送信されたデータはブラウザでコードとして解釈されなくなる。

ローカル型

ローカル型のクロスサイトスクリプティング攻撃では、ウェブページそのもののコード内の脆弱性が標的になる。これらの脆弱性は、JavaScriptでDOM（Document Object Model）を不用意に使った結果生じるもので、悪意のあるJavaScriptコードが含まれる別のウェブページを開くと、それと同時に、実際にはローカルシステムで最初のページ内のコードが改変されることがある。古いバージョンのInternet Explorer (Microsoft Windows XP Service Pack 2のInternet Explorer 6より前）では、World Wide Webから取得されたページではなく、ローカルコンピュータに格納されているローカルウェブページでもこの攻撃方法を使用できる。ブラウザの「サンドボックス」を破って外に出たそれらのページを通して、ブラウザの実行に使われたユーザー特権でローカルシステムに影響を及ぼすことができるのだ。多くのMicrosoft Windowsユーザーは何でも管理者アカウントとして実行する傾向があったため、これは事実上、Service Pack 2より前のMicrosoft Windows XPではローカル型のクロスサイトスクリプティング攻撃によって、ほとんど何でもできたことになる。

ローカル型のクロスサイトスクリプティング攻撃では、反射型や格納型の攻撃とは異なり、サーバには悪意のあるコードがまったく送信されない。攻撃動作はすべてローカルのクライアントシステムで発生するが、通常は正当であるウェブサイトから提供されたページは、ブラウザによって解釈される前に改変されるため、悪意のあるペイロードをサーバからクライアントに運んだかのように動作する。つまり、悪意のあるクロスサイトスクリプティングをフィルタで除外したりブロックしたりするサーバ側の保護では、この種類の攻撃には対処できないことになる。ローカル型のクロスサイトスクリプティングの詳細については、DOMベースのクロスサイトスクリプティングについての説明（英語）を参照してほしい。

クロスサイトスクリプティングからの保護

　クロスサイトスクリプティング攻撃からウェブ設計を保護する最も包括的な方法は、ユーザーによる入力に特殊文字が存在する場合は、URL内のものを含めてすべてHTMLエンティティなどの表示エンティティに変換することである。これは、PHP、Perl、ASP.NETなどのサーバ側コードだけでなく、ユーザーによる入力を扱うJavaScriptについても当てはまる。この対策は、ウェブサイト設計支援アプリケーションの場合など、ユーザーが自分の入力内でHTMLやXHTMLを使用できることを期待しているウェブサイトの運用の妨げになる場合もある。そのような場合は、悪意のあるコードからの保護のため、より複雑なコードが必要な場合がある。こうしたきめの細かいフィルタ処理は、悪意のあるセキュリティクラッカーとの軍拡競争の一面にすぎないが、当然、100％の効果が得られるものでもない。