ウェブセキュリティのありがちな誤解を解説する
•
4 likes•5,465 views
PHPカンファレンス2020での講演資料です。 アジェンダ 誤解1: Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10: セキュリティ情報はウェブで収集する
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ウェブセキュリティのありがちな誤解を解説する
Similar to ウェブセキュリティのありがちな誤解を解説する (16)
More from Hiroshi Tokumaru
More from Hiroshi Tokumaru (20)
Recently uploaded
Recently uploaded (8)
ウェブセキュリティのありがちな誤解を解説する
- 2. アジェンダ 誤解1: Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10: セキュリティ情報はウェブで収集する 2
- 3. 自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社 代表 https://www.eg-secure.co.jp/ – 独立行政法人情報処理推進機構 非常勤研究員 https://www.ipa.go.jp/security/ – 著書「体系的に学ぶ 安全なWebアプリケーションの作り方」第2版 2018年6月21日 – YouTube チャンネル 徳丸浩のウェブセキュリティ講座 https://j.mp/web-sec-study 3
- 5. クッキーの属性 クッキーには下記の属性があるが… • Domain • Path • Expires (Max-Age) • Secure • HttpOnly • SameSite 5
- 6. Domain属性の誤解 • Domain属性の例 Set-Cookie: SESS=4F3BF15034A9B; domain=example.jp • Domain属性を設定すると、当該ドメインとサブドメインにクッキー が送られる domain=example.jp の場合、 example.jp に加えて、sub.example.jp 等 にもクッキーが送信される • Domain属性を指定しないと、元のホストにのみクッキーが送られる • サブドメインにクッキーを送る必要がなければ、domain属性は指定し ないのが正しい • たまに、「Domain属性を厳密に指定する」等の解説があるが間違い 6
- 7. Path属性の誤解 • Path属性の例 Set-Cookie: SESS=4F3BF15034A9B; path=/foo • Path属性を指定すると、そのディレクトリ（サブディレクトリ含む） へのリクエストにのみクッキーが送信される • Path属性を指定するとセキュリティが強化されるという説明がたまに あるが、セキュリティ上の効果はない • JavaScriptはオリジン（ホスト、ポート、スキーム）での制御なので、 ディレクトリは無関係であるため • 特定ディレクトリでのみクッキーを使いたい場合、Path属性を使うこ とは問題ないが、攻撃などによる漏洩を防げるわけではない 7
- 8. IPAセキュアプログラミング講座の解説（旧バージョン） • 対策4 Cookie属性の厳密な指定 Cookieの属性をより厳しい条件に設定する。 – Domain なるべく狭い範囲を指定する（なるべく長いドメイン名を指定する） – Path なるべく狭い範囲を指定する（なるべく長いパス・プレフィックスを指定す る） – max-ageまたはexpires 指定しないか、なるべく短い有効期間を設定する – Secure 暗号通信（https:）を使う場合は必ず指定する 8 https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/403.html （2013年7月7日のアーカイブ）
- 9. IPAセキュアプログラミング講座の解説（現バージョン） • 対策4 Cookie属性の厳密な指定 Cookieの属性をより厳しい条件に設定する。 – Domain 指定しない（Cookieを発行したサーバのみに送信） – Path なるべく狭い範囲を指定する（なるべく長いパス・プレフィックスを指定す る） – max-ageまたはexpires 指定しないか、なるべく短い有効期間を設定する – Secure 暗号通信（https:）を使う場合は必ず指定する ※注：以前あったpath属性による指定は効果がないため削除しました。 9 https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/403.html （現在）
- 10. Secure属性の誤解 • Secure属性の例 Set-Cookie: SESS=4F3BF15034A9B; Secure • Secure属性を指定すると、HTTPSリクエストにのみクッキーが付与さ れる • よくある誤解 : TCP80ポートを閉じていれば、Secure属性は不要 • 以下のURLでTCP80ポートを閉じていても、Cookieは平文で送信され る http://example.jp:443/ 10
- 11. HttpOnly属性の誤解 • HttpOnly属性の例 Set-Cookie: SESS=4F3BF15034A9B; HttpOnly • HttpOnly属性を指定すると、JavaScriptからアクセスできなくなる • よくある誤解: HttpOnlyを指定するだけでXSSの脅威を防げる • 正解: HttpOnlyを指定すると、Cookieの盗み出しができなくなるだけ で、秘密情報の盗み出しや不正操作はできてしまう。 11
- 12. 徳丸本2版添付の Bad Todo Listによるデモ 12
- 13. trap.example.com SameSite属性ってなに? : SameSite=none（旧来のデフォルト） • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=none（旧来のデフォルト）の場合 13 trap.example.com （罠サイト） POST GET trap.example.com example.jp （攻撃対象サイト） 元々Cookieがセットされていた らCookieが送信される（常に）
- 14. trap.example.com SameSite属性ってなに? : SameSite=Lax • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=Lax（Google Chromeの現在のデフォルト）の場合 14 trap.example.com （罠サイト） GETのみ trap.example.com example.jp （攻撃対象サイト） 元々Cookieがセットされていた らCookieが送信される （GETのみ）
- 15. trap.example.com SameSite属性ってなに? : SameSite=Strict • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=Strict の場合 15 trap.example.com （罠サイト） POST GET trap.example.com example.jp （攻撃対象サイト） 元々Cookieがセットされていて も、Cookieは一切送信されない
- 16. SameSiteのデフォルト変更によって… • CookieにSameSite=Laxを指定することで、CSRF脆弱性の防御になる • 例外は… – IE10や、古いスマホのブラウザ（SameSite属性に対応していないもの） – GETメソッドを受け付ける更新処理（たまによくある）では、SameSite=Laxで は突破されてしまう→POSTに限定すること • 古いブラウザも考慮して、当面は従来どおりトークンによる対策を推 奨 • 今後、モダンなブラウザはデフォルトがSameSite=Laxになる （Google Chromeでは実施済み） • POSTによるサイト遷移でCookieが必要なら、Cookieの属性として SameSite=None; Secureを指定する必要がある 16
- 18. 脆弱性の影響する範囲 • SQLインジェクション – データベース内のデータが全て影響を受ける（DBにつなぐ権限しだい） • クロスサイトスクリプティング(XSS) – 脆弱性のあるページと同一オリジン全体 • セッション管理系（Session Fixation等） – セッション全体（概ねサイト全体） • OSコマンドインジェクション、ディレクトリトラバーサル – サーバー全体 • … • CSRF – 脆弱性がある機能のみが影響を受ける 18
- 20. カード情報入力フォームを改ざんして入力中のカード情報を盗む Copyright © 2017-2020 EG Secure Solutions Inc. 20
- 21. カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(1) Copyright © 2017-2020 EG Secure Solutions Inc. 21
- 22. カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(2) Copyright © 2017-2020 EG Secure Solutions Inc. 22
- 23. 近年のクレジットカード情報漏洩事件は「保存しない情報」が漏れる • 改正割賦販売法施行（2018年6月）以降、クレジットカード情報を サーバーに保存（通過も）は禁止されている • 現実に、入力フォーム改ざんや、決済フローの改変によりカード情報 が漏洩する • 入力した内容が漏洩しているので、「保存してはいけない」セキュリ ティコードも漏洩する 23
- 25. 「EXILE TRIBE STATION ONLINE SHOP」への不正アクセス報告 個人情報流出状況 (1)原因 第三者によって「EXILE TRIBE STATION ONLINE SHOP」に不正アクセスされ、決済処理プ ログラムの改ざんが行われたため。 (2)個人情報流出の可能性があるお客様 2020年8月18日～2020年10月15日の期間中に「EXILE TRIBE STATION ONLINE SHOP」にお いて、新規にクレジットカード情報を会員登録いただいたお客様、又は既に会員登録により 登録済みのクレジットカード番号を変更されたお客様44,663名の以下のクレジットカード情 報。 【流出した可能性のあるクレジットカード情報】 ・クレジットカード名義人 ・クレジットカード番号 ・有効期限 ・セキュリティコード 25 元々保存されていた クレジットカード情報は 漏洩していない https://www.exiletribestation.jp/news_important.html より引用
- 28. 650万件のパスワードハッシュのうち540万件が1週間で解読 http://securitynirvana.blogspot.jp/2012/06/final-word-on-linkedin-leak.html より引用 https://twitter.com/jmgosney/statuses/213212108924522496 より引用 Surviving on little more than furious passion for many sleepless days, we now have over 90% of the leaked passwords recovered.
- 31. NVIDIA GTX 1080 Ti GPU 8発のモンスターマシン https://www.servethehome.com/password-cracking-with-8x-nvidia-gtx-1080-ti-gpus/ より引用 MD5ハッシュ 180G/s → 257G/s SHA1ハッシュ 63G/s → 95G/s
- 32. パスワードのハッシュ保存について • 現在、ハッシュ値からのパスワード復元の主流の方法はGPUによる総 当り • 並列計算が極めて容易で、コストを掛ければいくらでも高速化できる • ソルト化ハッシュでも、総当たりスピードはそれほど変わらない • パスワードの保存方法 – 現在のパスワード保存のベストプラクティスは、ソルト付きハッシュとスト レッチング – 実装には、信頼できるライブラリやフレームワークの機能利用を推奨 © 2013-2020 Hiroshi Tokumaru
- 34. 証明書の価格と暗号化強度は関係ない 34https://www.ssllabs.com/ssltest/analyze.html?d=www.tokumaru.org Issuer Let's Encrypt Authority X3
- 37. なぜTRACEメソッドは危険と思われていたか? • Cross-Site Tracing(XST)攻撃という2003年に発表された攻撃にTRACEメ ソッドが悪用される • XSS攻撃により、XHRでTRACEメソッドを飛ばすと… HTTP/1.1 200 OK Server: Apache Content-Length: 198 TRACE /auth/index.php HTTP/1.1 Host: example.jp Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4 Authorization: Basic eWFtYWRhOnBhc3N3b3Jk … • CookieヘッダやAuthorizationヘッダがXSSにより取得される 37
- 38. TRACEメソッドの現在 • XST脆弱性はブラウザ側で対処すべき問題という認識であり、主要ブ ラウザでは 2006年頃対応が完了 – IE : Windows XP SP2にて対応（当初は不完全） – Firefox : 1.0.5(2005年9月リリース) にて対応 – Google Chrome、Safari等 : 当初から安全 • 現在XST攻撃可能な主要ブラウザはない • 参考: 実はそんなに怖くないTRACEメソッド https://blog.tokumaru.org/2013/01/TRACE-method-is-not-so-dangerous-in-fact.html • 現実的な危険はあまりないが、TRACEメソッドの抑止は簡単に実現で き、副作用もないので、抑止しておきましょう 38
- 42. Fire Wall XSSによりイントラの内部のサーバーを攻撃する様子 © 2020 Hiroshi Tokumaru evil.example.com internal.example.jp 罠のサイト 攻撃対象 攻撃対象の 情報が 漏洩する 重要なお知らせ 至急会員情報を 確認下さい https://.... XSSの罠 https://internal.example.jp/?""><sc ript>.... evil.example.com
- 43. ウェブ脆弱性のうち受動的攻撃はイントラ内の攻撃が可能 • 以下がイントラネット内サイトの攻撃に悪用可能 – XSS – CSRF – DNSリバインディング – SSRF(Server Side Request Forgery) …これは能動的攻撃 • 現状ウイルス感染による攻撃（標的型攻撃、ランサムウェア）が成功 確率が高く、被害が目立つが、実はXSSによる内部サーバー侵入のト ライは既に観測されている 43
- 44. SSRF攻撃により内部サーバーを攻撃する様子 44https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー （192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできません。し かし、公開サーバーから内部のサーバーにはアクセスできる想定です。 攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、 内部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。
- 46. 情報収集どうやっていますか? • Googleで検索する（ググれカスとか言いますものね） • 検索上位から見ますよね • でも、検索上位が正しい記事なの? • SSRF(Server Side Request Forgery)を例に確認してみます 46
- 51. 件の記事と徳丸のブログ記事を比較してみる SSRF攻撃とは通常の方法ではアクセスできないサー バーに対して攻撃を仕掛ける手法の一つです。 攻撃者はインターネット上に公開サーバーには直接ア クセスできます。しかし内部サーバーへはアクセスで きません。しかし公開サーバーから内部サーバーへの アクセスはできる状態を仮定します。 この時、攻撃者は公開サーバーに対して攻撃コマンド を送信することで、公開サーバーを経由して内部サー バーに対して攻撃をしかけることができます。この時、 公開サーバーからのコマンドは正規コマンドとして処 理されます。これがSSRF攻撃の概要です。 SSRF攻撃とは、攻撃者から直接到達できないサーバー に対する攻撃手法の一種です。下図にSSRF攻撃の様子 を示します。 攻撃者からは、公開サーバーにはアクセスできますが、 内部のサーバーはファイアウォールで隔離されている ため外部から直接アクセスできません。しかし、公開 サーバーから内部のサーバーにはアクセスできる想定 です。 攻撃者は *何らかの方法で* 公開サーバーから内部の サーバーにリクエストを送信することにより、内部の サーバーを攻撃できる場合があります。これがSSRF攻 撃です。 51https://cybersecurity-jp.com/column/33568 より引用 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side- request-forgery.html より引用
- 53. 元ネタがあった 1980年代からSSRFがセキュリティ問題である、と指摘されていたと考えている理由はUNIXのリモー トシェルの仕様と注意事項にあります。現在のUNIX系OSにはそもそもリモートシェル系のコマンド （rコマンドと呼ばれるrshなど）はインストールされていない物が多いと思います。そこでrコマンド とは何か、簡単に説明します。 rコマンドの代表であるrshは名前の通り、リモートからシェルコマンドを実行する仕組みです。rshな どのrコマンドはホームディレクトリの.rhostファイルに実行を許可するホストとユーザー名を定義し てリモートコマンド実行を許可します。 ATTACKER1とSERVER1、SERVER2があり、SERVER1が攻撃対象だとします。 ATTACKER1 -> SERVER2 -> SERVER1 リモートシェルの仕組みを利用するとSERVER1が信頼するSERVER2にアクセスできれば、攻撃元とな るATTACKER1から攻撃対象となるSERVER1に攻撃可能になります。 53 リクエストフォージェリ – SSRFとCSRF – yohgaki's blog https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用
- 54. 件の記事と大垣さんのブログ記事を比較してみる SSRFと似た攻撃としてCSRFがあります。 CSRFは攻撃用のWebページを準備し、攻 撃用のURLを設定します。攻撃者はWeb サイトの訪問者に対して罠ページにアク セスさせて、攻撃用のURLをクリックさ せます。攻撃用URLをクリックしたユー ザーは正規のユーザーであると認識され るため、正しいリクエストとして処理さ れてしまいます。 1. 罠（攻撃用）のWebページを用意し、 攻撃用のURLを配置する 2. 攻撃目標のWebサイトの正規ユー ザーに罠ページにアクセスさせ、攻 撃用URLをクリックさせる 3. 攻撃目標のWebサイトに攻撃用URL が、正規ユーザーとして送られる 4. 攻撃目標のWebサイトは正規ユー ザーからのリクエストなので正しい リクエストとして処理する 54 https://cybersecurity-jp.com/column/33568 より引用 https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用
- 56. CSRFとSSRFの比較表 56 • SSRF サーバーが持つ権限・認証を利用して不正な命令を実行 • CSRF クライアントが持つ権限・認証を利用して不正な命令を実行 https://cybersecurity-jp.com/column/33568 より引用 https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用
- 63. ネット上のセキュリティ記事の現状と対策 • SEO技術の発展により、量産型のセキュリティ解説記事が検索上位に ある – 今回はSSRFで説明したが、SQLインジェクションやクロスサイトスクリプティ ングでも同様の傾向となる • 資金とSEOの動機のある企業が記事を量産している • もはや、「ググって上位の記事を参照する」方法では、質の高い記事 を見つけることはできない • 「検索上位にあるのにブクマが全然ない」、「ブクマはあるがコメン トのないものばかり」というのは一応の見分けにはなる • 最終的には、良質の記事を見分ける力量を読者が身につけるしかない • まずは徳丸本を読みましょう（宣伝） 63