IE、Firefox、Chrome開発者を悩ませるJavaScript、ユーザー企業への影響は？

高品質なWebページを実現できる一方でハッカーに悪用されるケースの多いJavaScript。企業はその存在を完全に無効にすべきかどうか、必要なセキュリティ対策も踏まえて検討する。

公開 2011年09月12日 09時01分

更新 2012年09月04日 14時42分

著者

Michael Cobb

[TechTarget]

印刷する

　JavaScriptは、最も利用されているWebサイトスクリプト言語だ。Webブラウザ上で動作し、HTMLのみの場合に比べてはるかに動的なページを実現できる。一方でハッカーにとっては、ブラウザを乗っ取り、不正な操作を実行できる存在でもある。

　JavaScriptが攻撃に悪用されるケースが多いためクロスサイトスクリプティング（XSS）をはじめ、さまざまなインジェクション攻撃に利用されている、ブラウザベンダーは一層のセキュリティ対策が求められている。本稿では、JavaScriptのセキュリティ対策を幾つか紹介する。また、企業はJavaScriptを完全に無効にすべきかどうかについても検討する。

　JavaScriptのセキュリティ対策の1つは、不正コードが埋め込まれている既知のサイトへのユーザーアクセスを防ぎ、コードが実行される機会そのものを絶つことだ。MicrosoftのInternet Explorer（IE） 8とIE 9はURLをフィルタリングするSmartScreen機能を利用し、Firefox、Safari、ChromeはGoogleのSafeBrowsingを採用して、同様の処理を行っている。仕組みは、まず上記のようなレピュテーションベースのシステムがインターネット上の不正なWebサイトを検索し、検索結果に従ってサイトのコンテンツにフラグを付ける。次にユーザーがリクエストしたURLのレピュテーション情報をブラウザが要求し、危険を示すフラグがコンテンツに付けられている場合は、ユーザーに警告を表示する。

　IE 9にはXSSフィルタ機能も実装されている。この機能は、Webサイトからの他のWebサイトに対する動作を分析し、疑わしいスクリプトコードが別のサイトに混入することを防ぐ。Chromeにも同様の機能がある。Firefoxの場合はNoScriptプラグインをユーザーがインストールする必要がある。ただし、いずれのコントロールでも、ブラウザがサーバの意図とは違う形でコンテンツを解釈する可能性があるため、信用できないコンテンツを適切に除外することは難しい。実際、Samyワームはこの矛盾を突き、（MySpaceサイトで入力検証時にブロックされる）単語「JavaScript」を「Java」と「Script」の2つに分けることで、CSSタグ内にコードを混入させた。

　また最近では、不正コードをカモフラージュするために、複雑で検出しにくい複合型の攻撃が使用され始めている。例えば、Adobe Flashに組み込むAdobe ActionScriptコードとWebページに組み込むJavaScriptコンポーネントに悪意のあるコードを分割して、多くの予防型セキュリティの検査をすりぬけるという手法が取られている。

　Firefoxは、バージョン4からコンテンツセキュリティポリシー（CSP）をサポートした。CSPを利用すると、サイトは特殊なヘッダを送信することで、.js形式の実行可能スクリプトの正規の発行元と見なされるべきドメインを指定できる。CSP対応Webブラウザは、このような承認済みのドメインから読み込まれたスクリプトのみを実行する。Twitterは最近、モバイルサイトにCSPを実装したが、これは簡単な作業ではなかった。埋め込まれたJavaScriptコードを別のファイルに移動し、スクリプトタグを使って再読み込みする必要があるからだ。

　また、CSPはonClickなど、JavaScriptによって制御されるさまざまなHTMLイベントを無効にするため、JavaScriptの悪用は阻止できても、ユーザー用の送信ボタンなど、Weサイトの正規のonClick機能が図らずも使用できなくなる可能性がある。WordPress、Drupal、Djangoの各WebフレームワークへのCSPへの実装が進められているが、特に、持続型XSSに対しては限られた保護しか得られず、クロスサイトリクエストフォージェリ（CSRF）攻撃には歯が立たないため、大半のWebサイトでCSPが使用されるようになるまでには、時間がかかるだろう。

　JavaScriptのリスクを考慮し、企業ではJavaScriptの実行を全面的に無効にする場合がある。この設定は、全てのブラウザに用意されている。ただしこの場合、ナビゲーションメニューにはJavaScriptがある程度使用されていることが多いため、かなりのWebサイトを利用できなくなる。セキュリティが最優先課題の場合は、スクリプトを無効にし、ホワイトリストを作ってブラウザでJavaScriptの実行を許可するサイトと禁止するサイトを制御することもできる。

　この処理も全てのブラウザでサポートされているが、ホワイトリストのメンテナンスには時間がかかるのが難点だ。また、Adobe ReaderでもJavaScriptを無効にすることをお勧めする。Symantecによると、2010年に発生したWebベース攻撃の半数近くが、不正なPDFファイルに関係しているという。ほとんどのPDFは表示や操作にJavaScriptを必要としないため、Adobe ReaderでJavaScriptを無効にしても、さほど不便は感じないだろう。

　上記のいずれの方法もスマートではないが、現時点では、100％安全でありながらJavaScriptも使用できるという実用的な代替策はない。ブラウザベンダーはブラウザのセキュリティを強化する必要に迫られているが、JavaScriptベースの攻撃に強いサイトの構築をWeb開発者に求める必要もある。

　例えば、ユーザー入力をWebページに追加したりデータベースに格納する前に厳格なチェックを実行することで、持続型（ストアド）XSS攻撃からWebサイトユーザーを保護する（.NET開発者の場合は、Microsoft Anti-Cross Site Scripting Libraryをフル活用して、格納対象のデータから不正データを除去する）。また、開発者はクライアントサイドスクリプトがcookieにアクセスできないように、HttpOnlyフラグを常に使用する習慣を付け、IE 8で導入されたtoStaticHTMLなどのメソッドを利用することを覚える。toStaticHTMLは、HTMLで表示する前にユーザー入力からイベントの属性とスクリプトを削除することで、DOMベースのXSS攻撃からページを保護するメソッドだ。JavaScriptベースの攻撃の被害を受け得るWebページを排除することで、ユーザーの保護を格段に強化できる。

　ブラウザやサイトでどれほどセキュリティ対策を講じても、ユーザーやサイトが、ユーザーの信頼というブラウザセキュリティの最大の弱みにつけ込んだソーシャルエンジニアリング攻撃の餌食になる可能性は消せない。ソーシャルエンジニアリング攻撃では、ユーザーがJavaScriptコードをブラウザのアドレスバーにコピーするように仕向け、現在読み込まれているページのコンテンツが実行されるようにする。IE 9では、このようなユーザー自身の操作が引き金になる攻撃を防ぐため、アドレスバーにコピーされた文字列から「JavaScript」というプレフィックスを削除している。しかし、最高の対抗手段は、根気よくユーザーの啓蒙を続け、セキュリティポリシーに従わない場合のリスクを理解してもらうことだ。

印刷する