SlideShare a Scribd company logo
1 of 64
ウェブセキュリティのありがちな誤解を解説する
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:)を使う場合は必ず指定する
8
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/403.html (2013年7月7日のアーカイブ)
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 (現在)
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
trap.example.com
SameSite属性ってなに? : SameSite=none(旧来のデフォルト)
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=none(旧来のデフォルト)の場合
13
trap.example.com (罠サイト)
POST
GET
trap.example.com
example.jp (攻撃対象サイト)
元々Cookieがセットされていた
らCookieが送信される(常に)
trap.example.com
SameSite属性ってなに? : SameSite=Lax
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=Lax(Google Chromeの現在のデフォルト)の場合
14
trap.example.com (罠サイト)
GETのみ
trap.example.com
example.jp (攻撃対象サイト)
元々Cookieがセットされていた
らCookieが送信される
(GETのみ)
trap.example.com
SameSite属性ってなに? : SameSite=Strict
• SameSite属性は、異なるサイトから遷移した場合に、クッキーを送信
するかどうかを制御するもの
• SameSite=Strict の場合
15
trap.example.com (罠サイト)
POST
GET
trap.example.com
example.jp (攻撃対象サイト)
元々Cookieがセットされていて
も、Cookieは一切送信されない
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名の以下のクレジットカード情
報。
【流出した可能性のあるクレジットカード情報】
・クレジットカード名義人
・クレジットカード番号
・有効期限
・セキュリティコード
25
元々保存されていた
クレジットカード情報は
漏洩していない
https://www.exiletribestation.jp/news_important.html より引用
カード情報はサイトに保存した方が漏洩しにくい
• カード情報「非保持化」に伴い、攻撃手法も、入力中のデータを盗む
方法に移行している
• クレジットカード情報をサイト(多くの場合決済代行事業者)に保存
すると、カード情報を入力する場面がなくなるので、漏洩リスクも減
る
26
誤解5: ハッシュ値で保存されたパスワードは
復元されない
27
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.
25GPUのモンスターマシン(パスワード解析用!)
http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用
ベンチマーク
http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf より引用
1秒間に1800億回のMD5ハッ
シュ値計算!
↓
8文字英数字パスワード(約220
兆パターン)のMD5ハッシュ値
をすべて計算するのに、20分し
か掛からない!
SHA1でも60分
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
パスワードのハッシュ保存について
• 現在、ハッシュ値からのパスワード復元の主流の方法はGPUによる総
当り
• 並列計算が極めて容易で、コストを掛ければいくらでも高速化できる
• ソルト化ハッシュでも、総当たりスピードはそれほど変わらない
• パスワードの保存方法
– 現在のパスワード保存のベストプラクティスは、ソルト付きハッシュとスト
レッチング
– 実装には、信頼できるライブラリやフレームワークの機能利用を推奨
© 2013-2020 Hiroshi Tokumaru
誤解6: 高価なSSL証明書ほど暗号強度が高い
33
証明書の価格と暗号化強度は関係ない
34https://www.ssllabs.com/ssltest/analyze.html?d=www.tokumaru.org
Issuer Let's Encrypt Authority X3
証明書の価格と暗号化強度の関係
• 証明書の価格と暗号化強度はまったく関係ない
• 無料の証明書でも、暗号的に強固な設定は可能
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
罠サイトを閲覧してマルウェアに感染する様子
40
③マルウェア
に感染
罠サイト
①罠サイトを閲覧
②仕掛けのあるHTML
ブラウザやブラウザのプラグインに脆弱性がなければ、「怪しいサイト」を閲覧
しただけでマルウェア感染することはない。ブラウザを常に最新の状態にしま
しょう。
「怪しいサイト」を閲覧したら自動的にウイルス感染するわけてばありません。
誤解9: イントラのウェブサイトは外部からは
攻撃できない
41
Fire Wall
XSSによりイントラの内部のサーバーを攻撃する様子
© 2020 Hiroshi Tokumaru
evil.example.com
internal.example.jp
罠のサイト
攻撃対象
攻撃対象の
情報が
漏洩する
重要なお知らせ
至急会員情報を
確認下さい
https://....
XSSの罠
https://internal.example.jp/?""><sc
ript>....
evil.example.com
ウェブ脆弱性のうち受動的攻撃はイントラ内の攻撃が可能
• 以下がイントラネット内サイトの攻撃に悪用可能
– XSS
– CSRF
– DNSリバインディング
– SSRF(Server Side Request Forgery) …これは能動的攻撃
• 現状ウイルス感染による攻撃(標的型攻撃、ランサムウェア)が成功
確率が高く、被害が目立つが、実はXSSによる内部サーバー侵入のト
ライは既に観測されている
43
SSRF攻撃により内部サーバーを攻撃する様子
44https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用
攻撃者からは、公開サーバー(203.0.113.2)にはアクセスできますが、内部のサーバー
(192.168.0.5)はファイアウォールで隔離されているため外部から直接アクセスできません。し
かし、公開サーバーから内部のサーバーにはアクセスできる想定です。
攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、
内部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。
誤解10: セキュリティ情報はウェブで収集する
45
情報収集どうやっていますか?
• Googleで検索する(ググれカスとか言いますものね)
• 検索上位から見ますよね
• でも、検索上位が正しい記事なの?
• SSRF(Server Side Request Forgery)を例に確認してみます
46
最近話題の脆弱性SSRFでググってみた
47
Google検索より
検索トップの記事を読んでみよう
記事の冒頭と目次
48https://cybersecurity-jp.com/column/33568 より引用
SSRF攻撃とは通常の方法ではアクセスできないサーバーに対して攻撃を仕掛ける手法の一つです。
攻撃者はインターネット上に公開サーバーには直接アクセスできます。しかし内部サーバーへはアク
セスできません。しかし公開サーバーから内部サーバーへのアクセスはできる状態を仮定します。
この時、攻撃者は公開サーバーに対して攻撃コマンドを送信することで、公開サーバーを経由して内
部サーバーに対して攻撃をしかけることができます。この時、公開サーバーからのコマンドは正規コ
マンドとして処理されます。これがSSRF攻撃の概要です。
SSRF攻撃とは(件の記事)
49https://cybersecurity-jp.com/column/33568 より引用
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 より引用
件の記事と徳丸のブログ記事を比較してみる
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 より引用
SSRF攻撃の仕組み
52https://cybersecurity-jp.com/column/33568 より引用
元ネタがあった
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 より引用
件の記事と大垣さんのブログ記事を比較してみる
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 より引用
CSRFとSSRFの違い(?)
55https://cybersecurity-jp.com/column/33568 より引用
CSRFとSSRFの比較表
56
• SSRF サーバーが持つ権限・認証を利用して不正な命令を実行
• CSRF クライアントが持つ権限・認証を利用して不正な命令を実行
https://cybersecurity-jp.com/column/33568 より引用
https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用
SSRFの対策
ファイアウォール
ファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように
制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必
要があります。注意点として、SSRF攻撃ではない正常のアクセスについて制限してしまうと、本来の
目的が果たせなくなってしまいます。
プロキシ
ブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにお
いてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプ
ロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、
デフォルトでプロキシ経由にならないことにも気を付ける必要があります。
インターセプト
Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエ
ストの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトでき
るわけではありません。
57https://cybersecurity-jp.com/column/33568 より引用
元ネタがあった
ファイアウォール
まずはファイアウォール(FW)による対策です。FWにも種類がありますが、少なくともローカルホ
ストへのアクセス制限については、それができるホスト型のものを使用する必要があります。…
プロキシ
ブラウザにプロキシ(HTTP/Socks)を設定して全てのアクセスをプロキシに転送します。そして、プ
ロキシ側(プロキシ自体の設定、またはプロキシを置くNW/サーバの設定)でアクセスを制御する方
式です。…
プロキシ方式の問題は、そもそもの話としてブラウザが全ての通信をプロキシ経由にするわけではな
いということです。少なくともWebRTCの通信についてはプロキシ経由になりません。またループ
バックアドレス宛の通信がデフォルトではプロキシ経由にならない点に注意が必要です。
インターセプト
Puppeteerはリクエストのインターセプト機能を提供しており、これを使うとリクエストの送信先な
どを制御できます。やられサイトの最終版ではこれを使っていますが、プロキシと同様に全ての通信
がインターセプトできるわけではないという問題があります。…
58https://www.mbsd.jp/blog/20190605.html より引用
件の記事と寺田さんのブログ記事を比較してみる
ファイアウォール
ファイアウォールの設定により、攻撃者が接続先となる攻撃
対象を指定しても、接続できないように制限する方法が有効
です。少なくともローカルホストに対するアクセスについて
は厳しく制限する必要があります。
プロキシ
ブラウザにプロキシを設定して全てのアクセスをプロキシ経
由にする方法です。そしてプロキシにおいてアクセス制御を
行います。プロキシを設定する方法の注意点として、ブラウ
ザが全ての通信をプロキシ経由にするとは限らない点があげ
られます。さらにループバックアドレスへの通信については、
デフォルトでプロキシ経由にならないことにも気を付ける必
要があります。
インターセプト
Puppeteerのようにリクエストのインターセプト機能を持つ
ツールを使用している場合には、リクエストの送信先などを
制御することができます。しかしこの方法では全ての通信を
インターセプトできるわけではありません。
ファイアウォール
まずはファイアウォール(FW)による対策です。FWにも種
類がありますが、少なくともローカルホストへのアクセス制
限については、それができるホスト型のものを使用する必要
があります。
プロキシ
ブラウザにプロキシ(HTTP/Socks)を設定して全てのアクセ
スをプロキシに転送します。そして、プロキシ側(プロキシ
自体の設定、またはプロキシを置くNW/サーバの設定)でア
クセスを制御する方式です。…
プロキシ方式の問題は、そもそもの話としてブラウザが全て
の通信をプロキシ経由にするわけではないということです。
少なくともWebRTCの通信についてはプロキシ経由になりま
せん。またループバックアドレス宛の通信がデフォルトでは
プロキシ経由にならない点に注意が必要です。
インターセプト
Puppeteerはリクエストのインターセプト機能を提供してお
り、これを使うとリクエストの送信先などを制御できます。
やられサイトの最終版ではこれを使っていますが、プロキシ
と同様に全ての通信がインターセプトできるわけではないと
いう問題があります。…
59
https://cybersecurity-jp.com/column/33568 より引用 https://www.mbsd.jp/blog/20190605.html より引用
寺田さんのブログ記事はヘッドレスブラウザを使う場合のもの
60https://www.mbsd.jp/blog/20190605.html より引用
記事の構成はこう
61
徳丸浩の日記より転載・
改変
piyologより転載・改変
MBSD寺田さんの日記
より転載・改変
大垣さんのブログより
転載・改変
大垣さんのブログより
転載・改変
独自の作文?
キメラのように、既存記事を組み合わせて新しい記事をつくる
62
徳丸浩の日記
piyolog
MBSD寺田さん
のブログ記事
大垣さんの
ブログ記事
ネット上のセキュリティ記事の現状と対策
• SEO技術の発展により、量産型のセキュリティ解説記事が検索上位に
ある
– 今回はSSRFで説明したが、SQLインジェクションやクロスサイトスクリプティ
ングでも同様の傾向となる
• 資金とSEOの動機のある企業が記事を量産している
• もはや、「ググって上位の記事を参照する」方法では、質の高い記事
を見つけることはできない
• 「検索上位にあるのにブクマが全然ない」、「ブクマはあるがコメン
トのないものばかり」というのは一応の見分けにはなる
• 最終的には、良質の記事を見分ける力量を読者が身につけるしかない
• まずは徳丸本を読みましょう(宣伝)
63
Thank you!
質問、感想はDiscordでお待ちしています
64

More Related Content

What's hot

ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する増田 亨
 
最近のやられアプリを試してみた
最近のやられアプリを試してみた最近のやられアプリを試してみた
最近のやられアプリを試してみたzaki4649
 
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方kwatch
 
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのかなぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのかSen Ueno
 
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Takayuki Shimizukawa
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)NTT DATA Technology & Innovation
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方Hiroshi Tokumaru
 
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアルAzure API Management 俺的マニュアル
Azure API Management 俺的マニュアル貴志 上坂
 
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題Hiroshi Tokumaru
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティスAmazon Web Services Japan
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきことこれからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと土岐 孝平
 
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかSQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかShogo Wakayama
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011Hiroshi Tokumaru
 

What's hot (20)

ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
 
最近のやられアプリを試してみた
最近のやられアプリを試してみた最近のやられアプリを試してみた
最近のやられアプリを試してみた
 
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
なぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのかなぜ自社で脆弱性診断を行うべきなのか
なぜ自社で脆弱性診断を行うべきなのか
 
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
 
Mavenの真実とウソ
Mavenの真実とウソMavenの真実とウソ
Mavenの真実とウソ
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
 
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアルAzure API Management 俺的マニュアル
Azure API Management 俺的マニュアル
 
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
 
Proxy War
Proxy WarProxy War
Proxy War
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
これからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきことこれからSpringを使う開発者が知っておくべきこと
これからSpringを使う開発者が知っておくべきこと
 
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかSQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
 
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
 

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

オンラインバンキングのセキュリティ技術の動向(完全版)
オンラインバンキングのセキュリティ技術の動向(完全版)オンラインバンキングのセキュリティ技術の動向(完全版)
オンラインバンキングのセキュリティ技術の動向(完全版)Fusion Reactor LLC
 
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)Shinobu Yasuda
 
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりHiroshi Tokumaru
 
Infomation Card と Windows CardSpace のご紹介
Infomation Card と Windows CardSpace のご紹介Infomation Card と Windows CardSpace のご紹介
Infomation Card と Windows CardSpace のご紹介shigeya
 
情報セキュリティexpo(2015) テコラスブースセッション eco_pro
情報セキュリティexpo(2015) テコラスブースセッション eco_pro情報セキュリティexpo(2015) テコラスブースセッション eco_pro
情報セキュリティexpo(2015) テコラスブースセッション eco_proNHN テコラス株式会社
 
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜Riotaro OKADA
 
クラウド事業者のためのクラウドセキュリティ(公開用)
クラウド事業者のためのクラウドセキュリティ(公開用)クラウド事業者のためのクラウドセキュリティ(公開用)
クラウド事業者のためのクラウドセキュリティ(公開用)Lumin Hacker
 
インターネット利用における悪意ある行為と対策
インターネット利用における悪意ある行為と対策インターネット利用における悪意ある行為と対策
インターネット利用における悪意ある行為と対策Yoshiki Sato
 
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題Masahiro Morozumi
 
情報セキュリティ/ どのリスク対策に費用をかけるべきか?
情報セキュリティ/ どのリスク対策に費用をかけるべきか?情報セキュリティ/ どのリスク対策に費用をかけるべきか?
情報セキュリティ/ どのリスク対策に費用をかけるべきか?masaaki murakami
 
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策 「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策 NHN テコラス株式会社
 
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)Kengo Suzuki
 
KYC and identity on blockchain
KYC and identity on blockchainKYC and identity on blockchain
KYC and identity on blockchainmosa siru
 
クラウドインフラに求められるセキュリティ
クラウドインフラに求められるセキュリティクラウドインフラに求められるセキュリティ
クラウドインフラに求められるセキュリティMiho Yamamoto
 
Blockchain Market Trend (June 2018)
Blockchain Market Trend (June 2018)Blockchain Market Trend (June 2018)
Blockchain Market Trend (June 2018)Motoi Oyane
 

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

オンラインバンキングのセキュリティ技術の動向(完全版)
オンラインバンキングのセキュリティ技術の動向(完全版)オンラインバンキングのセキュリティ技術の動向(完全版)
オンラインバンキングのセキュリティ技術の動向(完全版)
 
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
”もと”中の人が語り尽くすSoftLayerセキュリティー(2016/10/13更新版)
 
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
 
Infomation Card と Windows CardSpace のご紹介
Infomation Card と Windows CardSpace のご紹介Infomation Card と Windows CardSpace のご紹介
Infomation Card と Windows CardSpace のご紹介
 
情報セキュリティexpo(2015) テコラスブースセッション eco_pro
情報セキュリティexpo(2015) テコラスブースセッション eco_pro情報セキュリティexpo(2015) テコラスブースセッション eco_pro
情報セキュリティexpo(2015) テコラスブースセッション eco_pro
 
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜
今から取り組む企業のための脆弱性対応 〜⼤丈夫、みんなよく分かっていないから〜
 
クラウド事業者のためのクラウドセキュリティ(公開用)
クラウド事業者のためのクラウドセキュリティ(公開用)クラウド事業者のためのクラウドセキュリティ(公開用)
クラウド事業者のためのクラウドセキュリティ(公開用)
 
インターネット利用における悪意ある行為と対策
インターネット利用における悪意ある行為と対策インターネット利用における悪意ある行為と対策
インターネット利用における悪意ある行為と対策
 
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題
クラウドにおける責任共有モデルと クラウド利用者のセキュリティの課題
 
情報セキュリティ/ どのリスク対策に費用をかけるべきか?
情報セキュリティ/ どのリスク対策に費用をかけるべきか?情報セキュリティ/ どのリスク対策に費用をかけるべきか?
情報セキュリティ/ どのリスク対策に費用をかけるべきか?
 
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策 「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策
「情報セキュリティ10大脅威2017」 から読み取る最新セキュリティ傾向とその対策
 
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
 
KYC and identity on blockchain
KYC and identity on blockchainKYC and identity on blockchain
KYC and identity on blockchain
 
クラウドインフラに求められるセキュリティ
クラウドインフラに求められるセキュリティクラウドインフラに求められるセキュリティ
クラウドインフラに求められるセキュリティ
 
Blockchain Market Trend (June 2018)
Blockchain Market Trend (June 2018)Blockchain Market Trend (June 2018)
Blockchain Market Trend (June 2018)
 
TGM_salessheet
TGM_salessheetTGM_salessheet
TGM_salessheet
 

More from Hiroshi Tokumaru

脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証するHiroshi Tokumaru
 
SQLインジェクション再考
SQLインジェクション再考SQLインジェクション再考
SQLインジェクション再考Hiroshi Tokumaru
 
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入するHiroshi Tokumaru
 
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1introduction to unsafe deserialization part1
introduction to unsafe deserialization part1Hiroshi Tokumaru
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門Hiroshi Tokumaru
 
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)Hiroshi Tokumaru
 
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Hiroshi Tokumaru
 
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018Hiroshi Tokumaru
 
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようデバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようHiroshi Tokumaru
 
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座Hiroshi Tokumaru
 
ウェブセキュリティの常識
ウェブセキュリティの常識ウェブセキュリティの常識
ウェブセキュリティの常識Hiroshi Tokumaru
 
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則Hiroshi Tokumaru
 
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門Hiroshi Tokumaru
 
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くセキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くHiroshi Tokumaru
 
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016Hiroshi Tokumaru
 
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうCMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうHiroshi Tokumaru
 
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかにHiroshi Tokumaru
 
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったかHiroshi Tokumaru
 
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みセキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みHiroshi Tokumaru
 

More from Hiroshi Tokumaru (20)

脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
 
SQLインジェクション再考
SQLインジェクション再考SQLインジェクション再考
SQLインジェクション再考
 
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
 
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
 
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
 
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
 
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
 
秀スクリプトの話
秀スクリプトの話秀スクリプトの話
秀スクリプトの話
 
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようデバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
 
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
 
ウェブセキュリティの常識
ウェブセキュリティの常識ウェブセキュリティの常識
ウェブセキュリティの常識
 
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
 
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
 
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くセキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
 
安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016安全なPHPアプリケーションの作り方2016
安全なPHPアプリケーションの作り方2016
 
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうCMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
 
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
 
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
 
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みセキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
 

Recently uploaded

知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptxsn679259
 
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイルLoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイルCRI Japan, Inc.
 
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用KLab Inc. / Tech
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsWSO2
 
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアルLoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアルCRI Japan, Inc.
 
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介Hyperleger Tokyo Meetup
 
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdfネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdfTakayuki Nakayama
 

Recently uploaded (7)

知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
 
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイルLoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
LoRaWAN無位置ロープ型水漏れセンサー WL03A-LB/LSカタログ ファイル
 
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
2024年5月17日 先駆的科学計算フォーラム2024 機械学習を用いた新たなゲーム体験の創出の応用
 
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native IntegrationsUtilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
 
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアルLoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
LoRaWAN無位置ロープ式水漏れセンサーWL03A 日本語マニュアル
 
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
Hyperledger Fabricコミュニティ活動体験& Hyperledger Fabric最新状況ご紹介
 
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdfネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
ネットワーク可視化 振る舞い検知(NDR)ご紹介_キンドリル202405.pdf
 

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