サーブレットコンテナに依存しない解決手法（続き）
カスタムエラーページを必ず定義する
推奨度：○
正しい手法は、カスタムエラーページを必ず定義することである。システムが運用段階に入ったならば、詳細なエラーメッセージをユーザーに出力する必要はない。クロスサイトスクリプティングの問題と趣旨がそれるため、本稿ではこの点に重きを置いた解説は行わないが、この手法によりエラーメッセージのフッタから製品のバージョン情報が漏えいするという問題も併せて解決することができる。
やり方はいろいろあるが、struts-config内におけるエラーハンドリングの記述がまず考えられる手段だといえるだろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この定義によってエラーページが表示され、一見問題は解決されたように見える。だが、実際はこの記述だけでは十分でない。エラーハンドリングの対象となるのは、Actionクラスのexecuteメソッド呼び出し以降に限定されるからだ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
従って、例外がスローされるタイミングによっては、カスタムエラーページが表示されないことがある。例えば、JSP上で例外が発生した場合や、ActionFormへのパラメータ格納処理時の例外などが挙げられる。サンプルとして、以下のActionFormを使用するアプリケーションを作成してみる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
作成したアプリケーションのクエリストリングに以下を指定して、リクエストを発行してみる。
inputMsg[0]=
![画面6 TestFormの使用が定義されている/DispatchTest.doクエリストリングにinputMsg[0]=を指定](https://image.itmedia.co.jp/ait/articles/0604/27/r206.gif)
TestFormではパラメータinputMsgを配列で扱うように実装していない。ただし、Strutsはパラメータに [数値] が含まれていると配列として解釈するため、このような例外が発生することになる。この例では入力値がエラーページに表示されることはないのでクロスサイトスクリプティングの問題が発生することはないが、入力値をエラーページとして表示する実装上で同様の問題が起こらないことを保証するのは難しいだろう。
対策が不十分であることが分かったので、別の手法を検討してみよう。Strutsに依存しない一般的な対応として、web.xmlによる例外ハンドリングの仕組みを使用すれば、問題を解決することができそうだ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
web.xmlに上記定義を記述後、先ほどと同様のリクエストを発行してみる。
inputMsg[0]=
無事にエラーページを表示させることができた。
なお、この手法を使って例外を捕捉すると、HTTPステータスコードが200ではなく、500で返されることになる。IE（Internet Explorer）のデフォルト設定では、ステータスコード500の際にコンテンツのサイズが512バイト未満ならば、IEデフォルトのエラーメッセージを表示する仕様となっているから、512バイト以上のコンテンツを返してやる必要がある。
ステータスコード500の捕捉だけでは不十分なケースも予測し、同様の定義を400番台、500番台のすべてのステータスコードに対して設定しておけば、製品のデフォルトページでクロスサイトスクリプティングが動作する問題を防ぐことが可能だろう。
以上、2回にわたってクロスサイトスクリプティングの脆弱性に関する注意点を説明した。次回は、Validatorを使用した入力チェックに関する注意点について解説していこう。
Profile
安西 真人（あんざい まさと）
三井物産セキュアディレクション株式会社
テクニカルサービス事業部 技術グループ Webセキュリティチーム
エンジニア
Webアプリケーションのシステム開発経験を生かし、セキュリティコンサルタントとして主にWebアプリケーションのセキュリティガイドライン策定業務などに従事している。大手保険会社、出版社などへの導入実績を持つ。
Copyright © ITmedia, Inc. All Rights Reserved.