Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Webプラットフォームのセキュリティ
Semelhante a Webプラットフォームのセキュリティ (20)
Mais de Muneaki Nishimura
Mais de Muneaki Nishimura (15)
Último
Último (10)
Webプラットフォームのセキュリティ
- 4. 事前学習を振り返る • HSTSを元に次のような問題点を考察した その技術では解決できない問題 端末時刻の改ざんによるHSTSの強制失効 その技術の導入により新たに生じる問題 HSTSを用いたユーザー追跡 (HSTS Supercookies) 実装の誤りに起因する問題 指定を誤るとHTTPS非対応のサブドメインがアクセス不能に 仕様上既定されていない振る舞い HSTSはWebSocket(ws:)にも適用されるのか？ CVE-2015-1244: Chrome でWebSocketにHSTSが適用されない HSTSはプライバシーモードにも引き継ぐのか？ またその逆は？
- 5. この講義の目的 • Webの開発者 ブラウザが備えるセキュリティ機能の効果とその代償を理解し、 機能を適切に利用できるようになる • セキュリティ研究者 現在のブラウザが解決できていない問題を明確化し、それを 解決するための研究・提案ができるようになる • バグハンター ブラウザの機能の抜け穴を見つけて指摘できるようになる そして報奨金をガッポリ稼ぐ！
- 6. この講義の内容 • 次のテーマを元にディスカッションを行う 安全な通信を実現するためにブラウザがしていること HTTPSを使えば本当に十分なのか考えてみよう Same Origin Policy(SOP)とは何か 自分の言葉でSOPを説明してみよう ブラウザがFetch APIに課した制限 APIの悪用を防ぐためにブラウザが禁止していることを学ぼう
- 7. 私の戦歴(参考) • 次のような仕様不備を脆弱性として指摘してきた ChromeのCSP違反レポートの送信先が<base>で制御できる https://crbug.com/431218 ChromeのHTML ImportsがContent-Type指定を無視する https://crbug.com/439877 ChromeのService Workersがiframe[sandbox]内で動作する https://crbug.com/486308 FirefoxのWeb Notificationのアイコン表示がCSPを無視する https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0119.html FirefoxのReferrer Policyが新しいタブで開いた際に効かない https://lists.w3.org/Archives/Public/public-webappsec/2015Apr/0246.html FirefoxのBroadcast Channel APIがプライバシーモードから 通常モードのウィンドウに通知される https://bugzilla.mozilla.org/show_bug.cgi?id=1148032
- 9. 問題 • 次のようなユーザ認証を行うサイトがある サーバとの通信にはどのような脅威があるか？ どのようにすれば安全な通信ができるか？ ログインのリクエスト ユーザ名=abc & パスワード=123… レスポンス セッションID=Zyxwv…
- 10. Phishing • 偽のサイトに誘導し、そこでパスワードなどの機微 な情報を入力させる 利用者を騙すために、本物のサイトと似た画面のデザインや URLが用いられることが多い ログインのリクエスト ユーザ名=abc & パスワード=123 よく見ると小文字のRN 送信内容が盗まれる
- 11. ブラウザのPhishing対策 • 本物と見分けの付かない偽のURL 形の似た異なる文字によるURL偽装(Homographic Attack) http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf 例：小文字の“M”と“RN”を区別するのは難しい 国際化ドメイン名(IDN)によりリスクが増加 例：Latinの'c'(U+0063)とCyrillicの'c'(U+0441)は見た目が同じ 対策として、ブラウザはIDNの表示ルールを各自で定め、 ルールに違反するURLはPunycode(ピュニコード)で表示 例：http://ebаy.com http://xn--eby-7cd.com Punycodeで表示'a' はCyrillic
- 14. ブラウザのPhishing対策 • ITリテラシーの高くない利用者をどう守るか そもそもURLの偽装が中途半端でも被害にあう人はいる 例: http://web.ib.mizuhobank.co.jp.ckw.●●●●.com https://www.antiphishing.jp/news/alert/mizuho20150520.html 画面さえ本物と似ていれば人は騙される • 最近の主流はURLのReputationに基づく検知 Chrome,Firefox,SafariはGoogleのSafe Browsing APIを利用 https://developers.google.com/safe-browsing/ IEは独自のSmartScreenフィルター機能を搭載 http://windows.microsoft.com/ja-jp/internet-explorer/products/ie-9/features/smartscreen-filter それって検出精度は大丈夫？
- 16. Pharming • DNS情報の改ざんにより、偽サイトへ誘導させる 利用者は正規のURLを指定しても偽サイトに誘導される URLを見ただけでは偽サイトだと判別できない ログインのリクエスト ユーザ名=abc & パスワード=123 正規サイトと同じURL 偽 DNSによる名前解決 偽のIPアドレス
- 19. Passive MITM • 誰が盗聴するのか 某国家の諜報機関(電気通信事業者と共謀) 企業の情報システム部門、Wi-Fi APの提供事業者など • Pervasive Surveillance (Mass Surveillance) 膨大な計算能力を有する諜報機関による広範囲なMITM 海底ケーブルを盗聴して大量のデータを取得するなど 暗号化データを盗聴するための研究開発が行われていた事実も https://en.wikipedia.org/wiki/Dual_EC_DRBG 実際に攻撃が行われていたことが2013年に明らかとなり、 通信路を暗号化する取り組みが加速し始めた https://tools.ietf.org/html/rfc7258
- 20. Passive MITM • 平文で流れるデータは意外と多い HTTP, FTP, SMTP, POP, Telnet… HTTPSでも接続先のホスト名は平文で送信される TCP/IPのレイヤは暗号化されていない TLS拡張のSNI(Server Name Indication)も平文 • HTTPSを使えば防げるけれど サーバのパフォーマンス低下 証明書を定期的に更新する手間 サイトに接続できない端末の発生 プリインストールされているルート証明書の有効期限切れ 古いTLS規格や弱い暗号スイートのみをサポートする端末
- 21. ブラウザのPassive MITM対策 • あの手この手でHTTPSの利用を促進 Let's Encrypt https://letsencrypt.org/howitworks/technology/ Opportunistic Security for HTTP (日和見暗号) https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-02 Prefer Secure Origins For Powerful New Features https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features • Let's Encrypt HTTPSを手軽に利用することを目的に作られた無料の認証局 2つのシェルコマンドで証明書の発行から運用まで https://letsencrypt.readthedocs.org/en/latest/intro.html#about-the-let-s-encrypt-client
- 22. ブラウザのPassive MITM対策 • Opportunistic Security for HTTP (日和見暗号) サーバ認証をせずにTLSでhttp:80の通信を暗号化 オレオレ証明書ベースのTLSでも平文よりは安全 http/2の拡張仕様として仕様策定中 https://tools.ietf.org/html/draft-nottingham-http2-encryption-03 • Prefer Secure Origins For Powerful New Features HTTPS接続時でなければ使えない機能を増やしていく https://w3ctag.github.io/web-https/ https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ Service WorkersやPush APIには既に適用されている http://www.w3.org/TR/service-workers/ http://www.w3.org/TR/push-api/
- 23. Active MITM • 盗聴に加え、通信路のデータの改ざんを行うMITM 標的のWebサーバになりすまし、HTTPSの通信も盗聴／改ざん Passive MITMに比べて被害は局所的 https://example.jp/ 盗聴・改ざん
- 24. Active MITM • 誰が攻撃を仕掛けるのか シリア政府は国民のFacebookへの接続に対してMITMを実施 https://www.eff.org/ja/deeplinks/2011/05/syrian-man-middle-against-facebook 認証局への侵入により不正発行された証明書がイランでGmail アカウントのハイジャック等に悪用された可能性 https://www.eff.org/ja/deeplinks/2011/09/post-mortem-iranian-diginotar-attack 航空機内Wi-FiサービスプロバイダのGogo https://casecurity.org/2015/01/08/gogo-found-spoofing-google-ssl-certificates/ • HTTPSは有効な手段であるはずだが… 多くのユーザが証明書エラーの警告を無視する Chrome 29では約70%の利用者が証明書エラーを無視 http://www.robreeder.com/pubs/sslExperimentCHI2014.pdf
- 25. ブラウザのActive MITM対策 • 証明書エラーのクリックスルー率を下げる クリックスルーの危険性を視覚的に訴えるUIに変更 Internet Explorer 6 Microsoft Edge (2015年7月時点の開発版)
- 26. ブラウザのActive MITM対策 • 証明書エラーのクリックスルー率を下げる(続き) クリックスルーを行う際のユーザ操作を増やす Safari 8 (1クリック) Firefox 39 (4クリック)
- 28. ブラウザのActive MITM対策 • Mixed Content HTTPSで配信されたページからHTTPのリソースの取得を禁止 http://www.w3.org/TR/mixed-content/ JavaScriptやCSSが改ざんされると、HTTPSで保護されたページの 情報が盗まれたり改ざんされたりするため リソースを2種類に分類して段階的に制限を適用 Blockable Content JavaScript, CSS, plugins, XMLHttpRequest Optionally Blockable Content image, audio, video, prefetch
- 29. ブラウザのActive MITM対策 • Mixed Content(続き) Firefox 1(初回のみ警告を表示) Firefox 38(デフォルトでブロック)
- 30. PKI Attacks (with Active MITM) • 不正に発行されたサーバ証明書を悪用したMITM 認証局への侵入やオペレーションミス、暗号の危殆化などに より不正な証明書が発行される 不正に発行された証明書は正規の証明書と区別できない 従来のPKIの仕組みでは対処できない問題 https://example.jp/ 証明書を不正発行 HTTPS接続HTTPS接続
- 31. PKI Attacks (with Active MITM) • 過去に起きた証明書の不正発行(の一部) 2008年 RapidSSL MD5署名に対するハッシュ衝突攻撃 2008年 Thawte ドメイン名の所有確認手順の不備 2008年 StartCom Webサイトに対する攻撃 2008年 Comodo ドメイン名の所有確認手順の不備 2011年 Comodo ドメイン名の所有確認手順の不備 2011年 DigiNotar 認証局(登録局)に対する侵入 2012年 TURKTRUST 中間CA証明書の誤発行 2013年 ANSSI 中間CA証明書の誤発行 2015年 Comodo ドメイン名の所有確認手順の不備
- 32. ブラウザのPKI Attack対策 • 2011年以降、様々な手法が提案された 主流は公開鍵ピンニング これまでに多くの問題を検知してきた実績 http://googleonlinesecurity.blogspot.jp/2011/08/update-on-attempted-man-in-middle.html 最近何かと話題のCT(Certificate Transparency) ChromeはCT非対応のEV証明書の運営組織をURLに表示しない http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency Chrome 43 (運営組織は非表示) Firefox 39 (運営組織を表示)
- 33. ブラウザのPKI Attack対策 • 公開鍵ピンニングとは 正規の証明書の情報をあらかじめブラウザに記憶(ピン留め) 以降、ピン留めした証明書以外によるHTTPSの通信を禁止 • 公開鍵ピンニングにも様々な課題がある 利用者がルート証明書ストアに追加した証明書は許可される 不正な証明書をインストールさせられた場合は対処できない 実際にLenovoのSuperfishは防ぐことができなかった http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that- breaks-https-connections/ ピン留めした証明書情報の更新忘れによるセルフDoS 新しい証明書を運用した際にピン留めした情報との不一致が発生 HPKPでは救済措置としてバックアップピンの登録を強制
- 34. ブラウザのPKI Attack対策 • CTとは 発行した証明書のデータを認証局がログサーバに記録 ログサーバは誰でも閲覧可能であるため、証明書の不正発行が あれば(きっと)誰かが気付くことができる • CTにも様々な問題がある ログサーバの情報を集計することにより様々な情報がばれる 各認証局の売上や世界シェア 設立予定の会社名や非公開の製品名を含む非公開のドメイン情報 ログサーバのアクセス履歴を見れば、いつどこからどのドメイン にアクセスされたかが分かる(OCSPで指摘された問題) 他にも説明しきれないくらい様々な問題がある(詳細は以下) http://ozuma.sakura.ne.jp/sumida/attach/01_cert_t-view.pdf http://www.slideshare.net/kenjiurushima/certificate-transparencyssl
- 35. ここまでのまとめ • 安全な通信を実現するためにブラウザは様々な対策 を講じてきた 「HTTPSを使えば安全」ではない • 他にも様々な脅威とその対策が行われている サーバ秘密鍵の漏洩とその対策(Perfect Forward Secrecy) TLSのレコード分断(Cookie Cutter Attack) ブラウザの自発的なフォールバック(SSL 3.0 Fallback) and more!!
- 38. 問題 • ブラウザにはSame Origin Policy(SOP)と呼ばれる コンテンツ分離の概念がある SOPとは何か？ Origin(生成元)が用いられる理由は何故か？ SOPの適用例にはどのようなものがあるか？
- 39. Origin • URLの構成要素のうち、scheme + host + port を 組み合わせたもの(RFC6454) https://tools.ietf.org/html/rfc6454 http://example.jpと同じOrigin http://example.jp:80/ http://example.jp/path/file http://example.jpと異なるOrigin http://example.jp:8080/ http://www.example. jp/ https://example. jp:80/ http://example.com/
- 40. Same Origin Policy (SOP) • WebコンテンツをOriginに基づいて分離する仕組み 同じOriginのコンテンツは信頼できるという前提に基づいた セキュリティモデル URLやパス単位に信頼の境界を定義する試みも過去にはあったが、 ブラウザの実装や運用が煩雑になりうまくいかなかった https://tools.ietf.org/html/rfc6454#section-8 何故ホスト名(host)のみでコンテンツを分離しないのか？ 同じhostでもhttp:とhttps:で信頼のレベルを分けたいから https://tools.ietf.org/html/rfc6454#section-3.2 SOPは全てのユースケースを満たすものではない 例：異なる学生のページが同一Originに存在する大学のサイト http://example.edu/~student/
- 41. SOPの適用例① • 異なるOriginのオブジェクトは操作できない 次の場合、サブウィンドウのlocationの参照は禁止 var subwin = window.open('http://other.example.jp/'); var subloc = subwin.location; // 禁止
- 42. SOPの適用例① • 例外的に操作できるオブジェクトもある 次の場合、サブウィンドウのlocationの変更は許可 var subwin = window.open('http://other.example.jp/'); subwin.location = ‘http://www.ipa.or.jp’; // 許可
- 43. SOPの適用例② • 異なるOriginに対するリクエスト 次のリクエストは異なるOriginでも許可 <script src="http://other.example.jp/foo.js"> <form action="http://other.example.jp/" method="post"> new WebSocket('ws://other.example.jp/'); 次のリクエストはサーバがCORS*1対応の場合に限り許可 var req = new XMLHttpRequest(); req.open(‘GET’, ‘http://other.example.jp/’); req.send(); @font-face { font-family: 'external'; src: url('http://other.example.jp/font.woff'); } *1 CORS：https://developer.mozilla.org/ja/docs/HTTP_access_control
- 44. SOPが適用されない機能 • 全てのコンテンツがSOPで分離される訳ではない リモートのオリジンからローカルファイルの参照は禁止 例: <iframe src="file:///etc/passwd"> Cookieはdomainとpathに基づくアクセス制御 HTTP認証はrealmに基づくアクセス制御 Service Workersは同一のSecure Originのみ利用可能 https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features ReferrerはHTTPSのOriginがHTTPで通信を行う際のみ規制
- 45. SOPと擬似URL • SOPが必ずしもOriginに基づく訳ではない window.openやiframeで開かれたabout:blankやjavascript: URL は親のドキュメント(ナビゲーション元)のOriginを継承 blob: URLはその元となるBlobを作成したOriginを継承 data: URLのOriginはブラウザによって大きく異なる(次頁) 親のオリジンを継承
- 46. data: URLのOrigin a [href] window.open iframe 30x Redirect Refresh アドレスバー 手入力 お気に入り Internet Explorer 11 (遷移不可) (遷移不可) (遷移不可) (遷移不可) (遷移不可) (遷移不可) Microsoft Edge 20.10240 (遷移不可) 独自の Origin (遷移不可) (遷移不可) (遷移不可) (遷移不可) Firefox 39 ナビゲーション 元のOrigin ナビゲーション 元のOrigin 独自の Origin 独自の Origin 独自の Origin ナビゲーション 対象Windowの Origin Safari 8 独自の Origin 独自の Origin 独自の Origin (ただしバグ有り) 独自の Origin 独自の Origin 独自の Origin Chrome 43 独自の Origin 独自の Origin (遷移不可) 独自の Origin 独自の Origin 独自の Origin
- 47. SOPの実装には一貫性が無い • コンテンツの分離するかどうかの基準が曖昧 SOPは単一のルールではなく「Origin単位で色々と分離しないとね」 という漠然としたもの 機能ごとに分離の仕方を決めるのでたまに誤る(SOPバイパスの脆弱性) 擬似URLのOriginもURLごとに決められる iframe[sandbox]やiframe[srcdoc]などの登場で複雑化 Originの定義もブラウザにより異なる ブラウザの脆弱性の温床 • 従来の仕様を見直そうとする動きもある Origin Cookie: SOPに基づく新しいCookie http://tools.ietf.org/html/draft-west-origin-cookies-01 • 機能の振る舞いを個別に調べることが重要 全てSOPで保護されていると思っていると痛い目に遭う
- 50. Fetch APIの使い方 fetch('http://api.example.jp/path',{ method:'POST', headers: { 'Content-Type':'text/plain' }, body:'Hello World!' }).then(function(res){ console.log(res.headers.get('Content-Type')); }).catch(function(err){ console.error(err); });