HTML5時代のWeb開発者が知らないとガチヤバな3つの未来予測と6つの脆弱性対策：UXClip（35）（2/2 ページ）

CEDEC 2013のHTML5に関する2つの講演を、主にセキュリティの観点からレポート。サイボウズ・ラボ竹迫氏とネットエージェント長谷川氏が語るWebは、こんなにヤバい

[宮田健，＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

HTML5時代、Web開発者なら必ずおさえておきたい6つのセキュリティ対策

　ネットエージェントの長谷川陽介氏のセッション「HTML5時代におけるセキュリティを意識した開発」は、Web系の技術者が最低限知っておくべき、攻撃手法とセキュリティ対策のいまを伝える講演だった。

【1】JavaScriptで安全なコードを書くための基礎「同一オリジンポリシー」

　「同一オリジンポリシー（Same Origin Policy）」は、近代的なWebにおけるコンセプトで、セキュリティを担保するための基本的な概念だ。これはRFC 6454 “Web Origin Concept”により提唱されており、「スキーム、ホスト、ポートが同一のものを信頼すべき」というものである。

　例えば、「http://example.jp/」というURLにおいては、以下の3つがそれぞれ割り当てられている。

スキーム：　http://
ホスト：　　example.jp
ポート：　　80

　このURLと、「https://example.jp/」とはスキームが異なるため、「同一オリジンではない」と判断できる。これが、同一オリジンポリシーの基本だ。

　この同一オリジンポリシーの制約としては、例えばXMLHttpRequestにおいては同一オリジンではない場合、明示的な許可なしにレスポンスが読めなかったり、Web Storageにおいてはオリジン単位で情報を保存するため、それを超えての読み書きができないようになっている。

　また、X-Frame-Options HTTPレスポンスヘッダは同一オリジン単位での許可となり、「クリックジャッキング」（参考：浸透しつつある仮想化環境をどう守る？どう使う？）対策として利用が可能だ。このように、比較的新しい機構は同一オリジンポリシーでの制約をかけられる。

【2】クロスサイトスクリプティング対策はHTML生成時にエスケープを

　ただし、この同一オリジンを破り、オリジンを超えてデータの読み書きを狙う方法がいくつかある。クロスサイトスクリプティング（XSS）はその一例だ。

　クロスサイトスクリプティングは、攻撃者が用意した任意のHTML、あるいはJavaScriptを挿入できてしまう脆弱性で、例えば検索のためのテキストボックスにスクリプト片を入れることで、任意のコードを実行できてしまうものだ。

　この応用例は多岐にわたり、例えば偽のフォームを表示させることで利用者が入力したデータを不正に取得するフィッシングサイトが作れてしまったり、セッション情報を漏えいさせることもできてしまう。「ブラウザ上でできることが、何でもできてしまう」（長谷川氏）。この対策は、HTMLを生成するときに適切にエスケープすることだ。

ネットエージェント長谷川陽介氏

　さらに、HTML5で登場した新要素によるクロスサイトスクリプティングも存在する。例えば、<script><object><iframe>などといった「危険そうな要素が入力されたら検出する」といった形で、ブラックリスト的にコーディングを行った場合、HTML5で新たに追加された多数の要素、属性、イベントが漏れてしまう。

　長谷川氏は「そもそもブラックリスト方式は無理がある」とし、「やはりHTML生成時にエスケープする、という原則を守るべきである」と述べた。「そうすれば、どんなデータに対しても正しいHTMLを出力できる。クロスサイトスクリプティングは正しくないHTMLを生成している『バグ』であり、想定しているHTMLを出力する対策をすべきだ」（長谷川氏）。

【3】JavaScriptが引き起こす「DOM Based XSS」

　次に長谷川氏は、JavaScriptが引き起こす「DOM Based XSS」について解説した。

　サーバ側のHTML生成時には問題がないにもかかわらず、JavaScriptによるHTMLレンダリング時に問題が発生する。この場合、Internet Explorerなど最新のブラウザに組み込まれた、XSSフィルタもすり抜けてしまうことが多いうえに、location.hash内の実行コードはサーバ側のログに残らないため、大きな問題となる。

　これは昨今、JavaScriptのコード量の増加に伴い、顕著になりつつある事象だ。

　原因は、攻撃者がコントロール可能な文字列からHTMLを生成したとき、それが適切に処理されていないことにある。例えば、innerHTMLやouterHTMLの処理が不足していると発生する。

　対策は、同様にHTML生成時におけるエスケープで、例えばURLを生成する処理であれば、明示的に「http://～」、もしくは「https://～」をあらかじめ設定する、または先頭文字列が「http://」のときのみ処理をするなどの判断を追加することが挙げられる。

　長谷川氏はエスケープする方法を紹介するとともに「むしろtextNodeを使おう」と述べた。

関連記事：IPAが「DOM Based XSS」の脆弱性に関するレポートを公開

【4】オープンリダイレクタの実装とCSRF対策

　長谷川氏はオープンリダイレクタの実装やCSRFの問題についても現状を解説した。

　オープンリダイレクタについては、あらかじめジャンプ先のURLが分かっている場合はコードの内部でリストを持っておき、攻撃者に任意のURLを組み込まれないようにしておくことが紹介された。

　また「CSRF」においては、XMLHttpRequest Level2で特定のファイルをアップロードできるという攻撃手法が紹介され「副作用を持つ場所全てにトークンを要求するべし」という解決策が提示された。

【5】HTML5における<input>要素の問題点

　長谷川氏は続いて、HTML5における新機能について触れた。<input>要素はHTML5において大幅な機能強化が行われ、タイプとしてdate、range、numberなど多くの入力形式に対応できるようになった（参考：HTML5でinput要素に追加された新しいタイプ13連発）。従来JavaScriptで実装していた入力内容の確認が、HTMLを書くだけで実現できるようになったといえる。

　長谷川氏によると、「Webアプリを超えて同一の操作性、統一されたエラーメッセージが出せることで、コード量の低減、ひいてはバグの抑制が狙える」という。

　ただし、攻撃者は任意のパターンの値を送信可能なため、この機構を「セキュリティ上のチェック機構として利用してはならない」と長谷川氏は指摘する。あくまで入力チェックとして利用し、セキュリティ上のチェックは従来通り行ったうえで、上記のようにHTML生成時のエスケープを忘れてはならない。

【6】機密情報をWeb Storageに保管しない方がよい

　また、JavaScriptでデータを保存可能な「Web Storage」も注目される技術だ。これはオリジン単位でストレージを作成できるが、Internet Explorer 8においてはhttp、httpsでデータが共有される。そのため「機密情報をWeb Storageに保管しない方がよい」と長谷川氏は述べる。

　そのほか、Safariの場合はプライベートブラウズ時にlocalStorageへの読み書きができないため、その場合は利用者がプライベートブラウズを行っていると推察できる。「万が一、『アクセスしていることすらバレたくない』ということでプライベートブラウズを行う利用者がいても、この手法でそれが分かってしまう」（長谷川氏）。

　また、共用PCにおいて、同じユーザーで、同じブラウザでアクセスすると、他のユーザーアカウント情報が漏えいすることも考えなくてはならない。対策としてはWeb Storage内にユーザーIDも含めて保存する、さらに未ログイン時にログインページにアクセスしたタイミングでWeb Storage内データを削除するなどの方式が考えられるが、「現時点では定石が確立されていない」（長谷川氏）とのことだ。