ウェブセキュリティのありがちな誤解を解説する

1. ウェブセキュリティのありがちな誤解を解説する EG セキュアソリューションズ株式会社徳丸浩

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

4. 誤解1: Cookieは誤解がいっぱい 4

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

17. 誤解2: 脆弱性があるページにのみ影響がある 17

18. 脆弱性の影響する範囲 • SQLインジェクション – データベース内のデータが全て影響を受ける（DBにつなぐ権限しだい） • クロスサイトスクリプティング(XSS) – 脆弱性のあるページと同一オリジン全体 • セッション管理系（Session Fixation等） – セッション全体（概ねサイト全体） • OSコマンドインジェクション、ディレクトリトラバーサル – サーバー全体 • … • CSRF – 脆弱性がある機能のみが影響を受ける 18

19. 誤解3: 脆弱なECサイトはセキュリティコードを保存している 19

23. 近年のクレジットカード情報漏洩事件は「保存しない情報」が漏れる • 改正割賦販売法施行（2018年6月）以降、クレジットカード情報をサーバーに保存（通過も）は禁止されている • 現実に、入力フォーム改ざんや、決済フローの改変によりカード情報が漏洩する • 入力した内容が漏洩しているので、「保存してはいけない」セキュリティコードも漏洩する 23

24. 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 24

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 より引用

26. カード情報はサイトに保存した方が漏洩しにくい • カード情報「非保持化」に伴い、攻撃手法も、入力中のデータを盗む方法に移行している • クレジットカード情報をサイト（多くの場合決済代行事業者）に保存すると、カード情報を入力する場面がなくなるので、漏洩リスクも減る 26

27. 誤解5: ハッシュ値で保存されたパスワードは復元されない 27

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.

29. 25GPUのモンスターマシン（パスワード解析用!） http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用

30. ベンチマーク http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用 1秒間に1800億回のMD5ハッシュ値計算! ↓ 8文字英数字パスワード（約220 兆パターン）のMD5ハッシュ値をすべて計算するのに、20分しか掛からない! SHA1でも60分

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

33. 誤解6: 高価なSSL証明書ほど暗号強度が高い 33

34. 証明書の価格と暗号化強度は関係ない 34https://www.ssllabs.com/ssltest/analyze.html?d=www.tokumaru.org Issuer Let's Encrypt Authority X3

35. 証明書の価格と暗号化強度の関係 • 証明書の価格と暗号化強度はまったく関係ない • 無料の証明書でも、暗号的に強固な設定は可能 35

36. 誤解7: TRACEメソッドの有効化は危険な脆弱性である 36

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

39. 誤解8: 怪しいサイトを閲覧すると情報が盗まれたり、ウイルスに感染する 39

40. 罠サイトを閲覧してマルウェアに感染する様子 40 ③マルウェアに感染罠サイト ①罠サイトを閲覧 ②仕掛けのあるHTML ブラウザやブラウザのプラグインに脆弱性がなければ、「怪しいサイト」を閲覧しただけでマルウェア感染することはない。ブラウザを常に最新の状態にしましょう。「怪しいサイト」を閲覧したら自動的にウイルス感染するわけてばありません。

41. 誤解9: イントラのウェブサイトは外部からは攻撃できない 41

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攻撃です。

45. 誤解10: セキュリティ情報はウェブで収集する 45

46. 情報収集どうやっていますか? • Googleで検索する（ググれカスとか言いますものね） • 検索上位から見ますよね • でも、検索上位が正しい記事なの? • SSRF(Server Side Request Forgery)を例に確認してみます 46

47. 最近話題の脆弱性SSRFでググってみた 47 Google検索より検索トップの記事を読んでみよう

48. 記事の冒頭と目次 48https://cybersecurity-jp.com/column/33568 より引用

49. SSRF攻撃とは通常の方法ではアクセスできないサーバーに対して攻撃を仕掛ける手法の一つです。攻撃者はインターネット上に公開サーバーには直接アクセスできます。しかし内部サーバーへはアクセスできません。しかし公開サーバーから内部サーバーへのアクセスはできる状態を仮定します。この時、攻撃者は公開サーバーに対して攻撃コマンドを送信することで、公開サーバーを経由して内部サーバーに対して攻撃をしかけることができます。この時、公開サーバーからのコマンドは正規コマンドとして処理されます。これがSSRF攻撃の概要です。 SSRF攻撃とは（件の記事） 49https://cybersecurity-jp.com/column/33568 より引用

50. SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできません。しかし、公開サーバーから内部のサーバーにはアクセスできる想定です。攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、内部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。 SSRF攻撃とは（徳丸のブログ記事より） 50https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用

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 より引用

52. SSRF攻撃の仕組み 52https://cybersecurity-jp.com/column/33568 より引用

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 より引用

55. CSRFとSSRFの違い(?) 55https://cybersecurity-jp.com/column/33568 より引用

56. CSRFとSSRFの比較表 56 • SSRF サーバーが持つ権限・認証を利用して不正な命令を実行 • CSRF クライアントが持つ権限・認証を利用して不正な命令を実行 https://cybersecurity-jp.com/column/33568 より引用 https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用

57. SSRFの対策ファイアウォールファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必要があります。注意点として、SSRF攻撃ではない正常のアクセスについて制限してしまうと、本来の目的が果たせなくなってしまいます。プロキシブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにおいてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、デフォルトでプロキシ経由にならないことにも気を付ける必要があります。インターセプト Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエストの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトできるわけではありません。 57https://cybersecurity-jp.com/column/33568 より引用

58. 元ネタがあったファイアウォールまずはファイアウォール（FW）による対策です。FWにも種類がありますが、少なくともローカルホストへのアクセス制限については、それができるホスト型のものを使用する必要があります。… プロキシブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセスをプロキシに転送します。そして、プロキシ側（プロキシ自体の設定、またはプロキシを置くNW/サーバの設定）でアクセスを制御する方式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全ての通信をプロキシ経由にするわけではないということです。少なくともWebRTCの通信についてはプロキシ経由になりません。またループバックアドレス宛の通信がデフォルトではプロキシ経由にならない点に注意が必要です。インターセプト Puppeteerはリクエストのインターセプト機能を提供しており、これを使うとリクエストの送信先などを制御できます。やられサイトの最終版ではこれを使っていますが、プロキシと同様に全ての通信がインターセプトできるわけではないという問題があります。… 58https://www.mbsd.jp/blog/20190605.html より引用

59. 件の記事と寺田さんのブログ記事を比較してみるファイアウォールファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必要があります。プロキシブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにおいてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、デフォルトでプロキシ経由にならないことにも気を付ける必要があります。インターセプト Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエストの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトできるわけではありません。ファイアウォールまずはファイアウォール（FW）による対策です。FWにも種類がありますが、少なくともローカルホストへのアクセス制限については、それができるホスト型のものを使用する必要があります。プロキシブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセスをプロキシに転送します。そして、プロキシ側（プロキシ自体の設定、またはプロキシを置くNW/サーバの設定）でアクセスを制御する方式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全ての通信をプロキシ経由にするわけではないということです。少なくともWebRTCの通信についてはプロキシ経由になりません。またループバックアドレス宛の通信がデフォルトではプロキシ経由にならない点に注意が必要です。インターセプト Puppeteerはリクエストのインターセプト機能を提供しており、これを使うとリクエストの送信先などを制御できます。やられサイトの最終版ではこれを使っていますが、プロキシと同様に全ての通信がインターセプトできるわけではないという問題があります。… 59 https://cybersecurity-jp.com/column/33568 より引用 https://www.mbsd.jp/blog/20190605.html より引用

60. 寺田さんのブログ記事はヘッドレスブラウザを使う場合のもの 60https://www.mbsd.jp/blog/20190605.html より引用

61. 記事の構成はこう 61 徳丸浩の日記より転載・改変 piyologより転載・改変 MBSD寺田さんの日記より転載・改変大垣さんのブログより転載・改変大垣さんのブログより転載・改変独自の作文?

62. キメラのように、既存記事を組み合わせて新しい記事をつくる 62 徳丸浩の日記 piyolog MBSD寺田さんのブログ記事大垣さんのブログ記事

63. ネット上のセキュリティ記事の現状と対策 • SEO技術の発展により、量産型のセキュリティ解説記事が検索上位にある – 今回はSSRFで説明したが、SQLインジェクションやクロスサイトスクリプティングでも同様の傾向となる • 資金とSEOの動機のある企業が記事を量産している • もはや、「ググって上位の記事を参照する」方法では、質の高い記事を見つけることはできない • 「検索上位にあるのにブクマが全然ない」、「ブクマはあるがコメントのないものばかり」というのは一応の見分けにはなる • 最終的には、良質の記事を見分ける力量を読者が身につけるしかない • まずは徳丸本を読みましょう（宣伝） 63

64. Thank you! 質問、感想はDiscordでお待ちしています 64

ウェブセキュリティのありがちな誤解を解説する

Estás leyendo una previsualización.

Eche un vistazo a continuación

ウェブセキュリティのありがちな誤解を解説する

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a ウェブセキュリティのありがちな誤解を解説する (12)

Más de Hiroshi Tokumaru (20)

Más reciente (20)