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

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

　第１回「適切なエスケープ処理でクロスサイトスクリプティングに備える」では、Strutsカスタムタグを使用する際の注意点を解説した。今回はサーブレットコンテナが抱える問題にまで視野を広げて、クロスサイトスクリプティング（Cross Site Scripting：XSS）に関する注意点を考察していこう。

エラーページで動作するスクリプト

　アプリケーションが返すレスポンスは、必ずしもアプリケーションの開発者が作成したものとは限らない。例えば、アプリケーション内において例外が発生した場合、明示的な指定がなければ製品のデフォルトエラーページが表示される。デフォルトエラーページはデバッグ用に用意されているものが多いため、表示内容には問題の起因となったパラメータやスタックトレースが含まれていることがある。

　では、デフォルトエラーページ内に出力される内容にスクリプトとして動作する値が含まれていたときには、どのような挙動が示されるのだろうか。渡されたパラメータを例外としてスローするアプリケーションを作成し、動作を確認してみよう。

public class ThrowsExceptionAction extends Action { public ActionForward execute( 　　　　　　　　ActionMapping mapping, 　　　　　　　　ActionForm form, 　　　　　　　　HttpServletRequest request, 　　　　　　　　HttpServletResponse response) 　　　　　　　　throws Exception { 　　　　TestForm testForm = (TestForm)form; 　　　　String input = testForm.getInputMsg(); 　　　　throw new Exception("：渡されたパラメータ" + input); 　　　　} }

ThrowsExceptionAction.Java

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

inputMsg=<script>alert('XSS');</script>

画面1　/ThrowsException.doのクエリストリングにinputMsg=<script>alert('XSS');</script>を指定

　Tomcat 5.5.15で確認した結果、パラメータは正しくHTMLエンコードされ、スクリプトは動作しなかった。

　では、HTMLエンコードはどのタイミングで行われているのだろうか。Strutsのソースコードを追っても、それらしい実装は見当たらない。エラーページはサーブレットコンテナによって作成されるので、サーブレットコンテナがHTMLエンコードを行っていると考えるのが自然だろう。

　サーブレットコンテナごとの動作の違いを見ていくと、HTMLエンコードが漏れている実装があった場合に、スクリプトが動作することが確認できた。例えば、Tomcat 4.1.27はエラーページのHTMLエンコードを行わない実装となっているため、同じアプリケーションを実行するとスクリプトが動作する。

画面2　Tomcat 4.1.27ではスクリプトが動作する

　このように製品のデフォルトエラーページを使用する際のHTMLエンコードは、サーブレットコンテナ依存の問題となっているため、クロスサイトスクリプティングの脆弱性が存在しないことを必ず確認する必要がある。