Japan Computer Emergency Response Team Coordination Center 電子署名者 : Japan Computer Emergency Response Team Coordination Center DN : c=jp, st=tokyo, l=chiyoda-ku, email=office@jpcert.or.jp, o=japan Computer Emergency Response Team Coordination Center, cn=japan Computer Emergency Response Team Coordination Center 日付 : 2014.07.28 14:12:07 +09'00' HTML5 を利用した Web アプリケーションのセキュリティ問題 に関する調査報告書 Rev.2 一般社団法人 JPCERT コーディネーションセンター 2013 年 10 月 30 日 (更新 2014 年 7 月 29 日)
目 次 1. はじめに... 2 2. 調 査 の 目 的 と 方 法... 4 2.1. 調 査 の 目 的... 4 2.2. 調 査 の 方 法... 4 3. HTML5 において 特 に 注 意 が 必 要 な 脆 弱 性... 5 3.1. クロスサイト スクリプティング... 5 3.2. クロスサイト リクエスト フォージェリ... 10 3.3. オープンリダイレクト... 13 3.4. アクセス 制 御 や 認 可 制 御 の 欠 落... 15 4. HTML5 における 注 意 が 必 要 な 機 能... 16 4.1. 新 しく 追 加 された HTML 要 素... 16 4.2. JavaScript API... 23 4.3. XMLHttpRequest... 30 5. HTML5 におけるセキュリティ 機 能... 38 5.1. X-XSS-Protection... 38 5.2. X-Content-Type-Options... 39 5.3. X-Frame-Options... 40 5.4. Content-Security-Policy... 42 5.5. Content-Disposition... 44 5.6. Strict-Transport-Security... 46 6. まとめ... 48 参 考 文 献... 49 付 録... 51 動 作 確 認 ブラウザ... 51 1
1. はじめに HTML5 は 狭 義 には WHATWG および W3C が HTML4 に 代 わる 次 世 代 の HTML として 策 定 を 進 めて いる Web 上 の 文 書 を 記 述 するためのマークアップ 言 語 の 仕 様 であり 広 義 には 通 信 規 格 WebSocket の ような 関 連 規 格 を 含 む Web アプリケーション 記 述 のための 枠 組 みである 日 本 を 含 むアジア 太 平 洋 地 域 に おいて 2012 年 1 月 に 行 われた 調 査 会 社 Evans Data 社 による 調 査 結 果 によると 58%のエンジニアが 新 規 に Web サイトを 構 築 する 際 に HTML5 を 利 用 すると 言 っており 急 速 に 普 及 が 進 みつつある こうした 強 い 市 場 ニーズを 受 けて HTML5 の 実 現 に ブラウザ 提 供 者 を 含 む 多 くのベンダーや 組 織 が 取 り 組 んでおり 標 準 化 機 関 において 定 義 しきれていない 仕 様 の 詳 細 は ブラウザなどにおける 実 現 が 先 行 し 齟 齬 も 生 じ ている HTML5 およびその 周 辺 技 術 の 利 用 により Web サイト 閲 覧 者 ( 以 下 ユーザ)のブラウザ 内 でのデータ 格 納 クライアントとサーバ 間 での 双 方 向 通 信 位 置 情 報 の 取 得 など 従 来 の HTML4 よりも 柔 軟 かつ 利 便 性 の 高 い Web サイトの 構 築 が 可 能 となる 一 方 で それらの 新 技 術 が 攻 撃 者 に 悪 用 された 際 にユーザが 受 ける 影 響 に 関 して 十 分 に 検 証 や 周 知 がされているとは 言 えず セキュリティ 対 策 がされないまま 普 及 が 進 むことが 危 惧 されている 本 調 査 は HTML5 への 移 行 が Web アプリケーションのセキュリティに 及 ぼす 影 響 について 現 時 点 におけ る 知 見 を 可 能 な 限 り 体 系 的 に 整 理 し Web セキュリティ 研 究 者 および Web アプリケーション 開 発 者 のための 基 礎 資 料 を 提 供 することを 目 指 して 実 施 された 調 査 は Web セキュリティの 専 門 家 に 委 託 し HTML5 で 新 たに 追 加 された 機 能 に 関 連 して 作 りこまれる 脆 弱 性 や HTML5 で 新 たに 追 加 されたセキュリティのための 機 能 を Web アプリケーションの 構 築 時 に 活 用 する 方 法 や 留 意 事 項 を 中 心 に 調 査 を 行 った なお HTML5 の 仕 様 の 詳 細 について 実 現 依 存 の 揺 れが 存 在 することを 先 に 述 べたが 本 報 告 書 は 付 録 に 記 載 する 主 要 なブラウザについて 2012 年 8 月 から 2013 年 2 月 にかけて 実 機 で 検 証 した 結 果 に 基 づいている 本 報 告 書 は 次 の 6 章 で 構 成 されている 第 1 章 の 概 要 に 続 き 第 2 章 では 本 調 査 の 目 的 および 方 法 を 記 述 する 第 3 章 では 従 来 から 存 在 した Web アプリケーションの 脆 弱 性 ではあるが 開 発 において 特 に 注 意 すべき 脆 弱 性 について 概 要 と 対 策 を 記 述 する この 中 には HTML5 で 新 たに 可 能 になる 攻 撃 手 法 従 来 は 不 要 だったが HTML5 では 新 たに 必 要 となる Web アプリケーション 開 発 上 の 考 慮 事 項 などが 含 まれる 第 4 章 では HTML5 で 新 たに 追 加 された 機 能 や HTML5 の Web アプリケーションで 使 用 されることの 多 い 機 能 の 観 点 から 脆 弱 性 が 作 り 込 まれる 様 子 と そうした 作 り 込 みを 避 けるための 対 策 を 記 述 する 第 5 章 では ブラウザに 実 装 されているセキュリティ 上 の 機 能 のうち HTML5 の Web アプリケーションを 安 全 に 運 用 するため 特 に 有 効 なものについて これらの 機 能 を 使 用 するための 実 装 方 法 や 設 定 方 法 を 記 述 2
する 第 6 章 に 本 報 告 書 全 体 のまとめを 記 述 する 本 報 告 書 は Web アプリケーションの 開 発 者 に HTML5 を 用 いた 安 全 な Web アプリケーションの 作 り 方 を 議 論 するための 出 発 点 となる 基 本 的 な 資 料 として 利 用 されることを 想 定 している HTML5 を 用 いた Web アプリ ケーションで 使 用 される 機 能 について 焦 点 を 絞 っているため 従 来 からの 基 本 的 な Web アプリケーションセ キュリティに 関 する 技 術 に 関 しては 取 り 扱 っていない 項 目 がある これらの 項 目 に 関 しては 独 立 行 政 法 人 情 報 処 理 推 進 機 構 ( 以 下 IPA)が 発 行 する 安 全 なウェブサイトの 作 り 方 などを 参 照 していただきたい また HTML5 の 仕 様 はなお 流 動 的 な 部 分 が 少 なからず 残 っており その 動 向 とそれに 伴 うセキュリティ 問 題 への 影 響 について 今 後 とも 注 目 していく 必 要 がある さらに これまで 知 られていなかったような HTML5 に 固 有 の 攻 撃 法 が 新 たに 見 つかる 可 能 性 も 否 定 できない したがって 本 報 告 書 は 調 査 時 点 での HTML5 において 調 査 時 点 で 発 見 できたセキュリティ 上 の 問 題 点 と それを 避 けるために 採 用 すべき 基 本 的 原 則 をま とめたものであり 読 者 各 位 からのフィードバックや 新 たな 知 見 を 加 えて 定 期 的 に 見 直 していく 必 要 があるも のと 考 えている 3
2. 調 査 の 目 的 と 方 法 2.1. 調 査 の 目 的 本 調 査 の 目 的 は 急 速 に 普 及 が 進 み 始 めようとしている HTML5 を 利 用 した Web アプリケーションの 開 発 時 に 作 り 込 みが 懸 念 される 脆 弱 性 の 主 なもののうち HTML5 の Web アプリケーションで 使 用 されやすいもの について 発 生 の 仕 組 みと 発 生 を 回 避 するために 取 るべき 基 本 原 則 を 調 査 し 安 全 な Web アプリケーショ ン 開 発 のための 技 術 書 やガイドラインのベースとなる 体 系 的 な 資 料 を 提 供 することである 2.2. 調 査 の 方 法 本 調 査 では 調 査 時 点 において 仕 様 の 骨 格 が 固 まっていた HTML5 の 新 機 能 として 次 の 項 目 を 抽 出 し それぞれについて Web アプリケーションセキュリティの 専 門 家 による 調 査 を 行 い セキュリティ 上 問 題 となる 事 例 と 対 策 をまとめた 追 加 ないし 機 能 が 拡 張 された HTML 要 素 meta a iframe video audio source canvas input button 新 たに 定 義 された JavaScript API WebSocket Web Storage Offline Web Application Web Workers Cross Document Messaging 調 査 では まず 各 項 目 に 対 して 懸 念 されるセキュリティ 問 題 を 抽 出 したうえで 検 討 を 加 え 可 能 な 限 り 検 証 を 行 ったうえで 結 果 をまとめた また 上 記 の 項 目 以 外 についても セキュリティ 上 の 問 題 となる 箇 所 を 調 査 し 追 記 した 4
3. HTML5 において 特 に 注 意 が 必 要 な 脆 弱 性 HTML5 ではブラウザでコンテンツを 表 現 する 機 能 を 拡 張 するため 新 しい 要 素 や 属 性 が 追 加 されている そうした 要 素 や 属 性 の 誤 った 使 用 のために Web サイトに 脆 弱 性 を 作 り 込 むばかりでなく 従 来 はセキュアだ った Web アプリケーションが HTML5 で 拡 張 された 機 能 が 攻 撃 者 に 利 用 可 能 となるために 脆 弱 性 を 帯 びる ようになる 場 合 もある 本 調 査 では そうした 脆 弱 性 の 中 でも 特 にWeb アプリケーション 開 発 者 が 注 意 する 必 要 があるものとして 次 に 挙 げる 4 つの 脆 弱 性 に 焦 点 を 絞 って 詳 細 に 分 析 した クロスサイト スクリプティング クロスサイト リクエスト フォージェリ オープンリダイレクト アクセス 制 御 や 認 可 制 御 の 欠 落 これらの 脆 弱 性 は HTML5 よりも 前 から 注 意 すべきものとされていたものばかりだが 本 章 では これらが HTML5 において 特 有 な 発 現 をする 様 子 と それを 避 けるための 方 法 について 述 べる HTML5 に 依 存 した 脆 弱 性 の 全 体 像 を 知 りたい 読 者 は 0. HTML5 における 注 意 が 必 要 な 機 能 も 参 照 していただきたい HTML5 で 初 めて 可 能 になった 重 要 な 仕 組 みの 一 つに クロスオリジン 通 信 がある オリジンとは コンテンツ の 出 自 を 識 別 するもので RFC6454 The Web Origin Concept で コンテンツを 読 み 込 んだスキームとホ ストとポートの 3 組 であると 定 義 されている 3 組 の 要 素 がすべて 同 じ 場 合 2 つのコンテンツは 同 一 オリジン であり 3 組 の 要 素 の 一 つでも 異 なる 場 合 はクロスオリジンであると 言 う JavaScript などのコンテンツが クロ スオリジンのコンテンツと 行 う 通 信 をクロスオリジン 通 信 と 呼 ぶ 3.1. クロスサイト スクリプティング クロスサイト スクリプティング( 以 下 XSS)とは 利 用 者 が 信 頼 しているWeb サイトに 関 連 して 利 用 者 からは 当 該 サイトが 意 図 的 に 発 行 したかのように 見 えるスクリプトを 当 該 サイトの 意 図 に 反 して ユーザのブラウザ に 送 り 込 み 実 行 する 攻 撃 法 である XSS 攻 撃 に 対 する 脆 弱 性 ( 以 下 XSS の 脆 弱 性 )は Web アプリケーシ ョンや JavaScript において 種 々の 入 力 データを 取 り 込 んで ブラウザによって 実 行 される HTML 文 書 を 動 的 に 生 成 するための 処 理 の 実 現 方 法 が 適 切 でない 場 合 に 入 力 データに 紛 れ 込 んだスクリプトを 見 逃 して HTML 文 書 に 組 み 込 んでしまうことにより 作 り 込 まれる XSS の 脆 弱 性 を 防 ぐためには スクリプトが 解 釈 され るような 文 脈 あるいは 特 定 の 文 字 列 を 挿 入 すると スクリプトが 解 釈 される 文 脈 に 切 り 替 わるような 部 分 を 動 的 に 生 成 する 際 に 特 別 な 注 意 を 払 う 必 要 がある HTML5 で HTML の 構 造 が 複 雑 になったことに 伴 い 従 来 とは 異 なった 経 緯 で 作 り 込 まれうる XSS の 脆 弱 性 として 次 のものが 調 査 の 結 果 抽 出 された (1) 新 要 素 および 新 属 性 により 引 き 起 こされる XSS (2) DOM 操 作 により 引 き 起 こされる XSS 5
(3) XHR Level 2 による XSS (4) Ajax データによる XSS ここでは (1)および(2)の 背 景 事 情 および 対 策 について 簡 単 に 説 明 する (3)については 4.3.1. 意 図 しな いクロスオリジンでのアクセス(クライアント 側 ) を (4)については 4.3.3. Ajax データによる XSS で 解 説 する 3.1.1. 新 要 素 および 新 属 性 により 引 き 起 こされる XSS 従 来 の HTML でも onerror イベントハンドラを 指 定 できる 要 素 があり それらの 要 素 では 属 性 onerror の 値 に JavaScript を 設 定 しエラー 処 理 手 続 きとして 実 行 させることが 可 能 だった そのため 動 的 に 生 成 される HTML 文 書 中 の onerror の 値 に 攻 撃 者 が JavaScript を 埋 め 込 みエラー 状 態 を 引 き 起 こすことができれば XSS 攻 撃 が 可 能 だった HTML5 では 複 数 の 新 しい 要 素 が 追 加 されたが そのうち<video> 要 素 や <source> 要 素 などでは onerror イベントハンドラがサポートされているため 以 下 ののような HTML において は 指 定 された JavaScript が 実 行 される <video onerror="javascript:alert(1)"> <source onerror="javascript:alert(1)"> </video> また 従 来 の HTML でも <input> 要 素 などの 要 素 の 動 的 な 生 成 に 際 しては < > をエスケープしていても value 属 性 の 生 成 で 引 用 符 " ' に 対 するエスケープ 漏 れがあるために XSS 攻 撃 が 可 能 になる しかし 従 来 の HTML では 要 素 中 に 指 定 できるイベントハンドラは イベントを 発 生 させるために マウスを 動 かし たりクリックしたりするユーザの 操 作 が 必 要 な onmouseover や onclick といったものが 多 数 を 占 めた <input value="" onmouseover="alert(1)"> ところが HTML5 で 追 加 された 一 部 の 属 性 と それらユーザの 操 作 が 必 要 なものとを 組 み 合 わせることで ユーザの 操 作 なしに XSS 攻 撃 を 実 行 することが 可 能 となっている 例 えば <input> 要 素 に Web ページが 表 示 された 際 に 当 該 入 力 欄 にフォーカスを 移 動 する autofocus 属 性 が 追 加 されたため 同 要 素 中 の onfocus 属 性 に 指 定 されたイベントハンドラと 組 み 合 わせることでユーザの 操 作 なしに 実 行 されるようになっ た <input value="" autofocus onfocus="alert(1)"> また 従 来 の HTML では 値 にスクリプトを 指 定 することができる 属 性 は on で 始 まる 属 性 名 をもつ 属 性 に 限 られていた ところが HTML5 では formaction 属 性 のように on で 始 まらない 名 前 をもち 値 としてスクリプト 6
を 指 定 できる 属 性 が 追 加 された さらにブラウザ 独 自 の 実 装 や 仕 様 の 追 加 などにより on で 始 まらない 属 性 が 追 加 される 可 能 性 もある このため on で 始 まる 属 性 を 検 出 して その 部 分 だけを 無 害 化 するという 対 策 では XSS の 脆 弱 性 を 防 ぎきれない <form> <button formaction="javascript:alert(1)"> some text </button> </form> 以 上 のことから XSS 攻 撃 の 対 策 としてはユーザの 入 力 から 危 険 な 要 素 や 属 性 を 検 出 するといった 手 法 は 避 け HTML 生 成 時 にエスケープすることを 推 奨 する より 具 体 的 な 対 策 方 法 については IPA 安 全 なウェブサイトの 作 り 方 の 1.5 クロスサイト スクリプティング の 章 などを 参 照 していただきたい 3.1.2. DOM 操 作 により 引 き 起 こされる XSS DOM (Document Object Model)とは Web サーバと 通 信 をすることなく ブラウザ 上 に 表 示 されている HTML 文 書 をブラウザ 上 で 動 作 するスクリプトが 生 成 ないし 更 新 できるようにするために 定 義 された API であ り これにより 手 元 の PC 上 で 稼 働 しているアプリケーションに 近 い 即 応 性 のある Web アプリケーションを 実 現 することができる DOM Based XSS とは 攻 撃 者 が 入 力 データなどに 細 工 して 忍 び 込 ませたスクリプトを ブラウザ 上 で 動 作 している JavaScript などのスクリプトが 不 用 意 に 取 り 込 んで Web ページ 中 に DOM 操 作 を 通 じて 組 み 込 み それがブラウザ 上 で 実 行 されるという 攻 撃 法 である HTML5 を 用 いた Web アプリケーシ ョンは JavaScript が 多 く 使 用 される 傾 向 にあることから DOM Based XSS の 脆 弱 性 が 作 り 込 まれる 場 合 があ る DOM Based XSS 攻 撃 の 対 策 を 3.1.2.1. HTML 生 成 時 は DOM 経 由 で 操 作 を 行 う および 3.1.2.2. URL を 取 り 扱 うときは http あるいは https に 限 定 する で 述 べる 3.1.2.1. HTML 生 成 時 は DOM 経 由 で 操 作 を 行 う DOM Based XSS 攻 撃 に 対 する 対 策 としても HTML 生 成 時 のエスケープ の 原 則 は 有 効 であるが テキ ストノードを 生 成 して DOM 経 由 で 操 作 する 方 がより 網 羅 的 に XSS 攻 撃 の 発 生 を 防 ぐことができる なお JavaScript における HTML 生 成 時 とは innerhtml への 代 入 や document.write によるドキュメントへの 書 き 込 みなど JavaScript 内 で DOM 構 造 が 変 更 されるタイミングのことを 指 す 7
// 脆 弱 な 例 // 外 部 からの 文 字 列 をそのまま HTML として 使 用 することで XSS 攻 撃 が 可 能 である var div = document.getelementbyid("msg"); div.innerhtml = some_text; // 外 部 からの 文 字 列 // 安 全 な 例 // 外 部 からの 文 字 列 をエスケープして HTML を 生 成 function escape_html( s ){ return s.replace( /&/g, "&" ).replace( /</g, "<" ).replace( />/g, "> " ).replace( /"/g, """ ).replace( /'/g, "'" ); } var div = document.getelementbyid("msg"); var escaped_text = escape_html( some_text ); div.innerhtml = escaped_text; // エスケープ 済 み 文 字 列 // 安 全 な 例 ( 推 奨 ) // テキストノードを DOM API を 介 して 操 作 することで 安 全 に HTML を 生 成 var div = document.getelementbyid("msg"); var text = document.createtextnode( some_text ); // テキストノード 生 成 div.appendchild( text ); テキスト 部 分 だけでなく 次 のように 属 性 値 にも 注 意 をする 必 要 がある // 脆 弱 な 例 // 外 部 由 来 の 文 字 列 をそのまま 属 性 値 として 使 用 することで XSS 攻 撃 が 可 能 である var f = document.getelementbyid("form"); f.innerhtml = "<input type='text' value='" + some_text + "'>"; // 安 全 な 例 ( 推 奨 ) // DOM API を 経 由 して 属 性 値 を 設 定 する var f = document.getelementbyid("form"); var elm = document.createelement( "input" ); elm.setattribute( "type", "text" ); elm.setattribute( "value", some_text ); // 属 性 値 の 設 定 8
f.appendchild( elm ); 3.1.2.2. URL を 取 り 扱 うときは http あるいは https に 限 定 する <a> 要 素 の href 属 性 や<iframe> 要 素 などの src 属 性 location.href への 代 入 などにおいて URL を 取 り 扱 う 場 合 に javascript スキームなどの http あるいは https 以 外 の 任 意 のスキームが 攻 撃 者 によって 指 定 され る 場 合 XSS 攻 撃 が 行 われる 可 能 性 がある // 脆 弱 な 例 1 // 外 部 からの 文 字 列 をそのまま URL として 使 用 することで XSS 攻 撃 が 可 能 である // 攻 撃 者 は 変 数 url に "javascript:..." といった 文 字 列 を 指 定 可 能 とする location.href = url; // 脆 弱 な 例 2 // 外 部 からの 文 字 列 をそのまま URL として 使 用 することで XSS 攻 撃 が 可 能 である // 攻 撃 者 は 変 数 url に "javascript:..." といった 文 字 列 を 指 定 可 能 とする var elm = document.getelementbyid("link"); // <a id="link"> var text = document.createtextnode( url ); elm.appendchild( text ); elm.setattribute( "href", url ); // href に"javascript:..."が 設 定 される 外 部 由 来 の 文 字 列 を URL として 使 用 する 場 合 には それが http あるいは https であることが 明 確 な 場 合 に 限 定 することで このような XSS 攻 撃 を 防 ぐことができる // 安 全 な 例 // URL が"http://"または"https://"で 始 まっている 場 合 のみ 処 理 する if( url.match( /^https?: / // ) ){ var elm = document.getelementbyid("link"); // <a id="link"> var text = document.createtextnode( url ); elm.appendchild( text ); elm.setattribute( "href", url ); } ただし URL が http://または https://で 始 まっているものに 限 定 した 場 合 でも location オブジェクトに 代 入 す る 場 合 には XSS 攻 撃 は 発 生 しないがオープンリダイレクトが 発 生 する 可 能 性 がある 詳 細 は 3.3. オープ ンリダイレクト で 解 説 する DOM Based XSS の 脆 弱 性 に 関 しては IPA が 発 行 する IPA テクニカルウォッチ DOM Based XSS に 関 するレポート も 参 照 していただきたい 9
10
3.2. クロスサイト リクエスト フォージェリ クロスサイト リクエスト フォージェリ( 以 下 CSRF) 攻 撃 は 攻 撃 者 が 用 意 したページに 被 害 者 ユーザを 誘 導 することにより 意 図 しない Web サイトから 意 図 しない 操 作 を 被 害 者 ユーザに 行 わせる 攻 撃 手 法 である XHR がクロスオリジンでのリクエストをサポートしたことにより クロスオリジン 通 信 での CSRF 攻 撃 が 可 能 とな った そのため 従 来 は CSRF の 脆 弱 性 がなかった Web サイトにも CSRF 攻 撃 が 行 われる 可 能 性 がある 例 えば ファイルのアップロードを 行 う 機 能 に 対 して 攻 撃 者 が 攻 撃 を 行 うケースについて HTML4 の 機 能 の みを 使 用 した 攻 撃 手 法 と HTML5 の 新 機 能 を 使 用 した 攻 撃 手 法 について 考 える このファイルのアップロ ード 機 能 では 次 のような HTML を 使 用 しておりサーバ 側 ではリファラのチェックが 行 われていないとする 次 のフォームが 送 信 するデータにはトークンのような 情 報 が 見 当 たらないため この 機 能 には CSRF の 脆 弱 性 があると 考 えられる <!-- http://target.example.jp/ 上 のコードの 例 --> <form method="post" action="upload" enctype="multipart/form-data"> <input type="file" name="file"> <input type="submit"> </form> HTML5 の 機 能 を 使 用 しない 場 合 JavaScript を 使 用 してクロスオリジンのリクエストを 送 ることができない そのため 攻 撃 者 は 次 のような ページロード 時 にクロスオリジンで 攻 撃 対 象 の 正 規 サイトに 対 してデータを POST する 悪 意 のある Web サイトを 作 成 し ユーザの 誘 導 を 狙 った CSRF 攻 撃 を 仕 掛 けるとする <!-- 悪 意 ある Web サイト 上 のコードの 例 --> <body onload="document.forms[0].submit();"> <form method="post" action="http://target.example.jp/upload" enctype="multipart/form-data"> <input type="file" name="file"> <input type="submit"> </form> </body> ところが 実 際 にはこの 悪 意 のある Web サイトをユーザが 開 いたとしても 次 のようにファイルの 内 容 ファイ ル 名 ともに 空 のまま 送 信 されることになり 有 意 なデータをサーバへと 送 信 することはできない 11
POST http://target.example.jp/upload Host: target.example.jp... Content-Type: multipart/form-data; boundary=----abcdefg ------abcdefg Content-Disposition: form-data; name="file"; filename="" Content-Type: application/octet-stream ------abcdefg-- 一 方 で HTML5 を 使 用 する 場 合 XHR がクロスオリジン 通 信 に 対 応 したことにより XHR によって POST リ クエストを 送 信 することが 可 能 になり アップロードするファイルの 内 容 を 次 のように JavaScript 内 で 自 由 に 組 み 立 てることができる var xhr = new XMLHttpRequest(); var boundary = '----boundary'; var file="abcd"; // 送 信 するファイルの 内 容 var request; xhr.open( 'POST', 'http://target.example.jp/upload', 'true' ); xhr.setrequestheader( 'Content-Type', 'multipart/form-data; boundary=' + boundary ); xhr.withcredentials = true; // Cookieを 付 与 xhr.onreadystatechange = function(){}; request = '--' + boundary + ' r n' + 'Content-Disposition: form-data; name="file"; ' + ' filename="filename.txt" r n' + 'Content-Type: application/octet-stream r n r n' + file + ' r n' + '--' + boundary + '--'; xhr.send( request ); HTML5 では このように ファイルの 内 容 およびファイル 名 を 自 由 に JavaScript 内 で 組 み 立 てて 攻 撃 対 象 となるサーバへ CSRF の 脆 弱 性 を 使 用 してアップロードすることが 可 能 となる なお XHR でのクロスオリジ ンの 通 信 では 通 常 Cookie は 送 信 されないが withcredentials プロパティを true に 設 定 することで Cookie が 送 信 されるようになる ファイル 名 やファイルコンテンツの 表 示 部 分 に XSS の 脆 弱 性 が 存 在 する 場 合 には これらを 組 み 合 わせての 攻 撃 も 可 能 である 12
自 サイトが XHR のクロスオリジン 通 信 を 許 可 していない 場 合 や クロスオリジン 通 信 に 対 応 していないという 場 合 であっても 攻 撃 者 の 用 意 した 罠 ページからのリクエスト 自 体 は 送 ってこられる 可 能 性 がある そのため 自 サイトに 対 して 送 られたデータを 無 条 件 に 処 理 している 場 合 には 攻 撃 に 使 用 される 可 能 性 がある CSRF 攻 撃 の 対 策 に 他 サイトから 送 信 された 場 合 のリクエストに 含 まれる Origin ヘッダを 確 認 するという 方 法 は 従 来 どおり 自 サイトform から 送 信 されたリクエストによる CSRF 攻 撃 には 対 応 できないため 根 本 的 な 対 策 とはならない XHR を 利 用 した CSRF 攻 撃 への 対 策 としては 従 来 の CSRF 攻 撃 の 対 策 と 同 様 トークン などの 秘 密 情 報 を<input type="hidden"> 要 素 に 含 めるなどの 手 段 を 用 いる <body onload="document.forms[0].submit();"> <form method="post" action="http://target.example.jp/upload" enctype="multipart/form-data"> <input type="file" name="file"> <input type="hidden" name="token" value="9cf89bc43b1b6fea399a..."> <input type="submit"> </form> </body> CSRF 攻 撃 のより 具 体 的 な 対 策 方 法 については IPA 安 全 なウェブサイトの 作 り 方 の 1.6 CSRF(クロス サイト リクエスト フォージェリ) の 章 などを 参 照 していただきたい 13
3.3. オープンリダイレクト Web アプリケーションで 入 力 値 などのデータに 応 じてリダイレクト 先 を 変 えたい 場 合 がある この 時 不 用 意 な Web アプリケーションの 作 り 方 をすると リダイレクト 先 を 攻 撃 者 が 自 在 に 変 更 して 被 害 者 を 悪 意 ある Web サイトに 誘 導 することが 可 能 になってしまう この 脆 弱 性 をオープンリダイレクトと 呼 ぶ オープンリダイレ クトはWeb サイトそのものに 被 害 を 及 ぼすわけではないが そのWeb サイトのドメイン 名 を 使 用 して 悪 意 ある サイトへユーザが 誘 導 されるなど Web サイトの 信 用 問 題 に 繋 がるため 対 策 が 必 要 である location.hash を 使 用 してリダイレクト 先 を 指 定 する 手 法 では リダイレクト 先 URL がサーバ 側 のログに 記 録 されないため オ ープンリダイレクトが 存 在 する 場 合 には アクセス 先 が 把 握 できず 後 から 状 況 を 確 認 できない 可 能 性 がある ため 特 に 注 意 が 必 要 である オープンリダイレクトを 発 生 させないためには リダイレクト 先 URL を 外 部 からの 入 力 によって 生 成 するので はなく 事 前 に 固 定 のリストとしてプログラム 内 で 持 っておくことが 最 も 有 効 である #!/usr/bin/perl # 安 全 な 例 # リダイレクト 先 (/foo /bar /baz)を 事 前 に 固 定 して 保 持 use URI::Escape; my $index = uri_unescape( $ENV{QUERY_STRING} '' ); my $pages = { foo=>'/foo', bar=>'/bar', baz=>'/baz' }; my $url = $pages->{$index} '/'; print "Status: 302 Found n"; print "Location: $url n n"; リダイレクト 先 の URL を 事 前 に 固 定 できず 動 的 に 生 成 せざるをえない 場 合 には 任 意 サイトへリダイレクトさ れないように 生 成 後 のリダイレクト 先 URL のドメインが 想 定 される 範 囲 に 含 まれるかどうかチェックする 必 要 がある Web アプリケーションで 動 的 に 生 成 した URL にリダイレクトするための 代 表 的 な 3 種 類 の 方 法 とそれぞ れに 関 連 する 注 意 事 項 を 次 に 述 べる 3.3.1. HTTP ステータスコードとして 301 または 302 などを 返 し リダイレクト 先 を Location ヘッダで 指 定 この 方 法 によるリダイレクトでは オープンリダイレクトだけでなく HTTP ヘッダインジェクションにも 注 意 する 必 要 がある 14
#!/usr/bin/perl # 脆 弱 な 例 # オープンリダイレクトだけでなく HTTP ヘッダインジェクションもある use URI::Escape; my $url = uri_unescape( $ENV{QUERY_STRING} '' ); print "Status: 302 Found n"; print "Location: /$url n n"; 3.3.2. JavaScript による location オブジェクトへの 代 入 この 方 法 によるリダイレクトでは スキームを http あるいは https に 限 定 する 必 要 がある 任 意 の JavaScript を 参 照 するスキームにリダイレクトされて XSS 攻 撃 が 行 われる 可 能 性 があるからである 詳 細 は 3.1.2. DOM 操 作 により 引 き 起 こされる XSS を 参 照 していただきたい // 脆 弱 な 例 1 // 外 部 由 来 の 文 字 列 をそのまま URL として 使 用 することで XSS 攻 撃 が 可 能 である // 攻 撃 者 は 変 数 url に "javascript:..." といった 文 字 列 を 指 定 可 能 var url = decodeuricomponent( location.hash.substring(1) ); location.href = url; // 脆 弱 な 例 2 // 外 部 由 来 の 文 字 列 の 確 認 が 不 十 分 なため オープンリダイレクトにつながる // 攻 撃 者 が / example.com/ のような 形 式 で URL を 指 定 することで 任 意 の // サイトへリダイレクト 可 能 var url = decodeuricomponent( location.hash.substring(1) ); // URL の 先 頭 が/ 2 文 字 目 が/ 以 外 であることをチェック if( url.match( /^ /[^ /]/ ) ) { location.href = url; } // 安 全 な 例 // リダイレクト 先 を 固 定 のリストとして 保 持 var index = location.hash.substring(1) 0; var pages = [ '/foo', '/bar', '/baz' ]; // リダイレクト 先 のリスト if( 0 <= index && index < pages.length ){ location.href = pages[ index ]; } 15
3.3.3. <meta http-equiv= Refresh >を 用 いたリフレッシュによるリダイレクト ユーザからの 入 力 をもとに 動 的 に 生 成 した URL を 用 いて この 方 法 でリダイレクトする 場 合 には オープンリ ダイレクトを 防 ぐことが 困 難 である したがって<meta>リフレッシュによるリダイレクトは 使 用 しないことが 望 ま しい 詳 細 については 4.1.2. <meta http-equiv> で 述 べる 3.4. アクセス 制 御 や 認 可 制 御 の 欠 落 一 般 には 公 開 しない 個 人 情 報 を 扱 う Web サイトにアクセス 制 御 や 認 可 制 御 の 不 備 があると 情 報 漏 えいを 引 き 起 こす 可 能 性 がある HTML5 で 追 加 された 機 能 を 攻 撃 者 が 利 用 すると 従 来 はアクセスすることができな かった 情 報 がアクセス 可 能 になる 場 合 がある 例 えば Ajax では 攻 撃 者 の 用 意 した 悪 意 ある Web サイトに<script> 要 素 の src 属 性 を 使 用 して 秘 密 情 報 を 含 む JSON を 読 み 込 ませ JavaScript として 解 釈 させることにより JSON 内 の 秘 密 情 報 にアクセスするな どの 取 り 扱 うデータに 含 まれる 秘 密 情 報 を 窃 取 するための 様 々な 攻 撃 手 法 が 見 つかっている また 従 来 は 許 されなかったクロスオリジン 通 信 を 利 用 して 本 来 はアクセスさせたくない 第 三 者 が 秘 密 情 報 にアクセス する 可 能 性 もある Web サイトの 中 には これらの HTML5 の 機 能 を 考 慮 しておらず 不 適 切 に 設 計 し 運 用 しており 開 示 制 限 すべき 情 報 を 公 開 しているものがある 一 般 には 公 開 しない 秘 密 情 報 を 扱 う Web サイト を HTML5 を 用 いて 構 築 する 場 合 には 適 切 にアクセス 制 御 や 認 可 制 御 を 実 装 する 必 要 がある その 対 策 の 詳 細 は 攻 撃 に 使 用 される 機 能 により 大 きく 異 なるため 第 4 章 HTML5 における 注 意 が 必 要 な 機 能 で 述 べる 16
4. HTML5 における 注 意 が 必 要 な 機 能 本 章 では 次 に 挙 げる HTML5 で 新 たに 追 加 された 機 能 や 使 用 されることの 多 い HTML5 の 機 能 ごとに 脆 弱 性 が 作 り 込 まれる 様 子 と そうした 作 り 込 みを 避 けるための 対 策 を 解 説 する 新 しく 追 加 された HTML 要 素 JavaScript API XMLHttpRequest 4.1. 新 しく 追 加 された HTML 要 素 本 節 では HTML5 で 追 加 変 更 されたものを 中 心 に HTML 要 素 属 性 ごとに 利 用 にあたりセキュリティ 上 注 意 すべき 点 について 解 説 する 4.1.1. <meta charset> <meta charset>は HTML ファイル 内 で 文 字 エンコーディングを 指 定 するために 使 用 される <head> </head> <meta charset="utf-8"> 埋 め 込 んだ HTML の 特 殊 文 字 を 文 字 エンコーディングにより 隠 すことで UTF-7 などの 文 字 エンコーディン グを 使 用 した XSS 攻 撃 が 可 能 になる したがって 文 字 エンコーディング 指 定 の 不 正 な 変 更 を 防 ぐことが 重 要 である そのため 文 字 エンコーディング 名 は HTTP レスポンスヘッダにおいて 明 確 に 指 定 することを 原 則 とし HTML 内 での<meta charset>による 指 定 は コンテンツをローカルに 保 存 した 場 合 の 文 字 化 けの 防 止 のためなど 補 助 的 な 使 途 だけに 限 ることを 推 奨 する 文 字 エンコーディング 名 の 指 定 は ブラウザ 側 が 正 しく 判 断 できるよう ハイフンあるいはアンダースコアも 含 めて 誤 記 のない utf-8 Shift_JIS EUC-JP など のような 正 確 な 表 記 によることが 求 められる 文 字 エンコーディングの 指 定 にレスポンスヘッダが 使 用 できず<meta charset>で 指 定 しなければならない 場 合 には <meta charset>より 先 行 する 部 分 に 外 部 からの 入 力 を 表 示 してはならない なぜなら 本 来 の <meta charset>の 前 に 攻 撃 者 が 挿 入 した 偽 の<meta charset>をブラウザが 解 釈 した 場 合 文 字 エンコー ディングの 認 識 が Web サイト 側 とブラウザ 側 とで 食 い 違 いを 生 じ XSS 攻 撃 が 行 われる 可 能 性 がある 次 の 例 では 攻 撃 者 が <title> 要 素 として UTF-7 で 表 記 した </title><meta charset="utf-7"> という 文 字 列 を 指 定 している この 例 では JavaScript は 動 かないが 他 の 手 法 を 組 み 合 わせれば XSS 攻 撃 が 行 われ る 可 能 性 がある 17
<title> +/v8apa-/title+ad4apa-meta charset+ad0aig-utf-7+aciapg- </title> <meta charset="utf-8">... <div>+adw-script+ad4-alert(1);+adw-/script+ad4-</div> 4.1.2. <meta http-equiv> <meta http-equiv>は 一 般 的 には HTML ファイル 内 で HTTP レスポンスヘッダを 補 完 するために 使 用 される すなわち<meta http-equiv="name" content="content">の 形 式 は HTTP レスポンスヘッダに name: content というフィールドを 追 加 したのと 同 じ 働 きをする 本 節 では 次 のような 構 文 により 指 定 される meta リ フレッシュと 呼 ばれるリダイレクト 機 能 に 関 して 述 べる <!-- http://example.jp/ へのリダイレクトの 例 --> <meta http-equiv="refresh" content="0;url=http://example.jp/"> この 例 では 0 秒 後 すなわち 即 刻 に url= で 指 定 された http://example.jp/ にリダイレクトされる リダイレク ト 先 URL を 指 定 する 部 分 に 攻 撃 者 が 自 由 に 文 字 列 を 挿 入 できる 場 合 javascript スキームへのリダイレクト による XSS 攻 撃 や 任 意 サイトへのリダイレクト(オープンリダイレクト)の 攻 撃 などにつながる 可 能 性 がある 例 えば 次 のような javascript スキームへのリダイレクトは Google Chrome や Opera Safari のブラウザで は javascript スキームで 指 定 されたスクリプトが 元 ページ 上 で 動 作 するため XSS 攻 撃 が 発 生 する 可 能 性 がある <!-- javascript スキーム へのリダイレクトの 例 --> <meta http-equiv="refresh" content="0;url=javascript:alert(1)"> また 次 の 例 のように content 属 性 の 値 に ;url= が 複 数 含 まれる 場 合 Internet Explorer 6 および 7 では 末 尾 の ;url= 以 降 の 文 字 列 が 示 す URL にリダイレクトされる <meta http-equiv>によるリダイレクトで 攻 撃 者 がリダイレクト 先 URL を 自 由 に 指 定 できる 状 況 では リダイレクト 先 ドメインを 制 限 することは 難 しく オープ ンリダイレクトを 防 ぐことは 困 難 である したがって <meta http-equiv>によるリダイレクトを 使 用 する 場 合 は 攻 撃 者 がリダイレクト 先 URL を 自 由 に 指 定 できないように 固 定 値 とすることが 望 ましい <!-- 意 図 しないサイトへのリダイレクトの 例 --> <meta http-equiv="refresh" content="0;url=http:example.jp/;url=http://evil.example.jp/"> 4.1.3. <a ping> <a> 要 素 の ping 属 性 は ユーザがリンクをクリックしたことを 通 知 すべき 通 知 先 リソースの URL を 指 定 するた めの 属 性 である 18
<!-- リンクのクリックで ping の URL へ 通 知 される --> <a href="http://example.jp/" ping="http://example.jp/ping"> example.jp へのリンク </a> ping 属 性 による 通 知 に 対 応 しているブラウザは Google Chrome および Safari である 通 知 先 リソースとし ては http および https スキームの URL のみが 有 効 で それ 以 外 の 例 えば"javascript:alert(1)"のようなスキ ームは 無 視 される 4.1.4. <iframe sandbox> <iframe> 要 素 では sandbox 属 性 によって iframe 内 のコンテンツに JavaScript の 実 行 禁 止 などの 条 件 を 指 定 することができ 信 頼 できないコンテンツを Web サイト 内 に 埋 め 込 む 場 合 などに 利 用 される <!-- sandbox 属 性 をもつ iframe の 例 --> <!-- script の 実 行 や form の submit などが 禁 止 される --> <iframe sandbox src="http://evil.example.com/"></iframe> sandbox 属 性 が 付 与 された iframe 内 のコンテンツに 対 し ブラウザは プラグインの 実 行 JavaScript の 実 行 form の 実 行 トップレベルウィンドウへの 干 渉 を 制 限 し コンテンツを 独 自 オリジンとして 取 り 扱 う sandbox 属 性 を 持 つ<iframe> 要 素 を 用 いて Web サイトを 埋 め 込 むことで その Web サイトの JavaScript の 実 行 を 禁 止 できるが 自 身 のページを<iframe sandbox>で 読 み 込 むようにしても XSS 攻 撃 などを 防 ぐ 対 策 にはならない XSS の 脆 弱 性 などが 存 在 するページがあれば 攻 撃 者 が iframe を 用 いず 脆 弱 性 を 持 つページを 直 接 開 くことで 攻 撃 ができるからである sandbox 属 性 では 値 として iframe 内 のコンテンツに 与 える 条 件 を 指 定 することもできる <!-- sandbox 属 性 をもつ iframe の 例 --> <!-- script の 実 行 は 許 可 される --> <iframe sandbox="allow-scripts" src="http://evil.example.com/"> </iframe> sandbox 属 性 に 複 数 の 値 を 組 み 合 わせて 指 定 する 場 合 には 各 値 をスペースで 区 切 って 列 記 する <!-- sandbox 属 性 をもつ iframe の 例 --> <!-- script の 実 行 form の 実 行 は 許 可 される --> <iframe sandbox="allow-scripts allow-forms" src="http://evil.example.com/"></iframe> 19
また <iframe>などによるフレーム 内 でページが 表 示 されることを 避 けるために これまではフレームバステ ィングと 呼 ばれる JavaScript コードが 利 用 されることがあった しかしながら ページが<iframe sandbox>で 読 み 込 まれた 場 合 には JavaScript が 動 作 しないため フレームバスティングは 正 常 に 動 作 せず ページが 表 示 されてしまう したがって クリックジャッキングを 防 止 するためには フレームバスティングではなく X-Frame-Options ヘッダを 使 用 する 必 要 がある 詳 細 については 5.3. X-Frame-Options で 解 説 する 4.1.5. <video> <video> 要 素 は <img> 要 素 によって 画 像 を 埋 め 込 むのと 同 様 に HTML 内 に 直 接 再 生 可 能 な 動 画 を 埋 め 込 むために 使 用 される Internet Explorer 9 および 10 では <video> 要 素 の onerror イベントが 動 作 するた め XSS 攻 撃 が 行 われる 可 能 性 がある <!-- video 要 素 による XSS 攻 撃 の 例 --> <video onerror="javascript:alert(1)"> <source src="#"> </video> 4.1.6. <audio> <audio> 要 素 は <img> 要 素 によって 画 像 を 埋 め 込 むのと 同 様 に HTML 内 に 直 接 再 生 可 能 な 音 声 を 埋 め 込 むために 使 用 される Internet Explorer 9 および 10 では <audio> 要 素 の onerror イベントが 動 作 するた め XSS 攻 撃 が 行 われる 可 能 性 がある <!-- audio 要 素 による XSS 攻 撃 の 例 --> <audio onerror="javascript:alert(1)"> <source src="#"> </audio> 4.1.7. <source> <source> 要 素 は <video> 要 素 や<audio> 要 素 の 中 に 置 いて 提 供 できるメディアソースを 指 定 するために 使 用 される Firefox Google Chrome Opera Safari Android 標 準 ブラウザの 各 ブラウザでは <source> 要 素 の onerror イベントが 動 作 するため XSS 攻 撃 が 行 われる 可 能 性 がある 20
<!-- video 要 素 と source 要 素 による XSS 攻 撃 の 例 --> <video> <source onerror="javascript:alert(1)"> </video> <!-- audio 要 素 と source 要 素 による XSS 攻 撃 の 例 --> <audio> <source onerror="alert(1)"> </audio> 4.1.8. <canvas> <canvas> 要 素 は JavaScript が 図 形 を 描 画 するための 描 画 領 域 (キャンバス)を 定 義 するために 使 用 され る Canvas では JavaScript から 自 由 に 画 像 を 読 み 書 きできるが オリジンが 異 なるスクリプトが 書 いた 画 像 の 読 み 取 りを 制 限 するために 内 部 に origin-clean と 呼 ばれるフラグを 持 っている origin-clean フラグは 初 期 状 態 では true に 設 定 されているが オリジンの 異 なる 画 像 が 描 画 された 時 点 で 自 動 的 に false に 設 定 される origin-clean がfalse になると todataurl メソッド getimagedata メソッド toblob メソッドを 用 いてCanvas 内 の 画 像 を JavaScript から 読 み 出 すことができない // http://example.jp/ 上 のコード // 異 なるオリジンの 画 像 の 読 み 込 みでセキュリティ 例 外 が 発 生 する <img id="img" src="http://other.example.jp/sample-image.png"> <canvas id="canvas"></canvas>... var img = document.getelementbyid( "img" ); var canvas = document.getelementbyid( "canvas" ); var ctx = canvas.getcontext( "2d" ); ctx.drawimage( img, 0, 0 ); alert( canvas.todataurl( "image/png" ) ); // 例 外 が 発 生 この 仕 組 みにより Canvas の 利 用 においてはセキュリティ 上 の 問 題 は 発 生 しにくくなっている 一 方 で オリジンを 超 えて 画 像 を 利 用 したいという 要 望 に 対 応 するため Firefox および Google Chrome Safari 6 Opera では XHR によるクロスオリジン 通 信 と 同 様 Cross-Origin Resource Sharing (CORS)の 仕 組 みに 従 い 画 像 提 供 側 が Access-Control-Allow-Origin レスポンスヘッダを 付 与 することで アクセスで きるようにしている すなわち other.example.jp 上 で 画 像 のレスポンスヘッダにおいて リソースの 読 み 取 り を 許 可 するオリジンを Access-Control-Allow-Origin レスポンスヘッダによって 次 のように 指 定 する 21
Date: Tue, 1 Jan 2013 09:00:00 GMT Access-Control-Allow-Origin: http://example.jp Content-Length: 28400 Content-Type: image/png 同 時 に example.jp 上 でも Canvas への 転 送 元 となる<img> 要 素 に crossorigin 属 性 を 与 える 必 要 があ る // http://example.jp/ 上 のコード // 異 なるオリジンの 画 像 を 読 み 込 む // セキュリティ 例 外 は 発 生 しない <img id="img" src="http://other.example.jp/sample-image.png" crossorigin> <canvas id="canvas"></canvas>... var img = document.getelementbyid( "img" ); var canvas = document.getelementbyid( "canvas" ); var ctx = canvas.getcontext( "2d" ); ctx.drawimage( img, 0, 0 ); alert( canvas.todataurl( "image/png" ) ); // 例 外 は 発 生 せず crossorigin 属 性 のついた<img> 要 素 では どのページからリクエストが 発 行 されたかのオリジンを 示 す Origin リクエストヘッダが 画 像 のリクエスト 時 に 付 与 される サーバ 側 は どのオリジンであればコンテンツに ア ク セ ス 可 能 か を Access-Control-Allow-Origin レ ス ポ ン ス ヘ ッ ダ で 指 定 す る 上 の 例 で は http://example.jp をオリジンとする JavaScript であれば 画 像 にアクセスすることが 可 能 である 画 像 のレスポ ンスヘッダに Access-Control-Allow-Origin が 存 在 しない 場 合 や Access-Control-Allow-Origin に 自 コンテ ンツのオリジンが 含 まれていない 場 合 は Canvas に 描 画 された 画 像 データにアクセスすることはできない 特 定 のオリジンからのみ 画 像 コンテンツへのアクセスを 許 可 したい 場 合 には Origin リクエストヘッダおよび Access-Control-Allow-Origin レスポンスヘッダの 指 定 に 加 えて 従 来 どおり Cookie を 使 用 しなければなら ない Cookie を 使 用 せず Origin リクエストヘッダおよび Access-Control-Allow-Origin レスポンスヘッダの 指 定 だけでは 攻 撃 者 が ブラウザの 替 わりにツールなどを 使 用 して 任 意 の Origin リクエストヘッダを 付 与 し たリクエストを 送 信 することにより JavaScript を 経 由 せずに 直 接 画 像 にアクセスすることが 可 能 だからであ る Access-Control-Allow-Origin: * という 指 定 は 全 てのオリジンからの JavaScript が 画 像 にアクセス 可 能 な ことを 意 味 しており 画 像 を 第 三 者 に 見 せたくない 場 合 にはこの 指 定 をしてはいけない 攻 撃 者 が crossorigin 属 性 のついた<img> 要 素 を 使 用 した 罠 ページを 用 意 すれば 罠 ページ 内 の JavaScript から 画 22
像 にアクセスできるからである また Cookie を 使 用 した 場 合 Access-Control-Allow-Origin: * という 指 定 をすることは 仕 様 上 禁 止 されている Access-Control-Allow-Origin: * という 指 定 は アクセス 保 護 などを 必 要 としない 完 全 に 公 開 するコンテンツ にのみ 使 用 し それ 以 外 は Access-Control-Allow-Origin: http://example.jp のように 許 可 するオリジンを 指 定 する 4.1.9. <input> <input> 要 素 は HTML5 において 大 幅 に 機 能 が 強 化 され 例 えば<input type="email">などの 属 性 を 指 定 することで メールアドレスの 形 式 の 入 力 データだけを 受 け 付 けることが 簡 単 に 実 現 できる また <input type="text" pattern="^[0-9a-fa-f]$">のように 開 発 者 が 任 意 のパターンを 指 定 して パターンにマッチする 入 力 だけに 制 限 することもできる 従 来 であれば 入 力 内 容 を 確 認 する JavaScript が 必 要 とされた 場 面 で JavaScript を 使 わずに 同 等 のことができる この 機 能 は コード 量 の 低 減 だけでなく エラーメッセージが 統 一 された 表 示 になるなどの 利 点 をもたらす ただし 攻 撃 者 はブラウザ 内 で HTML を 変 更 して <input> 要 素 で 指 定 されたパターンに 合 致 しないリクエス トを 送 信 することができるので 細 工 された 入 力 データを<input> 要 素 での 入 力 制 限 によって 完 全 に 排 除 で きると 考 えてはいけない <input> 要 素 では < > がエスケープされていても value 属 性 の 引 用 符 " ' のエスケープが 漏 れてい ると XSS 攻 撃 の 可 能 性 がある そのような XSS 攻 撃 の 多 くは 従 来 は onmouseover や onclick といったイ ベントハンドラとして 指 定 された JavaScript によって 実 行 されていたので 攻 撃 が 実 際 に 行 われるにはユー ザ 自 身 の 操 作 が 必 要 だった <!-- ユーザの 操 作 が 必 要 な 攻 撃 の 例 --> <input value="" onmouseover="alert(1)"> HTML5 では<input> 要 素 に 自 動 でフォーカスを 移 動 する autofocus 属 性 が 追 加 されたため これを 次 の 例 のように onfocus イベントハンドラと 組 み 合 わせることで ユーザの 操 作 なしに JavaScript の 実 行 が 可 能 とな った <!-- ユーザの 操 作 が 不 要 な 攻 撃 の 例 --> <input value="" autofocus onfocus="alert(1)"> また 生 成 する HTML へのイベントハンドラの 挿 入 を 禁 ずるために on で 始 まる 属 性 を 検 出 する 対 策 をとる 場 合 があったが HTML5 では formaction 属 性 のように javascrpt スキームを 値 にできる on で 始 まらない 要 素 や 属 性 が 追 加 されたため このような 対 策 では 不 十 分 である 23
<!-- on で 始 まらない 属 性 を 利 用 した 攻 撃 の 例 --> <form> <input type="button" formaction="javascript:alert(1)"> </form> 4.1.10. <button> <button> 要 素 にも<input> 要 素 同 様 formaction 属 性 のように on で 始 まらない 要 素 や 属 性 が HTML5 で 追 加 されたため on で 始 まる 属 性 を 検 出 するという XSS 攻 撃 対 策 は 不 十 分 である <form> <button formaction="javascript:alert(1)"> some_text </button> </form> 4.2. JavaScript API 近 年 の Web ブラウザは 様 々な 機 能 を JavaScript から 呼 び 出 すための API を 実 装 している 本 節 ではそ れらのうち セキュリティ 上 注 意 すべきものについて 述 べる なお XMLHttpRequest(XHR)については 注 意 すべき 事 項 が 多 いため 4.3. XMLHttpRequest にて 別 途 取 り 上 げる 4.2.1. WebSocket WebSocket は Web ブラウザとサーバ 間 での 双 方 向 通 信 を 実 現 するための 機 能 である WebSocket を 利 用 する 場 合 の 典 型 的 な JavaScript コードを 次 に 示 す var ws = new WebSocket( "ws://example.jp/" ); ws.onopen = function(){ console.log( 'connected' ); }; ws.onmessage = function( evt ){ console.log( evt.data ); }; ws.onclose = function(){ console.log( 'closed' ); }; 24
ws.send( 'data' ); ws URI スキームでは http スキームと 同 様 に 通 信 内 容 が 暗 号 化 されない TLS で 暗 号 化 された 通 信 経 路 を 利 用 したい 場 合 には wss URI スキームを 使 用 する var ws = new WebSocket("wss://example.jp:443/ "); 盗 聴 や 改 ざんによる 影 響 の 大 きい 重 要 な 情 報 の 送 受 信 には wss の 使 用 が 推 奨 される ws wss URI スキームとも 接 続 時 のハンドシェイク 時 に http および https スキームと Cookie を 共 有 するこ とに 注 意 が 必 要 である すなわち http://example.jp/ の Web ページへの 通 常 のアクセス 時 に 発 行 された Cookie は ws://example.jp:8080/ や wss://example.jp:8081/ などの 利 用 においてもハンドシェイクのリ クエスト 時 にサーバへ 送 信 される GET / HTTP/1.1 Host: example.jp Connection: Keep-Alive HTTP/1.1 200 OK Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 2524 Content-Type: text/html; charset=utf-8 Set-Cookie: session=12afe9bd34e5a202; path=/... GET /websocket HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: example.jp Origin: http://example.jp Sec-WebSocket-Key: mu6obz5gkwugzqbj2otwfq== Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: chat, superchat Cookie: session=12afe9bd34e5a202 HTTP/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: IsCRPjZ0Vshy2opkKOsG2UF74eA= 25
Sec-WebSocket-Protocol: chat... secure フラグを 付 与 して 発 行 された Cookie は https と wss URI スキームの 間 で 共 有 される すなわち https://example.jp/ へ の ア ク セ ス 時 に secure フ ラ グ を 付 与 し て 発 行 さ れ た Cookie は wss://example.jp:8081/などの 利 用 においてもハンドシェイクのリクエスト 時 にサーバへと 送 信 される また JavaScript からのアクセスを 禁 ずるために httponly フラグを 付 与 して 発 行 された Cookie は http およ び https スキームの 場 合 と 同 様 に ws および wss URI スキームにおいても 送 信 される 4.2.2. Web Storage Web Storage あるいは DOM Storage は JavaScript からアクセス 可 能 なデータをクライアント 側 に 保 存 す るための 仕 組 みである データがセッション 終 了 時 に 破 棄 される sessionstorage と ブラウザ 終 了 後 も 永 続 的 にデータを 保 持 し 続 ける localstorage がある いずれの 場 合 も 読 み 込 みおよび 書 き 込 みは 同 一 のオリ ジンに 制 限 されている このため http のページ 内 から 書 き 込 まれた Web Storage の 内 容 は https のページ からアクセスできない Cookie では httponly フラグを 与 えることで JavaScript からの 読 み 取 りを 防 ぐことができるが Web Storage には JavaScript からの 読 み 取 りを 防 ぐための 仕 組 みがない そのため Web Storage に 秘 密 情 報 を 保 存 す る 場 合 には Content Security Policy を 併 用 するなどの 対 策 を 行 う 必 要 がある 4.2.2.1. sessionstorage sessionstorage はブラウザのウィンドウまたはタブが 開 かれている 間 データを 保 持 する sessionstorage の 内 容 は ページのリロードや 他 のページなどの 表 示 などがあっても 維 持 され ブラウザのウィンドウまたはタ ブを 閉 じた 時 に 廃 棄 される また 他 のウィンドウまたはタブの sessionstorage の 内 容 は 読 み 込 みも 書 き 込 みもできない sessionstorage は iframe または frame で 表 示 されている 同 一 オリジンの 各 コンテンツ 間 で 共 有 される Internet Explorer 8 および 9 では - iframe または frame 間 では sessionstorage が 共 有 されない - http および https で sessionstorage が 分 離 されずに 共 有 される(Internet Explorer 8 のみ) という 問 題 が 既 知 となっている 4.2.2.2. localstorage localstorage は ブラウザを 終 了 させても 明 示 的 に 削 除 しない 限 り 永 続 的 にデータを 保 持 し 続 ける ただし Internet Explorer 8 および 9 には 次 の 問 題 があることが 知 られている 26
- メニューの ファイル 新 しいセッション から 立 ち 上 げた Internet Explorer とは localstorage が 共 有 さ れないことがある - http と https の 間 で sessionstorage が 分 離 されずに 共 有 される(Internet Explorer 8 のみ) また Safari では Mac 版 iphone 版 とも プライベートブラウズ 時 には localstorage への 書 き 込 みが 一 切 保 存 されない 例 えば 次 のコードをプライベートブラウズ 機 能 が 有 効 になった 状 態 で 実 行 してもデータは 取 得 できない localstorage.setitem( "foo", "value" ); alert( localstorage.getitem( "foo" ) ); Web Storage に 保 存 されたデータの 有 効 期 間 は Cookie にて 管 理 される Web アプリケーションとしてのセ ッションとは 一 致 しない そのため Web アプリケーションがログイン 機 構 を 持 ち ユーザに 固 有 の 情 報 を Web Storage に 格 納 する 場 合 明 示 的 にそれを 削 除 しない 限 りログアウト 後 もアクセス 可 能 である 例 えば ログイン 後 に (a) localstorage にデータを 保 存 したり (b) localstorage に 保 存 されているデータを 使 った りする 処 理 を 行 う Web アプリケーションがあった 場 合 ユーザ X がログイン 後 に(a)の 処 理 で localstorage に 保 存 されたデータを 同 じ 端 末 のブラウザを 共 用 しているユーザ Y がログイン 後 に(b)の 処 理 で 参 照 する 可 能 性 がある こうした 問 題 を 避 けるため ログアウト 時 に Web Storage に 格 納 したデータを 削 除 するなどし て 別 のユーザからアクセスされないようにしておくことが 望 ましい 4.2.3. Offline Web Application Offline Web Application 機 能 は 指 定 したリソースをオフラインキャッシュとしてデバイス 上 に 保 存 しておくこ とで ネットワークがオフラインになった 後 にも Web アプリケーションが 利 用 できるようにするための 機 能 であ る オフラインキャッシュを 利 用 すると 長 期 にわたりユーザのデバイス 上 に 保 存 されたリソースが 使 用 されること になる そのため 例 えば 暗 号 化 されていない Wi-Fi のような 信 頼 できないネットワークを 利 用 している 端 末 に 対 して 攻 撃 者 が 中 間 者 攻 撃 により 汚 染 したリソースをオフラインキャッシュとして 保 存 させた 場 合 そのネ ットワークを 離 れた 後 も 長 く 汚 染 されたリソースをユーザが 使 い 続 けることになり 結 果 として 例 えば 秘 密 情 報 が 攻 撃 者 のサイトに 送 信 されるなどの 被 害 の 可 能 性 も 考 えられる そのため 秘 密 情 報 などの 重 要 な 情 報 を 扱 う 場 合 は 当 該 リソースを 持 つサイト 全 体 に 対 して HTTPS を 利 用 することが 望 ましい 4.2.4. Web Workers Web Workers は JavaScript においてバックグラウンドで 並 列 処 理 を 行 うための 機 能 である Web Workers を 利 用 する 場 合 の 典 型 的 な JavaScript コードを 次 に 示 す 27
var worker = new Worker( 'worker.js' ); worker.onmessage = function( evt ){ console.log( evt.data ); }; worker.postmessage( 'ping' ); worker.js は バックグラウンドで 動 作 する JavaScript である 典 型 的 な 例 を 次 に 示 す onmessage = function( evt ){ if( evt.data == "ping" ){ postmessage( 'pong' ); } }; Web Workers において 外 部 のスクリプトファイルを 読 み 込 む 方 法 として Worker コンストラクタ SharedWorker コンストラクタ importscripts メソッドがある これらで 読 み 込 む URL を 攻 撃 者 が 任 意 に 指 定 できないように 注 意 しなければならない // Worker コンストラクタの 危 険 な 例 var src = location.hash.substring(1); var worker = new Worker( src ); 上 のコードが http://example.jp/#worker.js の URL にアクセスすると URL 中 の# 以 降 の worker.js が Web Workers のソースとして 使 用 される 現 在 のところ Worker コンストラクタのソース URI は 同 一 オリジンに 限 定 されているが 将 来 的 には data ス キームもサポートされる 可 能 性 がある すでに Firefox および Opera では Worker コンストラクタでの data ス キームの 指 定 がサポートされている そのため 攻 撃 者 が 次 のような URI を 指 定 してユーザにアクセスさせた 場 合 Web Workers として 攻 撃 者 の 用 意 した 任 意 のスクリプトが 動 作 することとなる http://example.jp/#data:text/javascript,onmessage=... SharedWorker コンストラクタも 現 在 は 同 一 オリジンのリソースに 限 定 されているが 将 来 的 には data スキ ームをサポートする 可 能 性 があるため Worker コンストラクタと 同 様 ソースとして 任 意 の URI が 指 定 されな いような 対 策 の 必 要 がある importscripts は 同 一 オリジンに 限 定 されず Web Workers において 任 意 のオリジンのスクリプトを 読 み 込 むことができる そのため 下 記 のようなコードでは 攻 撃 者 の 用 意 した 任 意 のスクリプトが Web Workers と して 動 作 することとなる 28
// 脆 弱 なコード importscripts に 任 意 の URI がわたる var src = location.hash.substring(1); var worker = new Worker( 'worker.js' ); worker.postmessage( src ); // worker.js onmessage = function( evt ){ if( evt.data ) importscripts( evt.data ); }; ただし Web Workers 内 で 攻 撃 者 のスクリプトが 動 作 しても Web Workers 内 からブラウザの DOM への 直 接 的 な 操 作 ができないため XSS 攻 撃 に 比 べて 一 般 的 には 脅 威 が 低 いと 考 えられる 4.2.5. Cross Document Messaging Cross Document Messaging( 以 下 XDM)は 異 なるオリジンのドキュメント 間 でメッセージをやり 取 りするた めの 機 能 である XDM を 使 用 する 典 型 的 なコードを 次 に 示 す この 例 では http://example.jp と http://example2.jp というオ リジンの 異 なるドキュメントの 間 で 通 信 を 行 っている <!-- サイト 1 --> <!-- http://example.jp/xdm.html --> <script type="text/javascript"> // メッセージ 受 信 時 のハンドラを 登 録 window.addeventlistener( 'message', function( evt ){ if( evt.origin == 'http://example2.jp' ){ alert( 'got:' + evt.data ); } }, false );... //メッセージを 送 信 var iframe = document.getelementbyid( "child" ); // child iframe iframe.contentwindow.postmessage( 'ping', "http://example2.jp" ); </script>... <!-- 通 信 対 象 --> <iframe src="http://example2.jp/xdm-child.html" id="child"></iframe> 29
<!-- サイト 2 --> <!-- http://example2.jp/xdm-child.html --> <script type="text/javascript"> // メッセージ 受 信 時 のハンドラを 登 録 window.addeventlistener( 'message', function( evt ){ if( evt.origin == 'http://example.jp' ){ evt.source.postmessage( "pong", evt.origin ); } }, false ); </script> ドキュメントに 対 してメッセージを 送 信 する 際 には postmessage メソッドを 使 用 する postmessage メソッド の 第 2 引 数 には 対 象 ドキュメントのオリジンか "*"を 指 定 する 上 のサイト 1 の 例 では iframe で 指 定 された URL が http://example2.jp/xdm-child.html な の で 送 信 先 オ リ ジ ン と し て http://example2.jp を postmessage メソッドの 第 2 引 数 に 指 定 している このオリジンの 指 定 が 送 信 対 象 のドキュメントのオリジンと 一 致 していない 場 合 対 象 ドキュメントへメッセージは 送 信 されない <!-- サイト 1 からの 抜 粋 --> <iframe src="http://example2.jp/xdm-child.html" id="child"></iframe>... var iframe = document.getelementbyid( "child" ); // child iframe iframe.contentwindow.postmessage( 'ping', "http://example2.jp" ); 対 象 ドキュメントのオリジンとして"*"を 指 定 して postmessage メソッドを 呼 び 出 した 場 合 任 意 のオリジンのド キュメントがそのメッセージを 受 け 取 ることができる 意 図 しない 通 信 相 手 もそのメッセージを 受 け 取 ることが できるため 送 信 するメッセージに 秘 密 情 報 が 含 まれる 場 合 には "*"ではなく 対 象 ドキュメントのオリジンを 指 定 する 必 要 がある また 外 部 から 送 信 されたメッセージを 受 け 取 るには window オブジェクトの message イベントハンドラを 登 録 する message イベントハンドラには 引 数 としてイベントの 詳 細 が Event オブジェクトとして 渡 される メッセージを 受 信 した 側 は 引 数 の Event オブジェクトの origin プロパティを 確 認 して メッセージの 送 信 元 が 想 定 している 通 信 相 手 かどうかを 確 認 し 任 意 のドキュメントからのメッセージを 受 け 入 れないよう 注 意 する 必 要 がある 30
<!-- サイト 1 からの 抜 粋 --> window.addeventlistener( 'message', function( evt ){ if( evt.origin == 'http://example2.jp' ){ alert( 'got:' + evt.data ); } }, false ); 4.3. XMLHttpRequest XMLHttpRequest とは JavaScript を 使 用 してサーバと HTTP 通 信 を 行 うための API である 現 在 主 要 な ブラウザでは HTML5 とあわせ Cross-Origin Resource Sharing(CORS)に 従 ったクロスオリジンでの 通 信 に 対 応 した XHR Level 2 が 実 装 されている 本 節 では XHR Level 2 に 関 連 するセキュリティ 上 の 注 意 点 につ いて 説 明 する なお Internet Explorer 8 9 の XHR はクロスオリジンでの 通 信 は 対 応 しておらず クロスオリジン 通 信 のた めに XDomainRequest という 類 似 の 機 能 が 提 供 されているが XDomainRequest に 関 する 詳 細 について は 本 報 告 書 では 割 愛 する 4.3.1. 意 図 しないクロスオリジンでのアクセス(クライアント 側 ) XHR が 同 一 オリジンとの 通 信 しかできないことを 前 提 に 書 かれていた 既 存 のコードが XHR がクロスオリジ ンでのアクセスをサポートしたことにより 脆 弱 となる 場 合 がある 例 えば 自 サイトとの 通 信 を 前 提 とし XHR の 通 信 先 を URL 内 の#(ハッシュ) 以 降 によって 指 定 し レスポンス の 一 部 をそのままドキュメント 内 に 挿 入 して 表 示 する 次 のようなコードがあったとする // 同 一 オリジンでの 通 信 を 前 提 に 書 かれたコード // http://example.jp/#/foo のような URL にて // # 以 降 を 通 信 先 URL として 使 用 する var url = location.hash.substring(1); var xhr = new XMLHttpRequest(); xhr.open( "GET", url, true ); xhr.onreadystatechange = function(){ if( xhr.readystate == 4 && xhr.status == 200 ){ div.innerhtml = xhr.responsetext; } }; xhr.send( null ); 31
このようなコードは XHR がクロスオリジンでのリクエストをサポートしていなかったときには 問 題 なかったが XHR に よ る ク ロ ス オ リ ジ ン 通 信 を サ ポ ー ト し た 現 在 の ブ ラ ウ ザ で は 問 題 と な る 攻 撃 者 が http://example.jp/#//evil.example.com/のような URL へユーザを 誘 導 した 場 合 XHR の 通 信 先 として example.jp 上 のリソースではなく 攻 撃 者 が 用 意 した evil.example.com 上 のリソースが 使 用 され XSS 攻 撃 や 意 図 しないデータを 表 示 させる 攻 撃 が 行 われる 可 能 性 がある 上 記 の 例 では innerhtml を 使 用 して いるが 仮 にこれがテキストノードへの 代 入 やエスケープしたうえでの 表 示 であったとしても スクリプトは 動 作 しないものの 攻 撃 者 が 用 意 した 偽 コンテンツが 表 示 される 可 能 性 がある 対 策 としては XHR が 任 意 サイトのデータを 読 まないようリクエスト 先 を 制 限 する 必 要 がある 具 体 的 には 次 のようにリクエスト 先 を 固 定 のリストで 保 持 しておき 攻 撃 者 の 指 定 したリクエスト 先 が 入 り 込 まないようにし ておくなどの 方 法 がある // 安 全 な 例 通 信 先 を 固 定 リストで 保 持 // http://example.jp/#1 のような URL にて 通 信 先 の index を 指 定 する var pages = [ "/", "/foo", "/bar", "/baz" ]; var index = location.hash.substring(1) 0; var xhr = new XMLHttpRequest(); xhr.open( "GET", pages[ index ] '/', true ); xhr.onreadystatechange = function(){ if( xhr.readystate == 4 && xhr.status == 200 ){ div.innerhtml = xhr.responsetext; } }; xhr.send( null ); リクエスト 先 のドメインが 想 定 された 範 囲 のものかどうか JavaScript にて 確 認 する 方 法 では そのサイト 内 に オープンリダイレクトがひとつでも 存 在 すると 任 意 のドメインへとリクエストを 転 送 できるため 攻 撃 者 の 用 意 したコンテンツを 表 示 させられることとなる // 脆 弱 となる 可 能 性 のある 例 // サイト 内 にオープンリダイレクトが 存 在 すると 任 意 のサイトと 通 信 可 能 var url = url_for_request; // リクエスト 先 URL if( url.indexof( "http://example2.jp/" ) == 0 url.indexof( "http://example3.jp/" ) == 0 ) { // example2.jp または example3.jp のときのみ 通 信 32
} var xhr = new XMLHttpRequest(); xhr.open( "GET", url, true );... このコードでは XHR のリクエスト 先 を example2.jp または example3.jp だけに 限 定 するようにしているが example2.jp または example3.jp 上 にオープンリダイレクトが 存 在 している 場 合 には 結 果 的 に 任 意 のサイト との 通 信 が 可 能 となってしまう XHR ではリダイレクトが 発 生 したことを 検 知 する 手 段 や 最 終 的 な URL を 知 る 手 段 は 存 在 しない そのため XHR のリクエスト 先 オリジンを 確 認 するという 方 法 では 問 題 が 発 生 する 可 能 性 があり 先 に 示 したとおり 事 前 にリクエスト 先 を 固 定 のリストで 保 持 しておくなどの 方 法 で 制 限 する 必 要 があ る 4.3.2. 意 図 しないクロスオリジンでのアクセス(サーバ 側 ) XHR によるクロスオリジン 通 信 におけるクライアント 側 の JavaScript を 次 に 示 す var xhr = new XMLHttpRequest(); xhr.open( "GET", "http://other.example.jp", true ); xhr.onreadystatechange = function(){ if( xhr.readystate == 4 && xhr.status == 200 ){ div.appendchild( document.createtextnode( xhr.responsetext ) ); } }; xhr.send( null ); JavaScript のコード 上 は 同 一 オリジン 内 での 通 信 の 場 合 と 同 様 である このときの HTTP リクエストおよびレスポンスは 例 えば 次 のようになる GET http://other.example.jp/ HTTP/1.1 Host: other.example.jp Origin: http://example.jp User-Agent: Mozilla/5.0(Windows NT 6.0; rv:18.0) Connection: keep-alive HTTP/1.1 200 OK Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 1512 Content-Type: text/plain; charset=utf-8 33
Access-Control-Allow-Origin: http://example.jp... リクエストには どのページからリクエストが 発 行 されたかのオリジンを 示 す Origin リクエストヘッダが 付 与 され る サーバ 側 は Access-Control-Allow-Origin レスポンスヘッダにてどのオリジンであればコンテンツにアク セス 可 能 かを 指 定 する 上 の 例 では http://example.jp をオリジンとする JavaScript であればコンテンツに アクセスすることが 可 能 である サ ー バ か ら の 応 答 に Access-Control-Allow-Origin レ ス ポ ン ス ヘ ッ ダ が 存 在 し な い 場 合 や Access-Control-Allow-Origin レスポンスヘッダに 自 身 のオリジンが 含 まれていない 場 合 は XHR を 利 用 し た JavaScript 内 で responsetext プロパティなどを 通 じてコンテンツにアクセスすることはできない コンテンツに 秘 密 情 報 が 含 まれ 特 定 のオリジンからのみ そのコンテンツへのアクセスを 許 可 するという 場 合 は Origin リクエストヘッダおよび Access-Control-Allow-Origin レスポンスヘッダだけでなく 従 来 どおり の Cookie を 使 用 したアクセス 制 限 を 行 う 必 要 がある Cookie を 使 用 せずに Origin リクエストヘッダおよび Access-Control-Allow-Origin レスポンスヘッダのみを 使 用 した 場 合 攻 撃 者 はブラウザを 使 用 せずに telnet クライアントなどのツールによって 任 意 の Origin リクエストヘッダを 付 与 したリクエストを 送 信 可 能 であり JavaScript を 経 由 せずに 直 接 コンテンツを 読 むことが 可 能 だからである Access-Control-Allow-Origin: *という 指 定 は 全 てのオリジンからの JavaScript がコンテンツにアクセス 可 能 なことを 意 味 しているが 秘 密 情 報 を 含 むコンテンツに 対 してはこの 指 定 をしてはいけない 攻 撃 者 が 罠 ページから XHR によるリクエストを 発 行 した 場 合 罠 ページ 内 の JavaScript から 秘 密 情 報 にアクセス 可 能 と なるからである Access-Control-Allow-Origin: * という 指 定 は アクセス 保 護 などを 必 要 としない 完 全 に 公 開 状 態 のコンテンツにのみ 使 用 し それ 以 外 については Access-Control-Allow-Origin: http://example.jp のように 許 可 するオリジンを 指 定 する XHR を 用 いてクロスオリジンのリクエストを 発 行 する 際 デフォルトでは Cookie は 送 信 されない クロスオリジ ンで Cookie を 送 信 するには 下 記 の 例 のように withcredentials プロパティを true に 設 定 する 必 要 がある Cookie を 使 用 した 場 合 Access-Control-Allow-Origin: * という 指 定 をすることは 仕 様 上 禁 止 されており XHR からも 読 み 込 むことができない var xhr = new XMLhttpRequest(); xhr.open( "GET", "http://other.example.jp", true ); xhr.withcredentials = true; // Cookie が 送 信 されるようになる xhr.onreadystatechange = function(){ if( xhr.readystate == 4 && xhr.status == 200 ){ div.appendchild( document.createtextnode( xhr.responsetext ) ); 34
}; } xhr.send( null ); GET http://other.example.jp/ HTTP/1.1 Host: other.example.jp Origin: http://example.jp User-Agent: Mozilla/5.0(Windows NT 6.0; rv:18.0) Cookie: session=12afe9bd34e5a202 Connection: keep-alive HTTP/1.1 200 OK Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 1512 Content-Type: text/plain; charset=utf-8 Access-Control-Allow-Origin: http://example.jp... また これら 以 外 にも XHR を 経 由 してクロスオリジンで CSRF を 発 生 させることも 可 能 になっているので 従 来 通 りトークンなどを 利 用 しての CSRF 対 策 が 必 要 である 詳 細 については 3.2. クロスサイト リクエスト フォージェリ を 参 照 していただきたい 4.3.3. Ajax データによる XSS XHR でやり 取 りされるデータ(Ajax データ)に HTML として 解 釈 可 能 な 文 字 列 が 含 まれる 場 合 これをブラウ ザで 直 接 開 くと XSS 攻 撃 が 成 立 する 可 能 性 がある Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 86 Content-Type: application/json; charset=utf-8 { } "name" : "foo", "value" : "<html><script>alert(1);</script></html>" 上 記 のような JSON 形 式 のデータを Internet Explorer で 直 接 開 くと データの 先 頭 部 分 に 含 まれる 文 字 列 35
を 調 べて HTML コンテンツであると 判 断 して 解 釈 しようとする 結 果 JavaScript が 動 作 する 可 能 性 がある JSON 以 外 のデータであっても text/plain や text/csv など 様 々な 種 類 の Ajax データで XSS 攻 撃 が 行 わ れる 可 能 性 がある また XSS 攻 撃 を 使 用 しなくても 攻 撃 者 が 罠 ページを 用 意 し 攻 撃 対 象 となる Ajax データを<script> 要 素 のソースとして 読 み 込 ませるなどの 手 法 により 秘 密 情 報 を 含 む Ajax データを 攻 撃 者 が 盗 み 見 る 可 能 性 が ある この 手 法 では JavaScript として 解 釈 可 能 な JSON や CSV などが 攻 撃 対 象 として 狙 われやすい 攻 撃 者 の 罠 サイトでは 秘 密 情 報 を 含 む Ajax データを JavaScript として 読 み 込 む <script src="http://example.jp/target.json"></script> <script src="http://example.jp/target.csv"></script> これらの 問 題 に 対 して 4.3.3.1. X-Content-Type-Options レスポンスヘッダを 指 定 する 4.3.3.2. XHR からのリクエストにのみ 対 応 する で 述 べる 両 方 の 対 策 を 実 施 しておくことを 推 奨 する これは Internet Explorer 6 および 7 は X-Content-Type-Options レスポンスヘッダに 対 応 していないためである 4.3.3.1. X-Content-Type-Options レスポンスヘッダを 指 定 する Internet Explorer 8 以 降 においては レスポンスヘッダで X-Content-Type-Options: nosniff を 指 定 すること により 与 えられたデータを 分 析 して Content-Type をブラウザが 判 断 する 動 作 を 抑 制 できるので HTML と して 扱 って 欲 しくないコンテンツが HTML として 処 理 されることによって 生 じる XSS 攻 撃 を 防 ぐことができる 詳 細 については 5.2. X-Content-Type-Options を 参 照 していただきたい 4.3.3.2. XHR からのリクエストにのみ 対 応 する XHR からのリクエストにのみ Ajax データを 応 答 するために クライアント 側 から XHR のリクエストを 送 る 際 の リクエストヘッダ 内 に 特 定 文 字 列 を 含 めておき サーバ 側 ではその 文 字 列 を 含 むリクエスト 以 外 はエラーなど を 返 すことにより ブラウザから 直 接 Ajax データを 参 照 できないようにすることが 可 能 である リクエスト 時 には 次 のように setrequestheader メソッドによりカスタムヘッダを 付 与 する var XHR = new XMLHttpRequest(); XHR.open( "GET", "http://example.jp/foo.json", true ); XHR.onreadystatechange = function(){... }; XHR.setRequestHeader( "X-Request-With", "XMLHttpRequest" ); XHR.send( null ); GET http://example.jp/foo.json HTTP/1.1 Host: example.jp 36
X-Request-With: XMLHttpRequest User-Agent: Mozilla/5.0(Windows NT 6.0; rv:18.0) Cookie: session=12afe9bd34e5a202 Connection: keep-alive サーバ 側 では X-Request-With リクエストヘッダなどの 独 自 のリクエストヘッダの 存 在 および 内 容 を 確 認 す ることにより ブラウザで 直 接 コンテンツを 開 いたのではなく XHR から 発 行 されたリクエストであることが 確 認 でき XHR からの 場 合 には 正 規 の 応 答 を 返 し そうでない 場 合 にはステータスコード 403 などを 返 すなどの 対 応 をとることができる なお jquery や prototype.js のように 上 記 のようなリクエストヘッダを 自 動 的 に 付 与 してくれるライブラリも 存 在 する クロスオリジンでの 通 信 において setrequestheader メソッドを 使 用 する 場 合 は GET や POST に 先 立 ち preflight リクエストと 呼 ばれる OPTIONS メソッドのリクエストが 発 行 される このとき 本 来 のリクエストで 使 用 するメソッドが Access-Control-Request-Method リクエストヘッダで 送 信 され setrequestheader メソッド で 設 定 されたカスタムヘッダが Access-Control-Request-Headers リクエストヘッダで 送 信 される preflight リクエストの 処 理 は XHR が 自 動 的 に 行 うため クライアント 側 では JavaScript で preflight リクエストに 関 する 処 理 を 実 装 する 必 要 はないが サーバ 側 での 対 応 が 必 要 となる 可 能 性 がある // クロスオリジンで setrequestheader する 例 var XHR = new XMLHttpRequest(); XHR.open( "GET", "http://other.example.jp/foo.json", true ); XHR.withCredentials = true; // Cookie を 送 信 XHR.onreadystatechange = function(){... }; XHR.setRequestHeader( "X-Request-With", "XMLHttpRequest" ); XHR.send( null ); 37
次 の 例 では foo.json は HTML として 解 釈 可 能 な 文 字 列 を 含 んでいるが XHR からのリクエストにのみ 対 応 することで ブラウザから 直 接 Ajax データを 参 照 できないようにしている OPTIONS http://other.example.jp/foo.json HTTP/1.1 Host: other.example.jp Origin: http://example.jp User-Agent: Mozilla/5.0(Windows NT 6.0; rv:18.0) Cookie: session=12afe9bd34e5a202 Connection: keep-alive Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Request-With HTTP/1.1 200 OK Date: Tue, 1 Jan 2013 09:00:00 GMT Access-Control-Allow-Origin: http://example.jp Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Request-With Access-Control-Max-Age: 1728000 Content-Length: 0 Connection: Keep-Alive Content-Type: application/json GET http://other.example.jp/foo.json HTTP/1.1 Host: other.example.jp X-Request-With: XMLHttpRequest Origin: http://example.jp User-Agent: Mozilla/5.0(Windows NT 6.0; rv:18.0) Cookie: session=12afe9bd34e5a202 Connection: keep-alive HTTP/1.1 200 OK Date: Tue, 1 Jan 2013 09:00:00 GMT Access-Control-Allow-Origin: http://example.jp Connection: Keep-Alive Content-Length: 86 Content-Type: application/json; charset=utf-8 { } "name" : "foo", "value" : "<html><script>alert(1);</script></html>" 38
5. HTML5 におけるセキュリティ 機 能 本 章 では 次 に 挙 げる 一 部 のブラウザに 実 装 されているユーザを 保 護 するためのセキュリティ 機 能 の 概 要 と それを 有 効 に 活 用 するための 留 意 事 項 を 述 べる これらの 機 能 を 有 効 にするかどうかは HTTP のレスポン スヘッダで 指 定 することができる これらの 機 能 は まだ 標 準 化 されていないものが 大 部 分 で 機 能 の 有 無 を 含 めてブラウザによる 相 違 があることに 注 意 されたい X- XSS-Protection X-Content-Type-Options X-Frame-Options Content-Security-Policy Content-Disposition Strict-Transport-Security 5.1. X-XSS-Protection ブラウザによっては XSS 攻 撃 から 保 護 する 機 能 が 付 与 されていることがある この 機 能 の 名 前 は 次 のように ブラウザにより 異 なっている Internet Explorer 8 以 降 : XSS フィルター Google Chrome : XSS Auditor Safari : XSS Auditor ブラウザにより 差 はあるが リクエストに 含 まれる<script>などの 要 素 がレスポンスにも 同 様 に 含 まれていた 場 合 に XSS 攻 撃 と 見 なして それらをブロック 無 害 化 することにより 反 射 型 XSS 攻 撃 を 防 ぐというのが 共 通 す る 原 理 である 原 理 上 リクエストとレスポンスの 両 方 に 類 似 する 文 字 列 が 含 まれる 場 合 に XSS 攻 撃 を 誤 検 出 することがある Internet Explorer の XSS フィルターでは 図 5-1 に 示 すように XSS 攻 撃 を 検 知 した 場 合 にアドレスバー の 下 に 通 知 が 表 示 されるが Google Chrome および Safari では 特 にそのような 通 知 は 表 示 されない この 機 能 は 表 5-1 に 設 定 例 を 示 したような 形 式 で X-XSS-Protection レスポンスヘッダにより 制 御 するこ とができる 図 5-1 Internet Explorer における XSS 保 護 フィルタ 動 作 画 面 39
表 5-1 X-XSS-Protection の 設 定 例 X-XSS-Protection: 0 XSS 保 護 フィルタ 機 能 を 無 効 にする X-XSS-Protection: 1 XSS 保 護 フィルタ 機 能 を 有 効 にする X-XSS-Protection: 1;mode=block XSS 保 護 フィルタ 機 能 を 有 効 にする XSS 攻 撃 検 出 時 にブラウザでの 表 示 を 空 白 にする 0 を 指 定 した 場 合 ブラウザの XSS 保 護 フィルタは 一 時 的 に 無 効 となる 1 を 指 定 した 場 合 ブラウザの XSS 保 護 フィルターは 有 効 となる 1;mode=block を 指 定 した 場 合 XSS 攻 撃 検 出 時 に 検 出 された 要 素 だけを 削 除 するのではなく 空 白 のドキュメントが 表 示 される(Internet Explorer では # のみが 表 示 され Google Chrome Safari では about:blank ページが 表 示 される) X-XSS-Protection が 指 定 されていない 場 合 は 1 を 指 定 した 場 合 と 同 様 に XSS 保 護 フィルタが 有 効 となる X-XSS-Protection ヘッダはレスポンスヘッダ 内 で 指 定 された 場 合 のみ 有 効 で <meta http-equiv>により HTML 内 で 指 定 しても 機 能 しない X-XSS-Protection: 0 を 指 定 して XSS 保 護 フィルタを 無 効 にすることは 誤 検 出 が 多 いなど 特 別 な 理 由 があ るページのみに 限 定 すべきである 5.2. X-Content-Type-Options レスポンスヘッダにて X-Content-Type-Options: nosniff を 指 定 することにより Internet Explorer 8 以 降 で は Content-Type レスポンスヘッダに 従 ってコンテンツを 取 り 扱 う Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 42 X-Content-Type-Options: nosniff Content-Type: text/plain; charset=utf-8 <html> <script>alert(1)</script> </html> Internet Explorer 6 および 7 でこのようなコンテンツを 開 いた 場 合 Content-Type は text/plain であるにも 関 わらず MIME スニッフィングにより HTML と 判 断 され JavaScript が 動 作 してしまうが Internet Explorer 8 以 降 では X-Content-Type-Options: nosniff が 指 定 されている 場 合 には Content-Type の 指 定 どおりにコ ンテンツを text/plain として 取 り 扱 う X-Content-Type-Options を 使 用 することにより Internet Explorer 8 以 降 に 対 しては 4.3.3. Ajax データ 40
による XSS で 説 明 したような HTML 以 外 のものが HTML として 処 理 されることによる XSS 攻 撃 を 防 ぐこと ができる 一 方 Internet Explorer 6 および 7 では X-Content-Type-Options レスポンスヘッダは 利 用 でき ないため XHR で 応 答 するデータに 関 しては 4.3.3.2. XHR からのリクエストにのみ 対 応 する で 解 説 した 対 策 が 必 要 である また XHR 以 外 からもアクセスが 想 定 されるコンテンツに 関 しては - HTML として 解 釈 されても 問 題 が 出 ないようにエスケープする - Content-Disposition: attachment レスポンスヘッダを 付 与 しブラウザ 内 で 直 接 開 かせない - 異 なるドメインにコンテンツを 配 置 する などの 対 策 で 影 響 を 軽 減 することができる また X-Content-Type-Options: nosniff は Internet Explorer 9 および 10 に 対 しては コンテンツを 直 接 開 く 場 合 だけでなくスタイルシートや<script> 要 素 での 外 部 スクリプトの 読 み 込 みにも 適 用 され 次 の Content-Type のみを 使 用 することができる スタイルシート text/css スクリプト application/ecmascript text/ecmascript text/x-javascript application/javascript text/javascript text/vbs application/x-javascript text/jscript text/vbscript なお X-Content-Type-Options はレスポンスヘッダ 内 で 指 定 された 場 合 のみ 有 効 で <meta http-equiv> により HTML 内 で 指 定 された 場 合 には 機 能 しない HTTP レスポンスヘッダにて X-Content-Type-Options: nosniff を 指 定 することで 読 み 込 み 可 能 なスタイル シートやスクリプトソースの Content-Type を 制 限 することができるため 動 的 に 生 成 される 全 てのコンテンツ に 対 して X-Content-Type-Options: nosniff を 付 与 することを 推 奨 する 5.3. X-Frame-Options Internet Explorer 6 および 7 を 除 く 現 在 の 主 要 なブラウザでは クリックジャッキング 対 策 としてレスポンスヘ ッダにて X-Frame-Options を 指 定 することにより iframe frame 内 での 該 当 コンテンツの 埋 め 込 みを 禁 止 することができる 例 えば 次 のような HTTP レスポンスヘッダを 付 与 することにより コンテンツが 他 ページ 内 の iframe などで 表 示 されることを 禁 止 できる 41
Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 28400 X-Frame-Options: DENY Content-Type: text/html; charset=utf-8 <!doctype html> <html>...</html> X-Frame-Options として 指 定 可 能 な 値 は 次 の 3 種 類 である 表 5-2: X-Frame-Options で 使 用 される 値 X-Frame-Options: DENY Iframe などでの 表 示 を 禁 止 する X-Frame-Options: SAMEORIGIN ページ 自 身 のオリジンと 同 一 オリジンの 場 合 のみ iframe などでの 表 示 が 可 能 オリジンが 一 致 しな い 場 合 は 表 示 を 禁 止 する X-Frame-Options: ALLOW-FROM uri ページ 自 身 のオリジンが uri で 指 定 されたオリジン と 一 致 する 場 合 のみ iframe などでの 表 示 が 可 能 一 致 しない 場 合 は 表 示 を 禁 止 する ALLOW-FROM uri の 指 定 は Internet Explorer 8 以 降 および PC 版 Android 版 の Firefox(ESR を 除 く) でサポートされている uri 部 にはプロトコルスキームも 必 要 である 次 は http://example.jp/ 内 のページから iframe で 読 み 込 まれた 場 合 にのみ 表 示 を 許 可 する 場 合 の 例 である X-Frame-Options: ALLOW-FROM http://example.jp また X-Frame-Options はいくつかのブラウザではレスポンスヘッダ 内 で 指 定 された 場 合 のみ 機 能 し <meta http-equiv>で 指 定 された 場 合 には 機 能 しない クリックジャッキング 対 策 として X-Frame-Options レスポンスヘッダではなく フレームバスティング と 呼 ば れるコードによってコンテンツの iframe 内 への 埋 め 込 みを 防 ぐ 方 法 が 知 られているが この 方 法 は 多 数 の 欠 点 があるため 使 用 するべきではない // フレームバスティングコードの 一 例 if( top!= self ){ top.location = self.location; } 42
5.4. Content-Security-Policy Content Security Policy(CSP)は 読 み 込 み 可 能 なリソースのオリジンをレスポンスヘッダにて 指 定 すること で 機 能 を 制 限 し XSS 攻 撃 の 可 能 性 を 低 減 する 機 能 である 現 在 CSP に 対 応 しているブラウザは Firefox および Google Chrome Safari である CSP が 有 効 になると ブラウザ 内 の 次 の 機 能 が 制 限 される - <script>や<img> <iframe>といった 各 要 素 でのリソースの 読 込 み - <div onmouseover="alert(1)">や<script>alert(1)</script>といったインラインでの JavaScript の 実 行 - JavaScript 内 での eval 関 数 や Function コンストラクタといった 文 字 列 からのコードの 生 成 - javascript スキームや data スキーム CSP は Firefox では X-Content-Security-Policy レ ス ポ ン ス ヘ ッ ダ で Google Chrome では Content-Security-Policy レ ス ポ ン ス ヘ ッ ダ ま た は X-WebKit-CSP レ ス ポ ン ス ヘ ッ ダ Safari では X-WebKit-CSP レスポンスヘッダで 指 定 する 将 来 的 には Content-Security-Policy レスポンスヘッダに 統 一 される 見 込 みである すべてに 対 応 するためには 次 のように 3 種 類 のレスポンスヘッダを 出 力 する Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Type: text/html; charset=utf-8 X-Content-Security-Policy: default-src 'self'; img-src img.example.jp X-WebKit-CSP: default-src 'self'; img-src img.example.jp Content-Security-Policy: default-src 'self'; img-src img.example.jp この 例 では 画 像 は img.example.jp 上 のものを それ 以 外 の 全 てのリソースについてドキュメントと 同 一 オリ ジンからのみ 読 み 込 みを 許 可 している CSP では この 例 の default-src や img-src をディレクティブ self や img.example.jp をディレクティブソースと 呼 んでおり ディレクティブ ディレクティブソースとして W3C で は 様 々な 種 類 が 定 義 されているが ブラウザによって 実 装 状 況 は 異 なる ディレクティブとして 代 表 的 なもの を 次 に 示 す default-src script-src style-src img-src frame-src 表 5-3: ディレクティブの 例 他 のディレクティブで 指 定 されていない デフォルトで 許 可 されるディ レクティブソースを 列 挙 する スクリプトとして 許 可 するディレクティブソースを 列 挙 する スタイルシートとして 許 可 するディレクティブソースを 列 挙 する 画 像 の 読 込 みを 許 可 するディレクティブソースを 列 挙 する フレームとして 表 示 可 能 なディレクティブソースを 列 挙 する デ ィ レ ク テ ィ ブ ソ ー ス と し て は 先 に 示 し た img.example.jp の よ う な ホ ス ト 名 で の 指 定 の 他 に *.example.jp といったワイルドカードや https: のようなスキーム 名 次 に 示 す 予 約 語 での 指 定 が 可 能 で 43
ある 'self' 'none' 'unsafe-inline' 'unsafe-eval' 表 5-4: ディレクティブソースの 例 ドキュメント 自 身 と 同 一 オリジンの 場 合 にのみ 許 可 する どのオリジンも 許 可 しない script-src style-src においてインラインでのスクリプト 記 述 スタイル 記 述 を 許 可 する JavaScript 内 での eval Function settimeout setinterval といっ た 文 字 列 からコードを 生 成 する 機 能 を 許 可 する CSP では ポリシー 違 反 を 検 出 した 場 合 にブラウザから 自 動 的 にサーバに 対 してレポートを 送 信 することも できる レポートの 送 信 先 は report-uri ディレクティブによって 指 定 する(Content-Security-Policy 以 外 のレ スポンスヘッダは 省 略 している) Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Type: text/html; charset=utf-8 Content-Security-Policy: default-src 'self'; img-src img.example.jp; report-uri http://example.jp/report.cgi ポリシー 違 反 のレポートを 受 け 取 ることで サイト 運 営 者 は XSS 攻 撃 を 早 い 段 階 で 察 知 することが 可 能 とな る また レスポンスヘッダにて Content-Security-Policy の 代 わりに Content-Security-Policy-Report- Only(ま たは X-WebKit-CSP-Report-Only あるいは X-Content-Security-Policy-Report-Only)を 指 定 した 場 合 ポ リシーに 違 反 した 場 合 でもリソースはブロックされることなく 読 み 込 まれ 違 反 のレポートのみが 送 信 されるこ とになる Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Type: text/html; charset=utf-8 Content-Security-Policy-Report-Only: default-src 'self'; img-src img.example.jp; report-uri http://example.jp/report.cgi CSP は 現 在 も 活 発 に 仕 様 策 定 と 実 装 が 進 められており ブラウザ 間 およびバージョン 間 での 実 装 差 異 が 大 きいという 段 階 である 44
5.5. Content-Disposition レスポンスヘッダにおいて Content-Disposition: attachment を 指 定 することでコンテンツをブラウザ 内 で 表 示 するのではなく ファイルとして 保 存 するように 指 定 できる この 機 能 は Web メールや 掲 示 板 などにおい て 添 付 ファイル 機 能 として 広 く 利 用 されている Internet Explorer ではこのときに 表 示 されるダイアログにお いて 開 く を 選 択 することで XSS 攻 撃 が 行 われる 可 能 性 がある Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 42 Content-Disposition: attachment; filename="index.html" Content-Type: text/html; charset=utf-8 <html> <script>alert(1)</script> </html> 例 えば Internet Explorer 8 でこのようなレスポンスを 返 すサーバにアクセスした 場 合 次 のようなダイアログ が 表 示 される 図 5-2: ダウンロード 確 認 ダイアログ ダイアログが 表 示 された 時 点 でユーザが 開 く を 選 択 すると サーバをオリジンとしてコンテンツがブラウザ 上 で 表 示 されるため 蓄 積 型 の XSS 攻 撃 が 行 われる 可 能 性 がある Internet Explorer 8 以 降 では レスポン スヘッダに X-Download-Options: noopen を 指 定 することでダイアログの 開 く ボタンを 非 表 示 にすることが できる 45
Content-Type: text/html; charset=utf-8 Date: Tue, 1 Jan 2013 09:00:00 GMT Content-Length: 42 Content-Disposition: attachment; filename="index.html" X-Download-Options: noopen <html>... <script>alert(1)</script> </html> 図 5-3: ダウンロード 確 認 ダイアログ 46