---
title: ウェブセキュリティのありがちな誤解を解説する
tags:  #security #php  
author: [徳丸 浩](https://www.docswell.com/user/ockeghem)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PL711QK47G.jpg?width=480
description: PHPカンファレンス2020での講演資料です。
published: December 12, 20
canonical: https://www.docswell.com/s/ockeghem/K44J1K-phpconf2020
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/PL711QK47G.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/8G7W8MDZE2.jpg)

アジェンダ
誤解1: Cookieは誤解がいっぱい
誤解2: 脆弱性があるページにのみ影響がある
誤解3: 脆弱なECサイトはセキュリティコードを保存している
誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる
誤解5: ハッシュ値で保存されたパスワードは復元されない
誤解6: 高価なSSL証明書ほど暗号強度が高い
誤解7: TRACEメソッドの有効化は危険な脆弱性である
誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する
誤解9: イントラのウェブサイトは外部からは攻撃できない
誤解10: セキュリティ情報はウェブで収集する
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/W4JZ8QGL73.jpg)

自己紹介
• 経歴
– 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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/KYE6P6YMJV.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5GE5K6GQ74.jpg)

クッキーの属性
クッキーには下記の属性があるが…
•
•
•
•
•
•
Domain
Path
Expires (Max-Age)
Secure
HttpOnly
SameSite
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/V972WMYWJR.jpg)

Domain属性の誤解
• Domain属性の例
Set-Cookie: SESS=4F3BF15034A9B; domain=example.jp
• Domain属性を設定すると、当該ドメインとサブドメインにクッキー
が送られる
domain=example.jp の場合、 example.jp に加えて、sub.example.jp 等
にもクッキーが送信される
• Domain属性を指定しないと、元のホストにのみクッキーが送られる
• サブドメインにクッキーを送る必要がなければ、domain属性は指定し
ないのが正しい
• たまに、「Domain属性を厳密に指定する」等の解説があるが間違い
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5DJYLXG97M.jpg)

Path属性の誤解
• Path属性の例
Set-Cookie: SESS=4F3BF15034A9B; path=/foo
• Path属性を指定すると、そのディレクトリ（サブディレクトリ含む）
へのリクエストにのみクッキーが送信される
• Path属性を指定するとセキュリティが強化されるという説明がたまに
あるが、セキュリティ上の効果はない
• JavaScriptはオリジン（ホスト、ポート、スキーム）での制御なので、
ディレクトリは無関係であるため
• 特定ディレクトリでのみクッキーを使いたい場合、Path属性を使うこ
とは問題ないが、攻撃などによる漏洩を防げるわけではない
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/2V7N41GDJ8.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GYJ9Q5W8J3.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/5GJ8GYNZJD.jpg)

Secure属性の誤解
• Secure属性の例
Set-Cookie: SESS=4F3BF15034A9B; Secure
• Secure属性を指定すると、HTTPSリクエストにのみクッキーが付与さ
れる
• よくある誤解 : TCP80ポートを閉じていれば、Secure属性は不要
• 以下のURLでTCP80ポートを閉じていても、Cookieは平文で送信され
る
http://example.jp:443/
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/MLJLG4P1ER.jpg)

HttpOnly属性の誤解
• HttpOnly属性の例
Set-Cookie: SESS=4F3BF15034A9B; HttpOnly
• HttpOnly属性を指定すると、JavaScriptからアクセスできなくなる
• よくある誤解: HttpOnlyを指定するだけでXSSの脅威を防げる
• 正解: HttpOnlyを指定すると、Cookieの盗み出しができなくなるだけ
で、秘密情報の盗み出しや不正操作はできてしまう。
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/547MQK45JW.jpg)

徳丸本2版添付の Bad Todo Listによるデモ
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/ZP7R8XWZJ9.jpg)

SameSite属性ってなに? : SameSite=none（旧来のデフォルト）
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=none（旧来のデフォルト）の場合
trap.example.com
trap.example.com
trap.example.com （罠サイト）
example.jp （攻撃対象サイト）
POST
GET
元々Cookieがセットされていた
らCookieが送信される（常に）
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/NPJX86P1EX.jpg)

SameSite属性ってなに? : SameSite=Lax
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=Lax（Google Chromeの現在のデフォルト）の場合
trap.example.com
trap.example.com
trap.example.com （罠サイト）
example.jp （攻撃対象サイト）
GETのみ
元々Cookieがセットされていた
らCookieが送信される
（GETのみ）
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/63JKK1DMJD.jpg)

SameSite属性ってなに? : SameSite=Strict
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=Strict の場合
trap.example.com
trap.example.com
trap.example.com （罠サイト）
example.jp （攻撃対象サイト）
POST
GET
元々Cookieがセットされていて
も、Cookieは一切送信されない
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4LE3ZQR2E5.jpg)

SameSiteのデフォルト変更によって…
• CookieにSameSite=Laxを指定することで、CSRF脆弱性の防御になる
• 例外は…
– IE10や、古いスマホのブラウザ（SameSite属性に対応していないもの）
– GETメソッドを受け付ける更新処理（たまによくある）では、SameSite=Laxで
は突破されてしまう→POSTに限定すること
• 古いブラウザも考慮して、当面は従来どおりトークンによる対策を推
奨
• 今後、モダンなブラウザはデフォルトがSameSite=Laxになる
（Google Chromeでは実施済み）
• POSTによるサイト遷移でCookieが必要なら、Cookieの属性として
SameSite=None; Secureを指定する必要がある
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/V8EDR9Y6JG.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4V7PWZ2ZJ8.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/L2JV8WDMJQ.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/Z5EG5DYXEL.jpg)

カード情報入力フォームを改ざんして入力中のカード情報を盗む
Copyright © 2017-2020 EG Secure Solutions Inc.
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/V4JQZ1M5JP.jpg)

カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(1)
Copyright © 2017-2020 EG Secure Solutions Inc.
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/DK743RVVE1.jpg)

カード情報入力フォームの画面遷移中に偽の入力フォームを挟む(2)
Copyright © 2017-2020 EG Secure Solutions Inc.
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/PLJ11Q34JG.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8GJW8MPZ72.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/W4EZ8QKLJ3.jpg)

「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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/KY76P6QMEV.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5G75K6RQJ4.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/V9J2WMDWER.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/5DEYLX29JM.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/2VJN418DE8.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GYE9Q5K8E3.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/5GE8GYRZED.jpg)

パスワードのハッシュ保存について
• 現在、ハッシュ値からのパスワード復元の主流の方法はGPUによる総
当り
• 並列計算が極めて容易で、コストを掛ければいくらでも高速化できる
• ソルト化ハッシュでも、総当たりスピードはそれほど変わらない
• パスワードの保存方法
– 現在のパスワード保存のベストプラクティスは、ソルト付きハッシュとスト
レッチング
– 実装には、信頼できるライブラリやフレームワークの機能利用を推奨
© 2013-2020 Hiroshi Tokumaru


# Page. 33

![Page Image](https://bcdn.docswell.com/page/MLELG4K17R.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/54JMQK25EW.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/ZPJR8XMZE9.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/NPEX86V17X.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/63EKK1QMED.jpg)

なぜ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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/4L73ZQP275.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/V87DR9L6EG.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/4VJPWZ4ZE8.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/L2EV8WXMEQ.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/Z57G5DVX7L.jpg)

XSSによりイントラの内部のサーバーを攻撃する様子
evil.example.com
evil.example.com
罠のサイト
XSSの罠
重要なお知らせ
https://internal.example.jp/?&quot;&quot;&gt;&lt;sc
ript&gt;....至急会員情報を
確認下さい
Fire Wall
https://....
internal.example.jp
攻撃対象
© 2020 Hiroshi Tokumaru
攻撃対象の
情報が
漏洩する


# Page. 43

![Page Image](https://bcdn.docswell.com/page/V4EQZ165EP.jpg)

ウェブ脆弱性のうち受動的攻撃はイントラ内の攻撃が可能
• 以下がイントラネット内サイトの攻撃に悪用可能
–
–
–
–
XSS
CSRF
DNSリバインディング
SSRF(Server Side Request Forgery) …これは能動的攻撃
• 現状ウイルス感染による攻撃（標的型攻撃、ランサムウェア）が成功
確率が高く、被害が目立つが、実はXSSによる内部サーバー侵入のト
ライは既に観測されている
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/DKJ43R4V71.jpg)

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


# Page. 45

![Page Image](https://bcdn.docswell.com/page/PLE11Q44EG.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/8GEW8MXZJ2.jpg)

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


# Page. 47

![Page Image](https://bcdn.docswell.com/page/W47Z8Q6LE3.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/KYJ6P62M7V.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/5GJ5K62QE4.jpg)

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


# Page. 50

![Page Image](https://bcdn.docswell.com/page/4LE3ZQKZE5.jpg)

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


# Page. 51

![Page Image](https://bcdn.docswell.com/page/V8EDR934JG.jpg)

件の記事と徳丸のブログ記事を比較してみる
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


# Page. 52

![Page Image](https://bcdn.docswell.com/page/4V7PWZ4VJ8.jpg)

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


# Page. 53

![Page Image](https://bcdn.docswell.com/page/L2JV8WXRJQ.jpg)

元ネタがあった
1980年代からSSRFがセキュリティ問題である、と指摘されていたと考えている理由はUNIXのリモー
トシェルの仕様と注意事項にあります。現在のUNIX系OSにはそもそもリモートシェル系のコマンド
（rコマンドと呼ばれるrshなど）はインストールされていない物が多いと思います。そこでrコマンド
とは何か、簡単に説明します。
rコマンドの代表であるrshは名前の通り、リモートからシェルコマンドを実行する仕組みです。rshな
どのrコマンドはホームディレクトリの.rhostファイルに実行を許可するホストとユーザー名を定義し
てリモートコマンド実行を許可します。
ATTACKER1とSERVER1、SERVER2があり、SERVER1が攻撃対象だとします。
ATTACKER1 -&gt; SERVER2 -&gt; SERVER1
リモートシェルの仕組みを利用するとSERVER1が信頼するSERVER2にアクセスできれば、攻撃元とな
るATTACKER1から攻撃対象となるSERVER1に攻撃可能になります。
リクエストフォージェリ – SSRFとCSRF – yohgaki&#039;s blog
https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/Z5EG5DV6EL.jpg)

件の記事と大垣さんのブログ記事を比較してみる
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


# Page. 55

![Page Image](https://bcdn.docswell.com/page/V4JQZ162JP.jpg)

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


# Page. 56

![Page Image](https://bcdn.docswell.com/page/DK743R4PE1.jpg)

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


# Page. 57

![Page Image](https://bcdn.docswell.com/page/PLJ11Q4XJG.jpg)

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


# Page. 58

![Page Image](https://bcdn.docswell.com/page/8GJW8MXK72.jpg)

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


# Page. 59

![Page Image](https://bcdn.docswell.com/page/W4EZ8Q6NJ3.jpg)

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


# Page. 60

![Page Image](https://bcdn.docswell.com/page/KY76P629EV.jpg)

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


# Page. 61

![Page Image](https://bcdn.docswell.com/page/5G75K62DJ4.jpg)

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


# Page. 62

![Page Image](https://bcdn.docswell.com/page/V9J2WM1MER.jpg)

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


# Page. 63

![Page Image](https://bcdn.docswell.com/page/5DEYLXZPJM.jpg)

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


# Page. 64

![Page Image](https://bcdn.docswell.com/page/2VJN413ME8.jpg)

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


