Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Webプラットフォームのセキュリティ

15,284 views

Published on

セキュリティ・キャンプ全国大会2015の講義資料です。

Published in: Technology
  • Be the first to comment

Webプラットフォームのセキュリティ

  1. 1. Webプラットフォームのセキュリティ セキュリティ・キャンプ全国大会2015 高レイヤートラック The Web Platform Security
  2. 2. 背景 • プラットフォーム化するWeb 経済、医療、政治など様々な分野でWebは欠かせない存在に 国家の安全や人の生命に関わる情報のやり取りも • 複雑化するWeb ブラウザは6週間おきにメジャーバージョンアップ ブラウザの機能追加により、昨日まで安全だったサイトが脆弱に Webアプリの大規模化 開発者の努力や脆弱性診断だけで安全性を保つことは困難に
  3. 3. 背景 • Webをセキュアにする様々な技術が登場 クロスサイトスクリプティングを抑止する技術(CSP) 全ての通信をTLSで暗号化する技術(HSTS) サーバ上のリソースの改ざんを検知する技術(SRI) • しかしこれらが全ての問題を解決する訳ではない その技術を導入することにより新たに生じる問題 仕様自体の考慮漏れ Webの仕様はW3CやIETFなどで有識者が話し合って策定 参加する有識者が思い付かないことは仕様にも反映されない 過去の知見を確実にFeedbackするプロセスがない
  4. 4. 事前学習を振り返る • HSTSを元に次のような問題点を考察した その技術では解決できない問題 端末時刻の改ざんによるHSTSの強制失効 その技術の導入により新たに生じる問題 HSTSを用いたユーザー追跡 (HSTS Supercookies) 実装の誤りに起因する問題 指定を誤るとHTTPS非対応のサブドメインがアクセス不能に 仕様上既定されていない振る舞い HSTSはWebSocket(ws:)にも適用されるのか? CVE-2015-1244: Chrome でWebSocketにHSTSが適用されない HSTSはプライバシーモードにも引き継ぐのか? またその逆は?
  5. 5. この講義の目的 • Webの開発者 ブラウザが備えるセキュリティ機能の効果とその代償を理解し、 機能を適切に利用できるようになる • セキュリティ研究者 現在のブラウザが解決できていない問題を明確化し、それを 解決するための研究・提案ができるようになる • バグハンター ブラウザの機能の抜け穴を見つけて指摘できるようになる そして報奨金をガッポリ稼ぐ!
  6. 6. この講義の内容 • 次のテーマを元にディスカッションを行う 安全な通信を実現するためにブラウザがしていること HTTPSを使えば本当に十分なのか考えてみよう Same Origin Policy(SOP)とは何か 自分の言葉でSOPを説明してみよう ブラウザがFetch APIに課した制限 APIの悪用を防ぐためにブラウザが禁止していることを学ぼう
  7. 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
  8. 8. 安全な通信を実現するために ブラウザがしていること
  9. 9. 問題 • 次のようなユーザ認証を行うサイトがある サーバとの通信にはどのような脅威があるか? どのようにすれば安全な通信ができるか? ログインのリクエスト ユーザ名=abc & パスワード=123… レスポンス セッションID=Zyxwv…
  10. 10. Phishing • 偽のサイトに誘導し、そこでパスワードなどの機微 な情報を入力させる 利用者を騙すために、本物のサイトと似た画面のデザインや URLが用いられることが多い ログインのリクエスト ユーザ名=abc & パスワード=123 よく見ると小文字のRN 送信内容が盗まれる
  11. 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
  12. 12. ブラウザのPhishing対策 • 本物と見分けの付かない偽のURL(続き) ChromeのIDN表示ルール(抜粋) https://www.chromium.org/developers/design-documents/idn-in-google-chrome URLに含まれる言語がユーザのロケールと一致すること 混在が許されない複数の文字集合がURLに存在しないこと 例えば、GreekとHiraganaが混在しないこと Safariはホワイトリストで許可した文字集合のみIDNで表示 https://support.apple.com/kb/TA22996?locale=ja_JP&viewlocale=en_US GreekやCyrillicを含むURLは全て禁止 ギリシャ語ドメインは表示できない 何故か絵文字はホワイトリストに含まれる
  13. 13. ブラウザのPhishing対策 • URLの偽装を根本的に防ぐのは難しい そもそもRFCに対策が難しいと書いてある http://jprs.co.jp/idn/rfc5890j.txt "紛らわしい文字の問題を統合的に解決する技術的対策が存在しないことは 注記に値する。この問題の影響範囲を限定する方法は様々なものが存在す るが、この問題を解消することはおそらくできないだろう。" EV SSL証明書は対策方法となりうる アドレスバーに運営組織名を表示 https://cabforum.org/ev-faq/ しかし訓練されていない利用者には効果が無いという指摘も http://www.usablesecurity.org/papers/jackson.pdf
  14. 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 それって検出精度は大丈夫?
  15. 15. ブラウザのPhishing対策 Firefox 38 Safari 8 Chrome 43
  16. 16. Pharming • DNS情報の改ざんにより、偽サイトへ誘導させる 利用者は正規のURLを指定しても偽サイトに誘導される URLを見ただけでは偽サイトだと判別できない ログインのリクエスト ユーザ名=abc & パスワード=123 正規サイトと同じURL 偽 DNSによる名前解決 偽のIPアドレス
  17. 17. Pharming • DNS情報はどこで改ざんされるのか hostsの改ざん、DNSサーバやルータへの攻撃など ドメイン名ハイジャック • これも根本的な対策が難しい問題 HTTPSにすれば、ある程度は防ぐことができる 偽のサーバとの接続は証明書検証エラーになる ドメイン名ハイジャックはHTTPSでも阻止できない ドメイン名を所有していれば正規のサーバ証明書を入手できる
  18. 18. Passive MITM • 通信路のデータ盗聴し、様々な情報を取得する 主に平文で流れるデータが対象 広範囲に及ぶ攻撃を仕掛けることができる 盗聴 盗聴
  19. 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. 20. Passive MITM • 平文で流れるデータは意外と多い HTTP, FTP, SMTP, POP, Telnet… HTTPSでも接続先のホスト名は平文で送信される TCP/IPのレイヤは暗号化されていない TLS拡張のSNI(Server Name Indication)も平文 • HTTPSを使えば防げるけれど サーバのパフォーマンス低下 証明書を定期的に更新する手間 サイトに接続できない端末の発生 プリインストールされているルート証明書の有効期限切れ 古いTLS規格や弱い暗号スイートのみをサポートする端末
  21. 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. 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. 23. Active MITM • 盗聴に加え、通信路のデータの改ざんを行うMITM 標的のWebサーバになりすまし、HTTPSの通信も盗聴/改ざん Passive MITMに比べて被害は局所的 https://example.jp/ 盗聴・改ざん
  24. 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. 25. ブラウザのActive MITM対策 • 証明書エラーのクリックスルー率を下げる クリックスルーの危険性を視覚的に訴えるUIに変更 Internet Explorer 6 Microsoft Edge (2015年7月時点の開発版)
  26. 26. ブラウザのActive MITM対策 • 証明書エラーのクリックスルー率を下げる(続き) クリックスルーを行う際のユーザ操作を増やす Safari 8 (1クリック) Firefox 39 (4クリック)
  27. 27. ブラウザのActive MITM対策 • HSTSによるクリックスルーの禁止 2015年6月現在、全ての主要ブラウザがHSTSをサポート Firefox 39 Chrome 43
  28. 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. 29. ブラウザのActive MITM対策 • Mixed Content(続き) Firefox 1(初回のみ警告を表示) Firefox 38(デフォルトでブロック)
  30. 30. PKI Attacks (with Active MITM) • 不正に発行されたサーバ証明書を悪用したMITM 認証局への侵入やオペレーションミス、暗号の危殆化などに より不正な証明書が発行される 不正に発行された証明書は正規の証明書と区別できない 従来のPKIの仕組みでは対処できない問題 https://example.jp/ 証明書を不正発行 HTTPS接続HTTPS接続
  31. 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. 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. 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. 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. 35. ここまでのまとめ • 安全な通信を実現するためにブラウザは様々な対策 を講じてきた 「HTTPSを使えば安全」ではない • 他にも様々な脅威とその対策が行われている サーバ秘密鍵の漏洩とその対策(Perfect Forward Secrecy) TLSのレコード分断(Cookie Cutter Attack) ブラウザの自発的なフォールバック(SSL 3.0 Fallback) and more!!
  36. 36. ここまでのまとめ • 技術的に未解決の問題はまだまだある Phishingの根絶 ドメイン名ハイジャック ルート証明書ストアに対する不正な証明書のインストール • 新しい機能の導入により生じる様々な問題もある 公開鍵ピンニングの運用ミスによるセルフDoS CTによる非公開ドメイン情報やアクセス数などの流出
  37. 37. Same Origin Policy(SOP)とは何か
  38. 38. 問題 • ブラウザにはSame Origin Policy(SOP)と呼ばれる コンテンツ分離の概念がある SOPとは何か? Origin(生成元)が用いられる理由は何故か? SOPの適用例にはどのようなものがあるか?
  39. 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. 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. 41. SOPの適用例① • 異なるOriginのオブジェクトは操作できない 次の場合、サブウィンドウのlocationの参照は禁止 var subwin = window.open('http://other.example.jp/'); var subloc = subwin.location; // 禁止
  42. 42. SOPの適用例① • 例外的に操作できるオブジェクトもある 次の場合、サブウィンドウのlocationの変更は許可 var subwin = window.open('http://other.example.jp/'); subwin.location = ‘http://www.ipa.or.jp’; // 許可
  43. 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. 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. 45. SOPと擬似URL • SOPが必ずしもOriginに基づく訳ではない window.openやiframeで開かれたabout:blankやjavascript: URL は親のドキュメント(ナビゲーション元)のOriginを継承 blob: URLはその元となるBlobを作成したOriginを継承 data: URLのOriginはブラウザによって大きく異なる(次頁) 親のオリジンを継承
  46. 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. 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で保護されていると思っていると痛い目に遭う
  48. 48. ブラウザがFetch APIに課した制限
  49. 49. Fetch API • HTTPによる非同期通信を提供する低水準のAPI 指定したURLに対するHTTPリクエスト送信/レスポンス受信 HTTPリクエストのメソッド、ヘッダ、ボディを指定可能 HTTPレスポンスのヘッダ、ボディを読み取り可能 2015年7月現在、ChromeとFirefoxで利用可能 http://example.jp/ HTTPリクエスト fetch(‘http://example.jp/path‘) HTTPレスポンス
  50. 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); });
  51. 51. ブラウザは何を制限すべきか 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); }); 常にボディを指定して良い? どんな文字を含めても良い? どんなヘッダの値を読んでも良い? どんな情報が含まれても良い? どんなURLを指定しても良い? どんなヘッダを指定しても良い? どんなメソッドを指定しても良い?
  52. 52. この講義のまとめ • Webには様々な脅威があり、ブラウザベンダは 個々に対策を講じてきた しかしWebの仕様は複雑かつ曖昧であり、その対策方法にも 一貫性が無かったり抜け漏れが生じたりする 対策する技術を加えたことで新たに生じる問題 後方互換性などの理由により技術的に未解決の問題 • 現状を理解し、それぞれの立場で今やれることを やってWebを安全にしていくしかない 今ある技術を正しく理解して使う 今の技術では未解決の問題を解決するために提案をする
  53. 53. 謝辞 本資料は下記の方々にレビューして頂きました。 この場を借りて御礼を申し上げます。 • 株式会社セキュアスカイ・テクノロジー はせがわようすけ様 • 富士ゼロックス株式会社 漆嶌賢二様 • トレンドマイクロ株式会社 木村仁美様

×