ウェブセキュリティのありがちな誤解を解説する
61.7K Views
December 12, 20
スライド概要
PHPカンファレンス2020での講演資料です。
関連スライド
SPAセキュリティ超入門
徳丸 浩
806.9K
各ページのテキスト
ウェブセキュリティのありがちな誤解を解説する EG セキュアソリューションズ株式会社 徳丸 浩
アジェンダ 誤解1: Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10: セキュリティ情報はウェブで収集する 2
自己紹介 • 経歴 – 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
誤解1: Cookieは誤解がいっぱい 4
クッキーの属性 クッキーには下記の属性があるが… • • • • • • Domain Path Expires (Max-Age) Secure HttpOnly SameSite 5
Domain属性の誤解 • Domain属性の例 Set-Cookie: SESS=4F3BF15034A9B; domain=example.jp • Domain属性を設定すると、当該ドメインとサブドメインにクッキー が送られる domain=example.jp の場合、 example.jp に加えて、sub.example.jp 等 にもクッキーが送信される • Domain属性を指定しないと、元のホストにのみクッキーが送られる • サブドメインにクッキーを送る必要がなければ、domain属性は指定し ないのが正しい • たまに、「Domain属性を厳密に指定する」等の解説があるが間違い 6
Path属性の誤解 • Path属性の例 Set-Cookie: SESS=4F3BF15034A9B; path=/foo • Path属性を指定すると、そのディレクトリ（サブディレクトリ含む） へのリクエストにのみクッキーが送信される • Path属性を指定するとセキュリティが強化されるという説明がたまに あるが、セキュリティ上の効果はない • JavaScriptはオリジン（ホスト、ポート、スキーム）での制御なので、 ディレクトリは無関係であるため • 特定ディレクトリでのみクッキーを使いたい場合、Path属性を使うこ とは問題ないが、攻撃などによる漏洩を防げるわけではない 7
IPAセキュアプログラミング講座の解説（旧バージョン） • 対策4 Cookie属性の厳密な指定 Cookieの属性をより厳しい条件に設定する。 – Domain なるべく狭い範囲を指定する（なるべく長いドメイン名を指定する） – Path なるべく狭い範囲を指定する（なるべく長いパス・プレフィックスを指定す る） – max-ageまたはexpires 指定しないか、なるべく短い有効期間を設定する – Secure 暗号通信（https:）を使う場合は必ず指定する https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/403.html （2013年7月7日のアーカイブ） 8
IPAセキュアプログラミング講座の解説（現バージョン） • 対策4 Cookie属性の厳密な指定 Cookieの属性をより厳しい条件に設定する。 – Domain 指定しない（Cookieを発行したサーバのみに送信） – Path なるべく狭い範囲を指定する（なるべく長いパス・プレフィックスを指定す る） – max-ageまたはexpires 指定しないか、なるべく短い有効期間を設定する – Secure 暗号通信（https:）を使う場合は必ず指定する ※注：以前あったpath属性による指定は効果がないため削除しました。 https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/403.html （現在） 9
Secure属性の誤解 • Secure属性の例 Set-Cookie: SESS=4F3BF15034A9B; Secure • Secure属性を指定すると、HTTPSリクエストにのみクッキーが付与さ れる • よくある誤解 : TCP80ポートを閉じていれば、Secure属性は不要 • 以下のURLでTCP80ポートを閉じていても、Cookieは平文で送信され る http://example.jp:443/ 10
HttpOnly属性の誤解 • HttpOnly属性の例 Set-Cookie: SESS=4F3BF15034A9B; HttpOnly • HttpOnly属性を指定すると、JavaScriptからアクセスできなくなる • よくある誤解: HttpOnlyを指定するだけでXSSの脅威を防げる • 正解: HttpOnlyを指定すると、Cookieの盗み出しができなくなるだけ で、秘密情報の盗み出しや不正操作はできてしまう。 11
徳丸本2版添付の Bad Todo Listによるデモ 12
SameSite属性ってなに? : SameSite=none（旧来のデフォルト） • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=none（旧来のデフォルト）の場合 trap.example.com trap.example.com trap.example.com （罠サイト） example.jp （攻撃対象サイト） POST GET 元々Cookieがセットされていた らCookieが送信される（常に） 13
SameSite属性ってなに? : SameSite=Lax • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=Lax（Google Chromeの現在のデフォルト）の場合 trap.example.com trap.example.com trap.example.com （罠サイト） example.jp （攻撃対象サイト） GETのみ 元々Cookieがセットされていた らCookieが送信される （GETのみ） 14
SameSite属性ってなに? : SameSite=Strict • SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信 するかどうかを制御するもの • SameSite=Strict の場合 trap.example.com trap.example.com trap.example.com （罠サイト） example.jp （攻撃対象サイト） POST GET 元々Cookieがセットされていて も、Cookieは一切送信されない 15
SameSiteのデフォルト変更によって… • CookieにSameSite=Laxを指定することで、CSRF脆弱性の防御になる • 例外は… – IE10や、古いスマホのブラウザ（SameSite属性に対応していないもの） – GETメソッドを受け付ける更新処理（たまによくある）では、SameSite=Laxで は突破されてしまう→POSTに限定すること • 古いブラウザも考慮して、当面は従来どおりトークンによる対策を推 奨 • 今後、モダンなブラウザはデフォルトがSameSite=Laxになる （Google Chromeでは実施済み） • POSTによるサイト遷移でCookieが必要なら、Cookieの属性として SameSite=None; Secureを指定する必要がある 16
誤解2: 脆弱性があるページにのみ影響がある 17
脆弱性の影響する範囲 • SQLインジェクション – データベース内のデータが全て影響を受ける（DBにつなぐ権限しだい） • クロスサイトスクリプティング(XSS) – 脆弱性のあるページと同一オリジン全体 • セッション管理系（Session Fixation等） – セッション全体（概ねサイト全体） • OSコマンドインジェクション、ディレクトリトラバーサル – サーバー全体 • … • CSRF – 脆弱性がある機能のみが影響を受ける 18
誤解3: 脆弱なECサイトはセキュリティコー ドを保存している 19
カード情報入力フォームを改ざんして入力中のカード情報を盗む Copyright © 2017-2020 EG Secure Solutions Inc. 20
カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(1) Copyright © 2017-2020 EG Secure Solutions Inc. 21
カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(2) Copyright © 2017-2020 EG Secure Solutions Inc. 22
近年のクレジットカード情報漏洩事件は「保存しない情報」が漏れる • 改正割賦販売法施行（2018年6月）以降、クレジットカード情報を サーバーに保存（通過も）は禁止されている • 現実に、入力フォーム改ざんや、決済フローの改変によりカード情報 が漏洩する • 入力した内容が漏洩しているので、「保存してはいけない」セキュリ ティコードも漏洩する 23
誤解4: クレジットカードをサイトに保存する と漏洩リスクが高まる 24
「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名の以下のクレジットカード情 報。 【流出した可能性のあるクレジットカード情報】 元々保存されていた ・クレジットカード名義人 クレジットカード情報は ・クレジットカード番号 漏洩していない ・有効期限 ・セキュリティコード https://www.exiletribestation.jp/news_important.html より引用 25
カード情報はサイトに保存した方が漏洩しにくい • カード情報「非保持化」に伴い、攻撃手法も、入力中のデータを盗む 方法に移行している • クレジットカード情報をサイト（多くの場合決済代行事業者）に保存 すると、カード情報を入力する場面がなくなるので、漏洩リスクも減 る 26
誤解5: ハッシュ値で保存されたパスワードは 復元されない 27
650万件のパスワードハッシュのうち540万件が1週間で解読 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. http://securitynirvana.blogspot.jp/2012/06/final-word-on-linkedin-leak.html より引用
25GPUのモンスターマシン（パスワード解析用!） http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用
ベンチマーク 1秒間に1800億回のMD5ハッ シュ値計算! ↓ 8文字英数字パスワード（約220 兆パターン）のMD5ハッシュ値 をすべて計算するのに、20分し か掛からない! SHA1でも60分 http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用
NVIDIA GTX 1080 Ti GPU 8発のモンスターマシン MD5ハッシュ 180G/s → 257G/s SHA1ハッシュ 63G/s → 95G/s https://www.servethehome.com/password-cracking-with-8x-nvidia-gtx-1080-ti-gpus/ より引用
パスワードのハッシュ保存について • 現在、ハッシュ値からのパスワード復元の主流の方法はGPUによる総 当り • 並列計算が極めて容易で、コストを掛ければいくらでも高速化できる • ソルト化ハッシュでも、総当たりスピードはそれほど変わらない • パスワードの保存方法 – 現在のパスワード保存のベストプラクティスは、ソルト付きハッシュとスト レッチング – 実装には、信頼できるライブラリやフレームワークの機能利用を推奨 © 2013-2020 Hiroshi Tokumaru
誤解6: 高価なSSL証明書ほど暗号強度が高い 33
証明書の価格と暗号化強度は関係ない Issuer Let's Encrypt Authority X3 https://www.ssllabs.com/ssltest/analyze.html?d=www.tokumaru.org 34
証明書の価格と暗号化強度の関係 • 証明書の価格と暗号化強度はまったく関係ない • 無料の証明書でも、暗号的に強固な設定は可能 35
誤解7: TRACEメソッドの有効化は危険な脆弱 性である 36
なぜ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
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
誤解8: 怪しいサイトを閲覧すると情報が盗ま れたり、ウイルスに感染する 39
罠サイトを閲覧してマルウェアに感染する様子 ①罠サイトを閲覧 ③マルウェア に感染 ②仕掛けのあるHTML 罠サイト ブラウザやブラウザのプラグインに脆弱性がなければ、「怪しいサイト」を閲覧 しただけでマルウェア感染することはない。ブラウザを常に最新の状態にしま しょう。 「怪しいサイト」を閲覧したら自動的にウイルス感染するわけてばありません。 40
誤解9: イントラのウェブサイトは外部からは 攻撃できない 41
XSSによりイントラの内部のサーバーを攻撃する様子 evil.example.com evil.example.com 罠のサイト XSSの罠 重要なお知らせ https://internal.example.jp/?""><sc ript>....至急会員情報を 確認下さい Fire Wall https://.... internal.example.jp 攻撃対象 © 2020 Hiroshi Tokumaru 攻撃対象の 情報が 漏洩する
ウェブ脆弱性のうち受動的攻撃はイントラ内の攻撃が可能 • 以下がイントラネット内サイトの攻撃に悪用可能 – – – – XSS CSRF DNSリバインディング SSRF(Server Side Request Forgery) …これは能動的攻撃 • 現状ウイルス感染による攻撃（標的型攻撃、ランサムウェア）が成功 確率が高く、被害が目立つが、実はXSSによる内部サーバー侵入のト ライは既に観測されている 43
SSRF攻撃により内部サーバーを攻撃する様子 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー （192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできません。し かし、公開サーバーから内部のサーバーにはアクセスできる想定です。 攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、 内部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用 44
誤解10: セキュリティ情報はウェブで収集する 45
情報収集どうやっていますか? • Googleで検索する（ググれカスとか言いますものね） • 検索上位から見ますよね • でも、検索上位が正しい記事なの? • SSRF(Server Side Request Forgery)を例に確認してみます 46
最近話題の脆弱性SSRFでググってみた 検索トップの記事を読んでみよう Google検索より 47
記事の冒頭と目次 https://cybersecurity-jp.com/column/33568 より引用 48
SSRF攻撃とは（件の記事） SSRF攻撃とは通常の方法ではアクセスできないサーバーに対して攻撃を仕掛ける手法の一つです。 攻撃者はインターネット上に公開サーバーには直接アクセスできます。しかし内部サーバーへはアク セスできません。しかし公開サーバーから内部サーバーへのアクセスはできる状態を仮定します。 この時、攻撃者は公開サーバーに対して攻撃コマンドを送信することで、公開サーバーを経由して内 部サーバーに対して攻撃をしかけることができます。この時、公開サーバーからのコマンドは正規コ マンドとして処理されます。これがSSRF攻撃の概要です。 https://cybersecurity-jp.com/column/33568 より引用 49
SSRF攻撃とは（徳丸のブログ記事より） SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃 の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー （192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできません。しかし、 公開サーバーから内部のサーバーにはアクセスできる想定です。 攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、内 部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用 50
件の記事と徳丸のブログ記事を比較してみる SSRF攻撃とは通常の方法ではアクセスできないサー バーに対して攻撃を仕掛ける手法の一つです。 攻撃者はインターネット上に公開サーバーには直接ア クセスできます。しかし内部サーバーへはアクセスで きません。しかし公開サーバーから内部サーバーへの アクセスはできる状態を仮定します。 この時、攻撃者は公開サーバーに対して攻撃コマンド を送信することで、公開サーバーを経由して内部サー バーに対して攻撃をしかけることができます。この時、 公開サーバーからのコマンドは正規コマンドとして処 理されます。これがSSRF攻撃の概要です。 https://cybersecurity-jp.com/column/33568 より引用 SSRF攻撃とは、攻撃者から直接到達できないサーバー に対する攻撃手法の一種です。下図にSSRF攻撃の様子 を示します。 攻撃者からは、公開サーバーにはアクセスできますが、 内部のサーバーはファイアウォールで隔離されている ため外部から直接アクセスできません。しかし、公開 サーバーから内部のサーバーにはアクセスできる想定 です。 攻撃者は *何らかの方法で* 公開サーバーから内部の サーバーにリクエストを送信することにより、内部の サーバーを攻撃できる場合があります。これがSSRF攻 撃です。 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-siderequest-forgery.html より引用 51
SSRF攻撃の仕組み https://cybersecurity-jp.com/column/33568 より引用 52
元ネタがあった 1980年代からSSRFがセキュリティ問題である、と指摘されていたと考えている理由はUNIXのリモー トシェルの仕様と注意事項にあります。現在のUNIX系OSにはそもそもリモートシェル系のコマンド （rコマンドと呼ばれるrshなど）はインストールされていない物が多いと思います。そこでrコマンド とは何か、簡単に説明します。 rコマンドの代表であるrshは名前の通り、リモートからシェルコマンドを実行する仕組みです。rshな どのrコマンドはホームディレクトリの.rhostファイルに実行を許可するホストとユーザー名を定義し てリモートコマンド実行を許可します。 ATTACKER1とSERVER1、SERVER2があり、SERVER1が攻撃対象だとします。 ATTACKER1 -> SERVER2 -> SERVER1 リモートシェルの仕組みを利用するとSERVER1が信頼するSERVER2にアクセスできれば、攻撃元とな るATTACKER1から攻撃対象となるSERVER1に攻撃可能になります。 リクエストフォージェリ – SSRFとCSRF – yohgaki's blog https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 53
件の記事と大垣さんのブログ記事を比較してみる SSRFと似た攻撃としてCSRFがあります。 CSRFは攻撃用のWebページを準備し、攻 撃用のURLを設定します。攻撃者はWeb サイトの訪問者に対して罠ページにアク セスさせて、攻撃用のURLをクリックさ せます。攻撃用URLをクリックしたユー ザーは正規のユーザーであると認識され るため、正しいリクエストとして処理さ れてしまいます。 1. 罠（攻撃用）のWebページを用意し、 攻撃用のURLを配置する 2. 攻撃目標のWebサイトの正規ユー ザーに罠ページにアクセスさせ、攻 撃用URLをクリックさせる 3. 攻撃目標のWebサイトに攻撃用URL が、正規ユーザーとして送られる 4. 攻撃目標のWebサイトは正規ユー ザーからのリクエストなので正しい リクエストとして処理する https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 https://cybersecurity-jp.com/column/33568 より引用 54
CSRFとSSRFの違い(?) https://cybersecurity-jp.com/column/33568 より引用 55
CSRFとSSRFの比較表 https://cybersecurity-jp.com/column/33568 より引用 • SSRF サーバーが持つ権限・認証を利用して不正な命令を実行 • CSRF クライアントが持つ権限・認証を利用して不正な命令を実行 https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 56
SSRFの対策 ファイアウォール ファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように 制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必 要があります。注意点として、SSRF攻撃ではない正常のアクセスについて制限してしまうと、本来の 目的が果たせなくなってしまいます。 プロキシ ブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにお いてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプ ロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、 デフォルトでプロキシ経由にならないことにも気を付ける必要があります。 インターセプト Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエ ストの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトでき るわけではありません。 https://cybersecurity-jp.com/column/33568 より引用 57
元ネタがあった ファイアウォール まずはファイアウォール（FW）による対策です。FWにも種類がありますが、少なくともローカルホ ストへのアクセス制限については、それができるホスト型のものを使用する必要があります。… プロキシ ブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセスをプロキシに転送します。そして、プ ロキシ側（プロキシ自体の設定、またはプロキシを置くNW/サーバの設定）でアクセスを制御する方 式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全ての通信をプロキシ経由にするわけではな いということです。少なくともWebRTCの通信についてはプロキシ経由になりません。またループ バックアドレス宛の通信がデフォルトではプロキシ経由にならない点に注意が必要です。 インターセプト Puppeteerはリクエストのインターセプト機能を提供しており、これを使うとリクエストの送信先な どを制御できます。やられサイトの最終版ではこれを使っていますが、プロキシと同様に全ての通信 がインターセプトできるわけではないという問題があります。… https://www.mbsd.jp/blog/20190605.html より引用 58
件の記事と寺田さんのブログ記事を比較してみる ファイアウォール ファイアウォールの設定により、攻撃者が接続先となる攻撃 対象を指定しても、接続できないように制限する方法が有効 です。少なくともローカルホストに対するアクセスについて は厳しく制限する必要があります。 プロキシ ブラウザにプロキシを設定して全てのアクセスをプロキシ経 由にする方法です。そしてプロキシにおいてアクセス制御を 行います。プロキシを設定する方法の注意点として、ブラウ ザが全ての通信をプロキシ経由にするとは限らない点があげ られます。さらにループバックアドレスへの通信については、 デフォルトでプロキシ経由にならないことにも気を付ける必 要があります。 インターセプト Puppeteerのようにリクエストのインターセプト機能を持つ ツールを使用している場合には、リクエストの送信先などを 制御することができます。しかしこの方法では全ての通信を インターセプトできるわけではありません。 https://cybersecurity-jp.com/column/33568 より引用 ファイアウォール まずはファイアウォール（FW）による対策です。FWにも種 類がありますが、少なくともローカルホストへのアクセス制 限については、それができるホスト型のものを使用する必要 があります。 プロキシ ブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセ スをプロキシに転送します。そして、プロキシ側（プロキシ 自体の設定、またはプロキシを置くNW/サーバの設定）でア クセスを制御する方式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全て の通信をプロキシ経由にするわけではないということです。 少なくともWebRTCの通信についてはプロキシ経由になりま せん。またループバックアドレス宛の通信がデフォルトでは プロキシ経由にならない点に注意が必要です。 インターセプト Puppeteerはリクエストのインターセプト機能を提供してお り、これを使うとリクエストの送信先などを制御できます。 やられサイトの最終版ではこれを使っていますが、プロキシ と同様に全ての通信がインターセプトできるわけではないと いう問題があります。… https://www.mbsd.jp/blog/20190605.html より引用 59
寺田さんのブログ記事はヘッドレスブラウザを使う場合のもの https://www.mbsd.jp/blog/20190605.html より引用 60
記事の構成はこう 徳丸浩の日記より転載・ 改変 大垣さんのブログより 転載・改変 piyologより転載・改変 大垣さんのブログより 転載・改変 独自の作文? MBSD寺田さんの日記 より転載・改変 61
キメラのように、既存記事を組み合わせて新しい記事をつくる 徳丸浩の日記 大垣さんの ブログ記事 piyolog MBSD寺田さん のブログ記事 62
ネット上のセキュリティ記事の現状と対策 • SEO技術の発展により、量産型のセキュリティ解説記事が検索上位に ある – 今回はSSRFで説明したが、SQLインジェクションやクロスサイトスクリプティ ングでも同様の傾向となる • 資金とSEOの動機のある企業が記事を量産している • もはや、「ググって上位の記事を参照する」方法では、質の高い記事 を見つけることはできない • 「検索上位にあるのにブクマが全然ない」、「ブクマはあるがコメン トのないものばかり」というのは一応の見分けにはなる • 最終的には、良質の記事を見分ける力量を読者が身につけるしかない • まずは徳丸本を読みましょう（宣伝） 63
Thank you! 質問、感想はDiscordでお待ちしています 64