ICEfacesは、エンタープライズ用途で開発されているフレームワークであり、セキュリティ確保は避けて通ることができない。ここでは、いくつかのトピックを簡単に紹介したい。
1.入力検証
入力検証は、堅牢なシステムを構築するうえで最も基本的かつ効果的な対策の一つである。先述した通り、ICEfacesでは、パーシャルサブミットで送信される、画面と非同期かつ部分的なリクエストに対しても、JSFのバリデーション機構をそのまま使うことができる。JSFのバリデーションでは、検証を通った値のみがManaged Beanに反映される。このためビジネスロジックにて、(バリデーションを実施したつもりで)汚染された値を用いてしまうようなミスが少なくなる(もちろん、適切にバリデーションをかけること、およびビジネスロジック中で直接リクエストデータを取得し、利用しないことが前提ではあるが)。
2.XSS(クロスサイトスクリプティング)対策
XSSは、確実に防がなければならない脆弱性の一つである。リスト2におけるupdate要素のデータは、HTMLの断片である。従って(古くから言われ続けている)HTMLエスケープ処理を実施することで、XSSを防ぐことが可能である。ICEfaces(JSF)では、UIコンポーネントのescape属性が明示的にfalseになっている場合を除き、フレームワークにてHTMLのエスケープ処理を実施する。従って、例えばアドレスフォームのLast Nameに次のような値を入力しても、更新されたテキストボックスに、イベント属性を追加することはできない。
Ashiwa" onblur="alert(XSS);
3.CSRF(クロスサイトリクエストフォージェリ)対策
ICEfacesのバージョン1.6.0では、「XHRより送信されるリクエストにより、CSRFが成立してしまう可能性がある」という脆弱性が修正されている。
図3は、このCSRF対策の概要を示している。
|
|
図3: CSRF対策 |
まずは、サーバにて推測困難な値を生成し、この値をレスポンスデータ(画面のHTML)に埋め込んでクライアントに返す。クライアントではこの値をWindowオブジェクトやhiddenフィールドに保持しており、リクエスト送信時に、Ajaxブリッジによって、URLクエリストリングやPOSTデータ中にこの値を含めて送信する(Cookieとして送信されない)。サーバでは、メイン処理に入る前に、値の妥当性のチェックをしており、不適切な値が送信された場合には、以降の処理が実行されないようになっている。
攻撃者は、(XSSの脆弱性や、通信経路の脆弱性などがない限り)この値を取得することができないため、CSRF攻撃を成立させることができない。
XSSやCSRFについての解説については、「IPA セキュア・プログラミング講座: Webアプリケーション編」などを参考にしていただきたい。
