ウェブセキュリティのありがちな誤解を解説する
Dec. 12, 2020•0 likes•5,240 views
Report
Technology
PHPカンファレンス2020での講演資料です。 アジェンダ 誤解1: Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10: セキュリティ情報はウェブで収集する
Hiroshi TokumaruFollow
More Related Content
What's hot
開発速度が速い #とは（LayerX社内資料）mosa siru
マルチテナントのアプリケーション実装〜実践編〜Yoshiki Nakagawa
SQLインジェクション総”習”編Yasuo Ohgaki
Spanner移行について本気出して考えてみたtechgamecollege
CyberAgentのプライベートクラウド Cycloudの運用及びモニタリングについて #CODT2020 / Administration and M...whywaita
マルチテナント化で知っておきたいデータベースのことAmazon Web Services Japan
Similar to ウェブセキュリティのありがちな誤解を解説する
オンラインバンキングのセキュリティ技術の動向（完全版）Fusion Reactor LLC
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版）Shinobu Yasuda
ウェブセキュリティの最近の話題早分かりHiroshi Tokumaru
Infomation Card と Windows CardSpace のご紹介shigeya
情報セキュリティexpo(2015) テコラスブースセッション eco_proNHN テコラス株式会社
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜Riotaro OKADA
More from Hiroshi Tokumaru
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証するHiroshi Tokumaru
徳丸本VMに脆弱なWordPressを導入するHiroshi Tokumaru
introduction to unsafe deserialization part1Hiroshi Tokumaru
XXE、SSRF、安全でないデシリアライゼーション入門Hiroshi Tokumaru
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)Hiroshi Tokumaru
Railsエンジニアのためのウェブセキュリティ入門Hiroshi Tokumaru
Recently uploaded
NoSQL/SQLデュアルインターフェースを備えた IoT向けデータベースGridDB - 強化された時系列データ管理・検索機能について -griddb
骨抜きアジャイルの骨を生み出す 〜私（スクラムマスター）のXP学習記録〜（XP祭り2023 発表資料）NTT DATA Technology & Innovation
MLOps Course Slides_JP（配布用）.pdfYuya Yamamoto
遠征ドルヲタのための便利サイトを作ってみたKenta Fujimoto
画像生成AIの問題点iPride Co., Ltd.
インフラチームとCCoEの関係.pptxssuser5c7ee4
ウェブセキュリティのありがちな誤解を解説する
- 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