CodeIQ MAGAZINECodeIQ MAGAZINE

フロントエンドエンジニアなら知っておきたい「HTML5のセキュリティ問題と対策技術」第44回HTML5とか勉強会レポート #html5j #HTML5

2014.02.14 Category:勉強会・イベント Tag: , ,

  • 34
  • このエントリーをはてなブックマークに追加
セキュリティ3

Web技術者コミュニティ「html5j」が主催する最新技術トレンドや業界動向を学ぶ勉強会「HTML5とか勉強会」が六本木ヒルズのGoogleで開催された。第44回となる今回のテーマは「HTML5とセキュリティ」。

セキュリティのエキスパートたちが語る、HTML5および関連する周辺技術のセキュリティ対策に役立つ情報とヒントをレポートする。
by 馬場美由紀 (CodeIQ中の人)

今から始めるHTML5セキュリティ

トップバッターで登壇したのは、一般社団法人JPCERTコーディネーションセンターの松本悦宜氏。JPCERT/CCが2013年10月に公開した「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」をもとに、Webアプリケーション開発者が 知っておきたいHTML5および関連する周辺技術のセキュリティ対策について解説した。

便利さの一方で、脆弱性も広がるHTML5

HTML5は、開発者にとって非常に便利である一方で、攻撃者にとっても非常に便利なものになってしまった。さまざまな機能によって表現の幅が広がっているのだが、それも逆に言えば、攻撃の幅も広がっていることに繋がっている。

  • XMLHttpRequest
  • Cross Document Messaging
  • Office Web Application
  • Web Storage
  • WebSocket
  • Web Workers

新規追加HTML属性・要素——など、上記のような関連キーワードはさまざまあるが、これらに関しても、使用に際しては、セキュリティの面で注意が必要であることを感じているという。

従来のHTMLでは影響がなかったケースでも、最近のプラウザがHTML5に対応する機能が当たり前のように実装されるようになり、それが脆弱性に繋がってしまうケースが存在する。

利便性が向上する一方で、それらの新技術について、攻撃者は当然ながら理解して使っている。しかし、それらが悪用された際にユーザーが受ける影響に関して、当時は十分に検証や周知がされているとは言えない状況だった。

そこでJPCERTから、2013年の10月30日に「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」というものを出した。先ほど紹介した背景を中心に、HTML5でWebアプリケーションなど開発する方々向けに、「セキュリティに関し、こういうことに注意して欲しい」という事項をまとめている。

このドキュメントに関しては、ネットエージェントの多大な協力があって完成した。現在は、JPCERTコーディネーションセンターの左メニューの「公開資料」→「研究・調査資料」の項からダウンロードできる。あるいは「JPCERT HTML5」で検索しても一番上に出てくるはずなので、興味のある方はそこから入手していただきたい。

ざっとどういうものが紹介されているかというものをリストアップしてみた。

報告書で紹介しているセキュリティ関連機能

「JavaScript API」の項で、「XMLHttpRequest」というキーワードを赤字で表しているが、今回はこれについて紹介する。あとは「HTML5の新要素・属性」で、「video」や「audio」はHTML5で新しい要素として策定されたが、従来からある「input」要素なども新しい属性が増えている。

さらにブラウザで実装されている「セキュリティ機能」にもいろいろあるが、そのうち「Content-Security-Policy」を紹介したい。

調査報告書のポイント(1):XMLHttpRequest

XMLHttpRequest(XHR)とは、JavaScriptでHTTP通信を行うためのAPIで、非同期通信でいろいろ便利なことができるというもの。HTML5以前からある機能だが、HTML5で新しくなっている。

以前は、同じオリジン内でしか通信ができなかった。しかしHTML5になり、クロスオリジン対応となった。クロスオリジンで通信するためにはサーバの合意が必要となるものの、サーバ側で許可していない場合でも、リクエストは送られてしまう。

例えばこのような感じとなる。

XHRを使用するJavaScriptコード

これがどのような面で脆弱性になるかというと——。フレームを使わずXHRで動的にコンテンツを書き換えているケースである。

ケース1:XHRを使用した既存のWebサイト

具体的な攻撃コード例を挙げる。

具体的な攻撃コード例

この場合、攻撃者が(例えば)evil.com/evil.htmlをURLの最後に付けると、クロスオリジン通信が可能になってしまうために、攻撃者が用意した外部のサイト「evil.com」と通信し、悪質なHTMLを読みに行ってしまう。

対策としては、URLをそのまま取るのではなく、通信先をホワイトリストとして指定しておき、悪意のある通信先へのアクセスを行わないようにすることが考えられる。

また、少々細かい話になるが、「それでは、閉じたイントラネット内であれば、Access-Controll-Allow-Originを“*”にすれば安心なのか」という点について。

しかしこの場合、攻撃者がそこで悪意のあるコードを実行してしまうと、当然、攻撃者のオリジンで実行しているのだけれども、“Access-Controll-Allow-Origin:*”にすることで、イントラネット内サイトBのデータ・レスポンスを攻撃者のところで受信してしまう。やはりCookieを使ってしっかりアクセス制限をすつことが望ましい。Access-Controll-Allow-Originはアクセス制御の目的で使用しないよう注意すべき。

ケース2:攻撃コード例

問題と対策

報告書ではJavaScript APIに関し、今回紹介した以外にも、さまざまな機能・問題を紹介している。

調査報告書のポイント(2):HTML新要素・属性

HTML新要素・属性に関しては、ここに並べたようなものがある。

HTML新要素・属性

まずはvideo、audioについて。
IE9および10では、<video><audio>要素のoneerrorイベントが動作するため、XSS(クロスサイトスクリプティング)攻撃が行われる可能性がある。

次に<button formaction>という新属性について。従来は生成するHTMLへのイベントハンドラーの挿入を禁じるために、onで始まる属性を検出する対策を取る場合があったが、formactionの登場で、このような対策では不十分となる。

<input type="email"><input type="text" pattern><input type="email">では、ブラウザが自動的にemailのチェックをしてくれる。しかし、ブラウザの設定を攻撃者が変えることで、emailのチェックをしなくなり、悪質なスクリプトが実行される可能性がある。やはりこれだけに頼らず、サーバサイドでのチェックも不可欠と言える。

<iframe sandbox>は、iframe内でのスクリプトの実行やフォームの送信などを制限する機能。もしここのsub.htmlに、何かの脆弱性があった場合も、スクリプトの実行を制限することができる。

そこで、もう対策はしなくてもよいと思いがちなのだが、実際には、自身のページを<iframe sandbox>で読み込むようにしても、攻撃者は直接ページを参照させることが可能であるため、XSS攻撃などを防ぐことはできない。

調査報告書のポイント(3):セキュリティ関連機能

報告書では、ここにあるリストにある機能について扱っている。

セキュリティ関連機能

今回はその中から、特に「Content-Security-Policy」を紹介する。
これは、「Content-Security-Policy」は、読み込み可能なリソースのオリジンをレスポンスヘッダに指定することで機能を制限。もしXSSの脆弱性があったとしても、「Content-Security-Policy」を設定することで、XSSのJavaScriptは実行されず、その攻撃の可能性を低減するものとされている。

Content-Security-Policyは、このような書き方になっている。

Content-Security-Policy記述模式

Content-Security-Policy、ディレクティブ例、ディレクティブソース例

ただし、ブラウザによってはContent-Security-Policyをサポートしていないもの、あるいは実装に差があるものもあり、これに頼り切ることなく、従来通りのXSS対策は必要となる。

また設定内容によっては、正規のJavaScriptが動作しない場合もあるため、その点でもしっかりテストをした上で導入するなどの注意も必要となる。

まとめ

HTML5は便利になる一方で、使用には注意が必要な機能も多々ある。
「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」は無料でダウンロードできるので、セキュアなWebアプリケーションの開発にぜひ役立てて欲しい。

本当は怖いクライアントサイドキャッシュポイズニング

Applicationのキャッシュポイズニングの内容に疑問があったため個人的に調査したという吾郷協氏。調査から得られた具体的な攻撃シナリオ、ユーザー、ベンダーそれぞれの対応方法、リスク評価、「調査報告書」に対するツッコミを紹介した。

まずは吾郷氏の自己紹介から。

  • たぶん、日本で一番AppCacheについて話しているのではないかと思う。
  • 今日はじめてJPCERT/CCの正式名称を知ったくらいのスキル
  • 「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」は長すぎるので、できれば公式な略称が欲しい。検討して頂きたい。
  • この資料は公開されない。情報がまとまりきっていない部分もあるので、この内容をまとめた記事(※)を後日公開することになると思うが、この資料自体は公開されない。ただし、内容についてTwitterなどで拡散するのは構わない。

攻撃シナリオを使って解説するApplicationCacheのキャッシュポイズニング

キャッシュポイズニングとは何か

キャッシュに攻撃コードを仕込むことで、継続的に監視、攻撃を行う手法のことをこのように呼ぶ。
中でも、検索すると真っ先に上がることでわかるように、DNSキャッシュポイズニングが特に有名。しかし今回はそれではなく、最近話題に上るようになってきた、クライアント側(ブラウザ上)のキャッシュポイズニングについて紹介する。

なぜ最近になって話題になっているかだが、それは、次のような変化が起きているためだと思う。

ひとつは、「モバイル端末の普及」。モバイル端末ではオフラインになる可能性が増えて、従来よりもキャッシュ管理がより重要になっている。また、簡単にアカウントを切り替える手段がないために、そのまま他人に貸してしまうなど、貸し借りの際のアカウント管理が問題となっている。「ちょっと目を放した隙に」といったように、“一瞬の隙”を衝かれやすいものでもある。

あとは、「ブラウザAPIの進化」。各種キャッシュAPIの増加。ApplicationCache。これが今回最も話したいことでもあるが、ApplicationCacheはかなり大きな変化であると思う。

本題1:ApplicationCacheは危険なのか?

「で、結局ApplicationCacheはって危険なの?」という問いを考えてみたい。
そもそもApplicationCacheの危険とはどのようなものかを考えると、例えば、“HTML5 Security cheat Sheet”という、QWASPが出している報告書の中でも、Offline Applicationsという項目がある。

また、「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」でも4.2.3でOffline Web Applicationが扱われているが、具体的に言えば、ApplicationCacheに関してのセキュリティ問題が論じられている。

では、ApplicationCacheを使ったキャッシュポイズニングとはどういうものかを考えると、ほぼ次のようなものを想像できる。

  • 「ユーザが信頼できないネットワーク上でAppCacheを使って不正なコードをキャッシュさせられる」
  • 大前提として、ユーザが信用できないネットワークを使っている以上、内容の差し替えはしようがないが、AppCacheの場合はその被害が大きくなる。
  • ただし、あまりどうしようもない問題でもある。

その攻撃シナリオは、

  • ターゲットの端末のhttp通信をすべて乗っ取り、htmlファイルすべてにiframeで汚染したいURLを開かせる。
  • iframe経由で開かれたURL全部でAppCacheを使っているようにhtmlを書き換える。
  • .appcacheで参照しているファイルに対して不正なコードを送り込む。

「通信内容が差し替えられるなら、AppCacheは無関係では」との疑問を抱く人もいるかもしれないが、AppCacheを使っていると、その後安全なネットワークに移っても被害が終わらない。

「通信内容を差し替えた時点で一気に攻撃されれば終わりでは」と思うかも知れないが、AppCache経由の場合はターゲットに気付かれず、継続的な監視ができる。攻撃だけでなく監視ができるというところに、今までとの大きな違いがある。

では、AppCacheは使わないほうがいいのだろうか。
今までの話のなかで気付かれた方もいるかもしれないが、ユーザが信用できないネットワークで起こる問題なので、SSLを使っていれば、ここまでの問題は関係がない。基本的には安全であると言える。従って、AppCacheは使わないほうがいい、などということはないと、吾郷氏は考えている。

ちなみに、偉い人の言葉に、「その仕様を最も悪用できる方法を思いつくことが、世界平和の貢献につながる」(デブサミ2012、趣味と実益の脆弱性発見)とある。

そこで、最も悪用した場合にどうなるのか、攻撃者の気持ちになって考えてみる。

  • 回線を奪取できれば、コンテンツ提供者と同じことができる。
  • 汚染された回線で偽の.appcacheにその.appcache自体のURLを書くと、非汚染回線に移っても攻撃が継続できる。
  • .appcacheが無効なら既存のJSに攻撃コードを仕込んで、HTTP HeaderにExpires設定してキャッシュさせてもいい(ブラウザのリロードボタンを押すと消えるが)。

今度はコンテンツ提供者側の気持ちになってこの攻撃について考えてみると——

  • 攻撃されているかどうかは判断できない(JSのシグネチャー確認をしても、確認用コードを書き換えられるので意味がない)。
  • もし攻撃を回避するなら、毎回必ずキャッシュを破棄する実装が必要になる(とはいえ、特にモバイル端末は回線速度が遅いので、キャッシュはできるだけ長くしたい。従ってコンテンツ提供者としてはあまり現実的な選択肢ではない)。
  • 仮に毎回必ずキャッシュを破棄する実装をしたとしても、ブラウザがAppCacheをサポートしていれば攻撃される。

結論1:AppCacheは危険ではない

「AppCacheは危険ではない」
「AppCacheは(少なくともコンテンツ提供側から見て)危険が増えたわけではない」

一般的にこの問題がどのように扱われているかというと、先述のQWASPの報告書、“HTML5 Security cheat Sheet”では

ユーザーが信用できないネットワークを使っている場合、キャッシュポイズニングの問題がある。従って、「AppCacheを使う前に、ユーザーに対して確認を取る」——といったようなことが書かれているが、実際には、「使う前の確認」をMitMで書き換えられてしまったら意味はない。

「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」では、こちらもOffline Web Applicationという項目で、AppCacheに関する記述がある。ただし、もともとAppCacheを使っていなくても、MitMが成立してしまえばキャッシュポイズニングは可能であり、Offline Web Applicationを使っている場合だけ攻撃を受ける可能性があるとするのはおかしいのではないかと思う。

この問題に関しブラウザベンダーがどう考えているかだが、外から見る限りでは、特に気にしていないように見える。FirefoxはAppCacheを使う前にユーザに確認を行うが、これはかなり古い時期に実装されていること、単に「ローカルに保存しますか」と訊ねるだけで、セキュリティに関し触れない文言から考えても、キャッシュポイズニング対策ではなさそう。

私個人としては、まずブラウザベンダーが対応したほうがいいように思うが、どう対応すべきかはわからない。

本題2:実際、MitMは可能なのか?

「実際、MitMってできるの?」——MitMとはman-in-the-middle attack、中間者攻撃と訳される。

ここまで述べてきた問題は、基本的に、MitMがあるという前提に立っている。もしもMitMが成立しないのであれば、AppCacheをいくら使ってもセキュリティ上に問題は発生しない。

現在、公衆無線LANが増加しているが、これはすなわち、MitMの危険性が上がっていることを意味するのか、ということを考えてみたい。

結論から言えば、従来より危険性は上がっていると思う。

  • キャリアの提供するアクセスポイント(AP)は外部から攻撃できるのではないか。
  • キャリアの提供するAPの振りをすることもできるのではないか。
  • キャリアの提供するAPに細工をすることはできないのか。
     ——APは見える位置、目立つ位置に置かれていることがある。それだけ攻撃や細工の危険性は高いのではないか。さらに、
     キャリアの提供するAPの設置店舗が悪意を持っているケースは考えられないのか。
  • 公衆無線LANサービス系は攻撃できないのか。
  • 共通passで接続できるAPのそばに、同じ認証情報の多量の汚染APをばらまいたらどうなるのか。
  • 人通りが多い場所に、自由に繋げられる汚染APを設置したらどうなるのか。
  • そしてこれらはどこまで犯罪なのか。
  • 例えば監視は犯罪なのか。

関連して、時間があれば会場の皆さんに質問をしたい。

「モバイルサイトは常にhttpsにすべきか?」
——HTTP/2.0は暗号化オプションになったが、各ブラウザベンダーは、割と暗号化必須で実装している。

例えばこういうところで繋げるモバイルサイトは、全部httpsにすべきなのだろうか。結構、攻撃を受ける可能性は高いのではないかと個人的には思っている。またAppCacheを使った場合にブラウザから消すことは非常に難しいので、場合によっては継続的に干渉されることになる。かなり厄介な問題ではないかと思っている。

HTTP/2.0で暗号化は必須にならず、オプションになったものの、各ブラウザベンダーは、割と暗号化必須で実装しているのはこうした問題もあるためかと個人的には思っているのだが、どうだろうか。

「Apple iTunesは、iTunes Tutorialsウィンドウに対してHTTPを使用するため、コンテンツを偽装される脆弱性が存在します」——これはどういう意味で脆弱性と判断されたのか。

ここまでのキャッシュポイズニングに関する考察をもとに考えれば脆弱性と考えられる気もするが、そういうことを想定して、これは脆弱性と判断されたのか。もしそうなると、他のサイト、他のアプリケーションもかなり脆弱と見なされるのではないだろうか。

Bypass SOP in a time of HTML5

最後の登壇者は、ネットエージェント株式会社のはせがわようすけ氏。
冒頭、「HTML5時代のSOP破り」という話題で話すと宣言。

なぜSOP破りというような話になってくるかというと、ブラウザが高機能化して、表現力・速度が上がってきたために、当然、JSコード量は増加してくる。そこで、攻撃者が狙う対象もブラウザ上へ移ってきて、SOP破りの受動的攻撃が増加してくる。

SOPを破るのを趣味にしている、などという人は、ますますいろいろな手法を編み出してきていて、なんだかスゴイことになってきている。

オリジンとは何か

まず最初に、オリジンについて、もう一度言葉の意味を整理するために振り返ってみたい。
オリジンとは、RFC6454というのが決まっていて(The Web Origin Concept)、「スキーム+ホスト+ポート」。この3つの組み合わせをもってオリジンという。

例えば、この2つを比較すると、下はポート8080で受けているので、「オリジンが異なる」ということになる。

  • http://example.jp/image.png
  • http://example.jp:8080/index.html

デフォルトのポートは省略される。プログラムの中で、オリジンどこから来た、といった話がしばしば入ってくる。そのため、オリジンを正規化して表現したほうがよい、ということになる。

  • http://example.jp
  • http://example.jp:8080

では、同一オリジンポリシー(Same-Origin Policy)、いわゆるSOPとは何か。
オリジンが異なる場合、XHRでの読み取り、localStorageでの読み書き範囲など、さまざまな制約を課そうというのが同一オリジンポリシー。ただ、そのように一言で言っても、実際には、どのような挙動を同一オリジンポリシーと呼ぶかに関しては、対象やメカニズムによってそれぞれ異なっている。

例えばXHRでは、オリジンが異なる場合は相手が許可した時にしか読めないとか、ローカルストレージは読み書きの範囲がオリジンに単位に制約されている。これらもそれぞれ同一オリジンポリシーのひとつ。つまり、機構によって、それぞれ同一オリジンポリシーによって制約される事項というのも異なってくる。

一方、古くからWebに存在しているcookieやHTTTP認証は——文脈上、オリジンと言ったりすることはあっても、必ずしも、厳密な意味でオリジンをベースにしているわけではない。

このように、オリジンが共通だと比較的自由にいろいろなことができるけれども、オリジンが異なると何もできない、というルールが同一オリジンポリシーである。とはいえ一方では、オリジンが異なっていても、それを超えて、相手が許可をしている場合には読み書きできるようにしたいという状況も発生することがある。

そういった場合に、リソースを共有するために統一的なルールを決めておこうというのが、CORS=Cross-Origin Resource Sharingというもの。

これはどういう状況の場合に発生するかというと、XHRで異なるオリジンから取ってきたリソースを代入して表示する、あとは画像や、Web Fontなどでも似たようなことがある。

もう少し下のレイヤー、具体的なプロトコルなどは、例えばこのようになる。

XHR with CORS

さて、Access-Control-Allow-Origin:*というのは、アスタリスクを指定すると、誰からでも読み取り可能になってしまう。仮に、機密情報を含むコンテンツだった場合、罠ページからでも読み取られてしまうことになる。従って、アスタリスクを付けることは避けなければならない。

XMLHttpRequest

XMLHttpRequestは、言うまでもなく、今時のJSアプリの要になっているもの。Lv.2により、クロスオリジン通信が可能になった。その一方で、非常に周辺に脆弱性も多い。例えばよくある脆弱性としては、

  • 意図せずクロスオリジン通信→XSS
  • 意図せずクロスオリジン通信→データ漏洩
  • Ajaxデータを悪用してXSS
  • Ajaxデータ内の機密情報漏洩

などが上げられる。

(1)意図せずクロスオリジン通信→XSS

最初に、「意図せずクロスオリジン通信→XSS」について。これは、例えば10年前、クロスオリジン通信ができない間は安全だったわけで、XHR Lv.2で脆弱になったとも言える。

意図せずクロスオリジン通信→XSS

対策としては、どこと通信するかを事前に、プログラムの中に固定でリストで持っておくこと。文字列のチェック等では抜け道から抜け道へと泥仕合になってくるので、リストのほうが確実で、プログラムの中で「これしか選べません」という状態にしておくほうが安全度は高い。

(2)意図せずクロスオリジン通信→データ漏洩

次に「意図せずクロスオリジン通信→データ漏洩」について。これはサーバ側の話となる。
まず、リクエストヘッダでオリジンが飛んでくる。このオリジンで、送信元を確認する。例えばexample.jpだけが読むことを許された機密情報であるという具合に、Access-Comtrol-Allow-Originで指定する。こうした実装例は、果たして安全だろうか。

しかし実際には、攻撃者はtelnet等で任意のOriginを送信可能。つまり、この実装例は脆弱であり、Origin:ヘッダを認証に使用してはいけない、ということになる。

リクエストヘッダのOriginで送信元を確認

Origin:ヘッダを認証に使用してはいけない

本当に認証をしたいのであれば、今まで通り、Cookieを使って行うべきだろう。

通常通りCookieを使って認証

(3)Ajaxデータを使ったXSS

ここに掲示したものは本質的にJavaScriptの記述なので、カッコを連ねてスクリプトを書いても問題はないはずなのだけれど、IEで表示させるとご覧のようになってしまう。

Ajaxデータを使ったXSS

これはIEが悪いとしか言いようがない。

返したものがJSONなのでエスケープすればよいと考えるかもしれない。しかしこれはJSONだから可能だというだけで、text/plain、text/csvなどの場合はエスケープできない。

このような場合は、X-Content-Type-Optionを付けると、非HTMLがHTML扱いされることはなくなる。

対策

実際に、Ajaxを使って多くのデータをやり取りする際に、その中のレスポンスに細工をして、HTML扱いをさせるという手法は、攻撃者側から見て“使える”もので、事例的にも多いので、X-Content-Type-Optionは忘れずに入れるようにしたい。

(4)Ajaxデータ内の機密情報漏洩

  • JavaScriptやVBScriptとして解釈可能なAjaxデータが狙われやすい
  • 典型的な攻撃としては、スクリプトのソースとして、機密情報が含まれるJSONを読み込む。
  • 昨年あった例としては、JSON配列をVBScriptとして読み込むものがあった。

JSON配列をVBScriptとして読み込む

Ajaxデータ内の機密情報漏洩

対策としては先ほどと同じだが、X-Content-Type-Optionsを付けることが考えられる。

対策

これをすると、Content-Typeに厳密に従うようになる。

セキュリティ関係のレスポンスヘッダ

ここまで、XHR周りの脆弱性の話を、4つほどしてきた。このように、XHR周りの話は多いのだが、一方で、先ほどのX-Content-Type-Optionsのように、1行付け加えるだけで、難しい部分は判らなくても、かなりの攻撃を防げる、効果的な手法もある。

こうした効果的なヘッダーはいくつかあり、ぜひ使いこなせるようにしたい。

使いこなすことでよりセキュアに

(1)X-XSS-Protection

まず最初のX-XSS-Protectionは、XSS保護機能の制御で、IE、Chrome、Opera、Safariで有効——つまりfirefoxではだめだが、それ以外ではほぼ有効なもの。以下のような特徴がある。

X-XSS-Protection

たまに調べてみると、「XSSフィルターを無効に設定しましょう」などと推奨しているページがあったりするが、これは絶対にやめるべき。どうしてもXSSフィルターの誤検知が出てユーザーからのクレームが相次ぐ場合には、

  • 該当ページに本当にXSSがないかどうか慎重に検査した上で
  • そのページのみ、X-XSS-Protection:0を指定する

という手法を使い、ブラウザの設定変更は行わないようにしたい。

(2)X-Content-Type-Options

次に、先ほどから紹介しているX-Content-Type-Options。これはContent-Typeを厳格に扱うもの。

X-Content-Type-Options

大きく2つの役割があり、1つはHTMLではないものをHTMLとして扱わないということ。これはJSONやCSVによるXSSの防止に役立つ。もう1つは非JSを<script src>として読み込まないこと。これはscript src経由での情報漏えい防止に役立つ。

これは副作用がほとんどないので、すべてのコンテンツに付加するべきだろうと思う。

(3)X-frame-Options

「クリックジャッキング」という、標的サイトを透明に重ね、意図しないクリックを引き起こす攻撃手法がある。
これへの対策として、X-frame-Optionsというヘッダを付けると、iframe、frameなどでの埋め込みを禁止/制御することができる。

X-frame-Options

特にX-frame-Options:ALLOW-FROMでは、特定オリジン以外からの埋め込みを禁止するものだが、指定できるオリジンは基本、1つだけとなっている(Firefoxのみはスペース区切りで複数オリジンが指定できる)。

複数オリジンに対応する場合には、呼び出し元オリジンごとに識別子をURLに付与するといった工夫が必要になる。

ALLOW-FROMの複数オリジン対応

(4)Content-Security-Policy

Content-Security-Policyは、先ほどもお話しがあったように、ヘッダで指定されたソースからしか画像やJSを読み込めなくするもの。JSのリソースを、明示的に「ここからはいい、ここからはダメ」と全部登録できるので、使いこなせばXSS対策として非常に有効だが、実際の運用は非常に大変になる。

(5)X-Dowmliad-Options

X-Dowmliad-Optionsはあまり知られていない、比較的マイナーなヘッダだが、IE8以降でダウンロード時の「開く」ボタンを非表示にできるというもの。これによって、添付ファイルによる蓄積型XSSを予防することができるなどの効果がある。

(6)Strict-Transport-Security

これはHTTPSを強制するための指令で、これをレスポンスヘッダに入れておくと、以降のHTTPへのアクセスはHTTPSに置き換わる。

第44回HTML5とか勉強会「HTML5とセキュリティ」動画公開中!

CodeIQコード銀行にあなたのコードを預けてみませんか?

  • CodeIQコード銀行ではあなたのコードを財産と考えます。
  • お預かりいただいたコードは、CodeIQコード銀行がしっかり評価し、フィードバックいたします。
  • 当コード銀行にお預けいただいたコードは、企業がみてスカウトをかける可能性があります。
  • 転職したい方や将来転職することを考えている方で、今の自分のスキルレベルを知りたい方はぜひ挑戦してみてください。
  • 企業からスカウトがきたら困る人は挑戦しないでください。

興味を持った方はこちらからチャレンジを!

  • 34
  • このエントリーをはてなブックマークに追加

■この記事を書いた人

avatar

馬場美由紀 (CodeIQ中の人)

エンジニアの勉強会やイベントレポート担当。技術やキャリアに関するエンジニア向けお役立ち情報もお伝えしていきます。面白い情報があったら教えてね!酔ったら記憶なくす記憶飛部所属。Twitter:@miyaq

■関連記事

【鹿児島の熱量を感じろ!】モバイルの未来は地方こそ主役「MOBILE CONFERENCE 2017... エンジニア・デザイナーのためのカンファレンスが鹿児島で開催 ウェブやモバイルのエンジニア・デザイナーのためのカンファレンス「MOBILE CONFERENCE 2017」。鹿児島キャリアデザイン専門学校マルチホールを会場に開催された。 この日はあいにくの雨天にも関わらず、会場はウェブ・モバイ...
ロバート・タージャン氏を直撃取材―IntertrustはLINEのセキュリティ技術に何をもたらすか?... LINEとIntertrust社が共同でセキュリティ・サミットを開催 LINEは、Intertrust Technologies Corporation(本社:カリフォルニア州、以下:Intertrust)と共催で、アプリケーションセキュリティおよびデータプライバシー強化ソリューションの促進を目的...
Webで簡単・効率的にアニメーションを実現できる最新フレームワーク・CSS3アニメーションを紹介... MozillaでWebアニメーションの機能の開発者が登壇 Webでアニメーションというと、数年前まではFlashコンテンツが当たり前に使われていた。 しかしスマートフォンの普及と共に、Webから駆逐され、今はHTML5でアニメーションを表すには、setInterval関数やrequestAnim...
Google AppsとOffice365を使いこなすためのGoogle Apps Script・O... Google AppsとOffice365のそれぞれの強みを知ろう 今回の勉強会タイトルは、「Office真夏の最強ツール決定戦 O1 CLIMAX 14」。Office系アプリケーションの2強、Google AppsとOffice365のそれぞれの強みを知ろうというもの。 これはプロレスフ...
JavaScript関数、Reactive Extensions(Rx)など、話題の関数型プログラミ... 関数型プログラミングは手続き型と同じぐらい古くからある 最初に登壇したのは、日本マイクロソフトのエバンジェリスト、荒井省三さん。「実践F♯関数型プログラミング入門」の著者であり、この本を元に、関数型プログラミングの解説が行われた。 関数型プログラミングは、手続き型と同じぐらい古くからある言語...
マルチプラットフォームで動く「Electron」は本当に使える技術なのか?... Electronはどこがすごいのか? 最初に登壇したのは、Node.js日本ユーザーグループ代表の古川陽介氏。「Electronアプリの作り方」というタイトルでセッションを行った古川氏は、会社でも「Electronを使ってアプリを開発している」と語る。 ▲Node.js 日本ユーザーグループ代表...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ