サーブレットコンテナが抱える問題を認識する：Strutsで作るセキュアWebアプリケーション（2）（3/3 ページ）

» 2006年04月27日 00時00分公開

[安西真人，三井物産セキュアディレクション株式会社]

サーブレットコンテナに依存しない解決手法（続き）

カスタムエラーページを必ず定義する

推奨度：○

　正しい手法は、カスタムエラーページを必ず定義することである。システムが運用段階に入ったならば、詳細なエラーメッセージをユーザーに出力する必要はない。クロスサイトスクリプティングの問題と趣旨がそれるため、本稿ではこの点に重きを置いた解説は行わないが、この手法によりエラーメッセージのフッタから製品のバージョン情報が漏えいするという問題も併せて解決することができる。

　やり方はいろいろあるが、struts-config内におけるエラーハンドリングの記述がまず考えられる手段だといえるだろう。

<global-exceptions>
<exception key="error.global"
type="java.lang.Exception"
path="/error.html"/>
</global-exceptions>

struts-config.xml

画面5　カスタムエラーページが表示される

　この定義によってエラーページが表示され、一見問題は解決されたように見える。だが、実際はこの記述だけでは十分でない。エラーハンドリングの対象となるのは、Actionクラスのexecuteメソッド呼び出し以降に限定されるからだ。

前略
protected ActionForward
processActionPerform(HttpServletRequest request,
　　　　　　　　　　　　　　 HttpServletResponse response,
　　　　　　　　　　　　　　 Action action,
　　　　　　　　　　　　　　 ActionForm form,
　　　　　　　　　　　　　　 ActionMapping mapping)
throws IOException, ServletException {
try {
　　aciton.executeメソッドの呼び出し
　　 return (action.execute(mapping, form, request, response));
　　ここでcatchされた例外だけが、ハンドリング対象となる
　　 } catch (Exception e) {
　　return (processException(request, response,
　　　　　　　　　　　　　　　　　　 e, form, mapping));
}
}
中略
protected ActionForward processException(HttpServletRequest request,
　　　　　　　　　　　　　　　　　　　　　 HttpServletResponse response,
　　　　　　　　　　　　　　　　　　　　　 Exception exception,
　　　　　　　　　　　　　　　　　　　　　 ActionForm form,
　　　　　　　　　　　　　　　　　　　　　 ActionMapping mapping)
　　throws IOException, ServletException {
中略
　　// Use the configured exception handling
　　try {
　　　　ExceptionHandler handler = (ExceptionHandler)
　　　　RequestUtils.applicationInstance(config.getHandler());
　　　　return (handler.execute(exception, config, mapping, form,
　　　　　　　　　　　　　　　　　　　request, response));
　　} catch (Exception e) {
　　　　throw new ServletException(e);
　　}
}
後略

RequestProcessor.java

　従って、例外がスローされるタイミングによっては、カスタムエラーページが表示されないことがある。例えば、JSP上で例外が発生した場合や、ActionFormへのパラメータ格納処理時の例外などが挙げられる。サンプルとして、以下のActionFormを使用するアプリケーションを作成してみる。

public class TestForm extends ValidatorForm {
　　private String inputMsg;
　　public String getInputMsg() {
　　　　return inputMsg;
　　}
　　public void setInputMsg(String inputMsg) {
　　　　this.inputMsg = inputMsg;
　　}
}

TestFormjava

　作成したアプリケーションのクエリストリングに以下を指定して、リクエストを発行してみる。

inputMsg[0]=

画面6　TestFormの使用が定義されている/DispatchTest.doクエリストリングにinputMsg[0]=を指定

　TestFormではパラメータinputMsgを配列で扱うように実装していない。ただし、Strutsはパラメータに [数値] が含まれていると配列として解釈するため、このような例外が発生することになる。この例では入力値がエラーページに表示されることはないのでクロスサイトスクリプティングの問題が発生することはないが、入力値をエラーページとして表示する実装上で同様の問題が起こらないことを保証するのは難しいだろう。

　対策が不十分であることが分かったので、別の手法を検討してみよう。Strutsに依存しない一般的な対応として、web.xmlによる例外ハンドリングの仕組みを使用すれば、問題を解決することができそうだ。

<error-page>
　　例外は Status Code 500 でハンドリングすることができる
　　<error-code>500</error-code>
　　<location>/error.html</location>
</error-page>

web.xml

　web.xmlに上記定義を記述後、先ほどと同様のリクエストを発行してみる。

inputMsg[0]=

画面7　エラーページの表示に成功

　無事にエラーページを表示させることができた。

なお、この手法を使って例外を捕捉すると、HTTPステータスコードが200ではなく、500で返されることになる。IE（Internet Explorer）のデフォルト設定では、ステータスコード500の際にコンテンツのサイズが512バイト未満ならば、IEデフォルトのエラーメッセージを表示する仕様となっているから、512バイト以上のコンテンツを返してやる必要がある。

　ステータスコード500の捕捉だけでは不十分なケースも予測し、同様の定義を400番台、500番台のすべてのステータスコードに対して設定しておけば、製品のデフォルトページでクロスサイトスクリプティングが動作する問題を防ぐことが可能だろう。

　以上、2回にわたってクロスサイトスクリプティングの脆弱性に関する注意点を説明した。次回は、Validatorを使用した入力チェックに関する注意点について解説していこう。