Slide 1
Slide 1 text
Security
Training for new graduates in 2023
パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部
※本資料は2023年3月時点の情報であり、2023年新卒の研修教材です。
Slide 2
Slide 2 text
準備
ワークでHTTP通信をインターセプトするツールが必要になります。
本研修では、Burp Suite(Community Edition)を利用します。
下記リンクからインストールしてください。
PortSwigger. Professional / Community 2023.2.3.
https://portswigger.net/burp/releases/professional-community-2023-2-3?requestededition=community
ご自身のMacOSを確認してインストー
ルしてください。
左上の🍎アイコンから「このMacにつ
いて」をクリックして、プロセッサを
確認。
Slide 3
Slide 3 text
準備
PortSwigger社のWebSecurityAcademyを利用します。
下記リンクからアカウントを作成してください。
PortSwigger. Create your account. https://portswigger.net/users/register
Slide 4
Slide 4 text
研修のゴール
広義には、セキュリティとはアプリケーション、ネットワーク、クライアント等様々なレイ
ヤーで対策すべき内容ですが、本研修では主にWebアプリケーション開発において必要とさ
れる、セキュリティ知識、技術を学習することを目的とします。
Slide 5
Slide 5 text
免責
本研修で学習する攻撃手法の悪用は禁止です。
悪用、興味本位等で他社のWebサービスに攻撃を仕掛けた場合に発生する損害、責任は一切
負いません。
Slide 6
Slide 6 text
目次
● Mindset
● Web basics
○ Same-origin policy
○ Cross-origin resource sharing(CORS)
○ Cookie & Session
● Web vulnerabilities
○ Cross-site request forgeries(CSRF)
○ Cross-site scripting(XSS)
○ SQL injection
○ OS command injection
○ Directory traversal
● Conclusion
6
Slide 7
Slide 7 text
Mindset
Slide 8
Slide 8 text
脆弱性
アプリケーション等の不具合等や設計ミスが原因となって発生した情報セキュリティ上の欠
陥のことを言います。
総務省. 「脆弱性（ぜいじゃくせい）とは？」.
https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/risk/11.html#:~:text=脆弱性（ぜいじゃくせい）とは、
コンピュータのOS,ホールとも呼ばれます。
Slide 9
Slide 9 text
脆弱性対策は義務
日本であれば、個人情報の保護に関する法律の第23条で定められています（2022/04/06時
点）
e-Gov. 「個人情報の保護に関する法律」. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
各国で定められた法基準に合わせて適切な措置を取る必要があります。
（EU圏内であればGDPR、カリフォルニア州であればCCPA等）
Slide 10
Slide 10 text
脆弱性があると何が起きるのか
● 個人情報等の秘密情報を勝手に閲覧されてしまう
● Webサイトの内容が書き換えられてしまう
● 別の利用者になりすまし、投稿、買い物、送金されてしまう
● Webサイトが利用不可な状態になってしまう
等々、例を挙げたらキリがないです。
Slide 11
Slide 11 text
脆弱性が突かれた結果…
● 利用者が受けた経済的損失の補填
● 取引先企業等への賠償責任
● Webサイトの停止による機会損失
● 社会的信用の失墜による会社全体の売上の低下
データ漏えい等が発生した場合は最悪で、一度漏洩してしまったデータは回収することがで
きません。
Slide 12
Slide 12 text
インシデントが起こったとしても事業は継続できます。損害金額も大きくはないかもしれ
ません。
しかし、一度失った社会的信用を取り戻すにはとても時間がかかります。
最悪の場合、信頼が戻らず、サービス停止や事業継続が難しくなる場合もあります。
我々は常に多くの個人情報を扱う立場であるため、これらの事例を教訓としセキュリティ
を学習するモチベーションとしてください。
ここまでのまとめ
Slide 13
Slide 13 text
Web basics
Slide 14
Slide 14 text
Same-origin
policy
Slide 15
Slide 15 text
Same-origin policy
15
同一生成元ポリシー。
そのオリジンのリソースに干渉する事ができるのは、同じオリジンのみとするウェブブラウザに搭載さ
れた機能です。
つまり、異なるオリジン（クロスオリジン）からのリソースへの干渉は制限されます。
http://example1.com
http://example2.com
http://example1.com
/api/users
/api/users
Slide 16
Slide 16 text
オリジン
16
オリジンとは URL のスキーム (プロトコル)、 ホスト (ドメイン)、 ポート で定義されま
す。
つまり、スキーム、ホスト、ポートがすべて一致すると同一オリジンと言えます。
Slide 17
Slide 17 text
URIの仕様
17
http://example.com:80/blog?date=20220407&q=hoge#huga
● URIスキーム: http
● ホスト名: example.com
● ポート番号: 80
● パス: /blog
● クエリパラメータ: date=20220407&q=hoge
● URIフラグメント: #huga
Slide 18
Slide 18 text
同一オリジンの例
18
// httpの既定ポートの80番が指定されているので、同一オリジンである
http://example.com
http://example.com:80
// スキーム、ホストが同一なので同一オリジンである
http://example.com/app1/index.html
http://example.com/app2/index.html
Slide 19
Slide 19 text
同一オリジンではない例
19
// ポートが異なるので同一オリジンではない
http://example.com
http://example.com:3000
// スキームが異なるので同一オリジンではない
http://example.com
https://example.com
// サブドメインではあるが、ホストが異なるので同一オリジンではない
http://example.com
http://www.example.com
http://myapp.example.com
Slide 20
Slide 20 text
Cross-origin
resource
sharing(CORS)
Slide 21
Slide 21 text
Cross-origin resource sharing
21
オリジン間リソース共有。
一般的には頭文字を取ったCORS（コーズ、コルス、シーオーアールエス）と呼ばれます。
あるオリジンで動作しているウェブアプリケーションに、異なるオリジンのリソースへアクセスできる
ようにブラウザに許可を与える仕組みです。
http://example1.com
http://example2.com
http://example1.com
/api/users
/api/users
Slide 22
Slide 22 text
Access-Control-Allow-Origin
22
クロスオリジンからのリソースへのアクセスを許可する場合に、HTTPレスポンスヘッダに付与します。
サーバー側で対応するものです。
// 前のページの例であれば、以下のようなレスポンスヘッダーが生成されます
Access-Control-Allow-Origin: http://example2.com
// ワイルドカードを指定すると、全てのクロスオリジンからのアクセスを許可する（非推奨）
Access-Control-Allow-Origin: *
Slide 23
Slide 23 text
Access-Control-Allow-Origin
23
ちなみに、
公開APIはフロントエンドから直接アクセスされる事は想定していないため、
Access-Control-Allow-Originは設定していない。
（APIKeyなどがリクエストに必要になるケースがあるため、フロントエンドから直接リクエストを送っ
てしまうとAPIKeyが外部に流出することになる）
CORSに関してはあくまでブラウザの話になるので、Curlやサーバー内部でリクエストする際は関係な
い。（普通外部のAPI使う時はサーバー側のAPIでラップして使うことがほとんどのはず）
Slide 24
Slide 24 text
Preflight Request
24
シンプルなリクエストに該当しない場合、リクエストの送信前にプリフライトリクエストが送信され、
安全性の確認が行われます。
モダンブラウザであれば、通常はブラウザから自動的に送信されるので、特に意識する必要はありませ
ん。
Mozilla. オリジン間リソース共有 (CORS). https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#単純リクエスト
Slide 25
Slide 25 text
イメージ
25
url: /api/user
method: OPTIONS
Client Server
プリフライトリクエスト
Mozilla.「Preflight request (プリフライトリクエスト)」. https://developer.mozilla.org/ja/docs/Glossary/Preflight_request
メインリクエスト
url: /api/user
method: POST
Slide 26
Slide 26 text
Cookie & Session
Slide 27
Slide 27 text
HTTPのステートレス性
HTTPは状態を持たないプロトコルとして設計されています。それぞれのリクエストは独立したものとし
て扱われます。
そのため、毎回リクエストに全ての情報を送信しなければいけません。
27
Aです。ハンバーガーの配達をお願いします。
かしこまりました。住所はどちらでしょうか？
東京都千代田区千代田1-1です。
かしこまりました。お届けします。
ステートフルな会話
Aです。ハンバーガーの配達をお願いします。
かしこまりました。住所はどちらでしょうか？
東京都千代田区千代田1-1です。
あなたは誰ですか？何を注文されますか？
ステートレスな会話
この会話成立させるには
「Aです。東京都千代田区千代
田1-1にハンバーガーの配達をお
願いします」
とリクエストする必要がある。
Slide 28
Slide 28 text
ステートレスによる課題
ステートフルなプロトコルと比べてスケーラビリティの高いプロトコルなので、Webアプリケーションへ
の適正は高いですが、状態を保持できないと不都合があります。
例えば、Amazon等のECサイトでは
1. 商品を検索する
2. 商品を買い物カゴへ入れる
3. 買い物カゴに入っている商品を購入する
という操作を行いますが、これらのリクエストは独立しています。
買い物カゴに入れても、購入リクエストを送信する時には買い物カゴは空なので購入できません。
28
Slide 29
Slide 29 text
Cookie
サーバとブラウザ間で状態を保存するための仕組みです。
一般的には、ログイン等のタイミングでサーバ側が生成したセッション情報をレスポンスに付与しま
す。それをクライアントのブラウザに保存することで、そのリクエストがどのクライアントから送られ
てきたのか管理します。
ログアウト等が実行されるまでの間は、それ以降のリクエストにCookieが付与されます。
29
Slide 30
Slide 30 text
イメージ
30
url: /api/user
method: GET
Client Server
Set-Cookie: SESSIONID=12345678
url: /api/hamburgers
method: GET
cookie: SESSIONID=12345678
Slide 31
Slide 31 text
Cookieの脆弱性
前述した通り、ブラウザに保存されたCookieをもとにユーザーを特定しているので、何らかの方法で
Cookieを抜き取ることで、そのユーザーになりすませる、と言えます。（これを悪用したものがセッ
ションハイジャックと言われる攻撃手法）
このような理由からCookieを悪用しようとする攻撃手法がいくつも存在します。間違っても平文でCookie
に秘匿情報を保存しないように注意してください。（推測可能なものもNG）
これらの脅威から守るためにCookieの正しい利用方法を紹介します。
31
Slide 32
Slide 32 text
Domain属性
理由がなければ設定しない。
● Cookie を受信することができるドメインを指定する属性
● 未設定の場合は、Cookieを生成したサーバーにのみ送信されるので、セキュリティ上ではこれが最
も安全
● 複数のドメインに対して有効なCookieを生成したい場合等が利用シーンにあげられる
○ ただし、Windows7、Windows8.1のIEについてはeTLDに該当する一部のドメインが設定できて
しまうクッキモンスターバグがある。（PSLを各ベンダ毎に管理していたのが根本原因）例え
ばexample.tokyo.jpに対して指定する場合は、example.tokyo.jpですが、tokyo.jpのクッキーが
作れてしまう問題。モダンブラウザでは対策されていますが、セッション固定化攻撃のリス
クが増加するため注意が必要です。
Jxck. 「Public Suffix List の用途と今起こっている問題について」.
https://blog.jxck.io/entries/2021-04-21/public-suffix-list.html
32
Slide 33
Slide 33 text
Secure属性
理由がなければ有効に設定する。
● Cookieの送信をHTTPSに限定する
○ CookieはHTTP、HTTPS問わず、送信されてしまう
○ HTTPの通信を盗聴されてCookieを盗み出される可能性がある
33
Slide 34
Slide 34 text
HttpOnly属性
理由がなければ有効に設定する
● JavaScriptからのCookieの参照を禁止する
○ 後述するXSS脆弱性に有効
34
Slide 35
Slide 35 text
SameSite属性
利用シーンに応じた適切な設定をする
● 設定値は、None（なし）、Lax（緩い）、Strict（厳しい）の3種類
○ 未設定の場合は、Laxが設定される（一部のモダンブラウザ, safari,firefoxはNoneっぽい）
■ 徳丸浩の日記. 「2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか」.
https://blog.tokumaru.org/2022/01/
○ Noneを設定する場合は、Secure属性の有効化が必須（一部のモダンブラウザ）
○ 後述するCSRF脆弱性に有効
35
Mozilla. Set-Cookie. https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie
Google. 「新しい SameSite=None; Secure Cookie 設定への対応準備」.
https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja
e-Words. SameSite属性 【SameSite Cookie】. https://e-words.jp/w/SameSite%E5%B1%9E%E6%80%A7.html
Slide 36
Slide 36 text
Cookieに関する規制
近年では個人情報保護の観点からCookieの利用を規制する動きがあります。
EUで施行されたGDPRを始め、日本でも2022年4月からCookieは個人関連情報（閲覧履歴、位置情報等も
該当する）にあたるとされ、第三者に提供する場合に本人の同意が必要になります。（取得側で個人
データとして取得する場合）
36
e-Gov. 個人情報の保護に関する法律. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
Slide 37
Slide 37 text
Cookieの何が問題か
Cookieは個人の行動履歴を特定する目的でも利用されます。（トラッキング）
例えば、ECサイトで閲覧していた商品が別のサイトの広告欄で表示される経験ありませんか？
これはあるWebサイトを閲覧した際に、そのサイトに設置された広告経由等で送られたCookieにより、実
現されている仕組みです。
一般的にそのサイトで必要な情報を保存するために用いられるCookieをファーストパーティCookieと言
い、広告等複数のサイトを横断して行動履歴をトラッキングする等の目的で利用されるCookieをサード
パーティCookieと言います。
前述した個人情報保護法改正による規制はサードパーティCookieが対象となります。
37
Slide 38
Slide 38 text
リタゲ広告のイメージ
38
https://ecA.com
https://ecB.com
ecA.comを
閲覧した
ecB.comを
閲覧した
1. ecA.comにアクセス
https://ad.com
2. ecA.comに設置されたad.com
の広告からリクエスト
3. ad.comからサードパーティ
クッキーが生成される
5. ecB.comに設置されたad.com
の広告からリクエスト
6. このクッキーを所有する
ユーザーはecA.com,ecB.comの
サイトを閲覧したという履歴が
広告サイトに蓄積される
4. ecB.comにアクセス
Slide 39
Slide 39 text
JSON Web Token
Cookieはステートフルなセッション管理方法ですが、一方最近ではステートレスなセッション管理方法として略してJWT
（ジョット）が利用されるケースも見られます。（サビ開はほとんどこれ）
複数のマイクロサービスで構成されるサービスが増え、認証情報の持ち運びができることから人気が高まっています。
Sessionと異なり、保存場所の選択肢にはインメモリ、WebStorage等も含まれます。
保存場所が変わっても基本的なアプローチはCookieと同様の考え方である点に注意してください。（見られて困る情報は
保存しない、JWTであれば署名を付ける）
Slide 40
Slide 40 text
Web vulnerabilities
Slide 41
Slide 41 text
Cross-site
request
forgeries(CSRF)
Slide 42
Slide 42 text
CSRF
ブラウザからクライアントが意図しないリクエストをサーバに送信させる攻撃手法。
サーバー側でリクエストを十分に検証せず処理するように設計されている場合、正規のリクエストとし
て扱われ、被害が発生する。
Slide 43
Slide 43 text
イメージ
正規サイトA
5. 正規サイトからのリクエストなので
正規リクエストとして
処理される
2. 悪意のあるユーザーが作成したサイトに
正規サイトAに対する
リクエストが埋め込まれている
偽サイトA’
4. ユーザーは気づかず
リクエストが送信される
6. ユーザーが意図しない結果が
反映される
1. 正規サイトAに
ログイン済
3. ユーザーが
偽サイトA’にアクセス
Slide 44
Slide 44 text
CSRF脆弱性の事例
● パソコン遠隔操作事件
Wikipedia. 「パソコン遠隔操作事件」. https://ja.wikipedia.org/wiki/パソコン遠隔操作事件#犯行の手口
その他にもパスワード変更、送金、商品の購入等を目的として仕掛けられることもあります。
44
Slide 45
Slide 45 text
CSRF脆弱性を探してみよう🔍
CSRF 攻撃を使用してユーザーの電子メールアドレスを変更する HTML を作成し、それをエクスプロイト
サーバーにアップロードしてください。
PortSwigger. Lab: CSRF vulnerability with no defenses. https://portswigger.net/web-security/csrf/lab-no-defenses
※注意: Solution, Community solutionsは開かないようにしてください。
💡ヒント
● まずはメールアドレス変更のリクエストを探してみましょう。
● 攻撃サイトでユーザーは操作を行いません。ユーザーがアクセスした瞬間にリクエストが送信され
るようにしてください。
● スクリプトが完成したら「Deliver exploit to victim」をクリックするのを忘れずに・
45
分かりにくいですが、画面上部のGo to exploit serverからHTMLが
作成できます。
Slide 46
Slide 46 text
解説
46
PortSwigger. Lab: CSRF vulnerability with no defenses.
https://portswigger.net/web-security/csrf/lab-no-defenses
Slide 47
Slide 47 text
CSRF脆弱性への対策
根本的な対策は、正規のリクエストであるかサーバー側で確認する。
● トークンの埋め込み
● 本人確認をする
● Refererのチェック
● CookieのSameSite属性の設定
Slide 48
Slide 48 text
トークンの埋め込み
第3者が知り得ない秘密情報（＝トークン）をリクエストに要求することで正規のリクエストであるか判
別します。
フレームワークを利用した開発を行う場合は、トークン生成、チェック機能が提供されていることが多
いので、比較的容易に実装可能です。CSRF脆弱性における汎用的な対策にあたるため推奨される方法で
すが、XSS脆弱性のあるサイトの場合はこの対策だけでは不十分となる点に注意してください。
Youtube. 徳丸浩のウェブセキュリティ講座. 「XSS脆弱性があるとCSRF対策は突破できる」.
https://www.youtube.com/watch?v=t23FHC5hRDk
Slide 49
Slide 49 text
本人確認をする
例えば、購入ページであれば購入の確定前にパスワードを再入力するページを挟む等の方法を指しま
す。
Githubでもセキュリティ侵害が発生しうる重要な操作を行う箇所でこのような操作が求められるケースが
あります。（sudoモード）
ただし、重要なページに絞らないと煩雑な操作になってしまうことや、パスワード入力を求めるタイミ
ングを誤ると脆弱性が混入することになるので注意が必要です。
GitHub. GitHub Docs. Sudo モード.
https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/sudo-mode
Slide 50
Slide 50 text
Refererのチェック
手段としては考えられますが、推奨できない方法です。
● Refererの送信有無がクライアントの設定次第になる
● 操作方法によってRefererが付かない（URLに直アクセス、新しいタブで開く等）
● チェック漏れが起きやすい
※ 余談
正しくはReferrerですが、スペルミスでRefererとなっているようです。
Wikipedia. HTTPリファラ. https://ja.wikipedia.org/wiki/HTTP%E3%83%AA%E3%83%95%E3%82%A1%E3%83%A9#%E7%B6%B4%E3%82%8A
Slide 51
Slide 51 text
CookieのSameSite属性の設定
Same Site=Lax 、もしくは Same Site=Strict の設定をすることで、クロスオリジンからのPOST等の危
険なメソッドの実行時にCookieの送信がされません。
送金や商品の購入のようなケースは防げますが、先程紹介した認証しなくても処理を実行できてしまう
ケースは防ぐことはできないので、あくまで緩和策と捉えてください。
Slide 52
Slide 52 text
Cross-site
scripting(XSS)
Slide 53
Slide 53 text
XSS
攻撃者が攻撃対象となるWebサイトに、何らかの方法で混入させた任意のJavaScriptコードをクライアン
トのブラウザ上で実行させる攻撃手法。Webアプリケーションにおける被害の中で最も多いのが、この脆
弱性です。（IPA2021年第4四半期調べ）
IPA. ソフトウェア等の脆弱性関連情報に関する届出状況. https://www.ipa.go.jp/files/000095630.pdf
この脆弱性が混入すると様々な被害が発生します。
● 被害者となるユーザーになりすます
● 被害者となるユーザーが実行できる操作、アクセスできる情報の読み取り
● Webサイトの改ざん
53
Slide 54
Slide 54 text
Reflected XSS
脆弱性のあるWebサイトのリンクに悪意のあるスクリプトを含ませて、偽メールや偽サイトに設置しま
す。その後、ユーザーがそのリンク先へアクセスすることで悪意のあるスクリプトをクライアント上で
実行させる攻撃手法です。
典型的な例は検索画面等が挙げられます。
リクエストしたクライアントへスクリプトが返ってくることから「Reflected XSS」と呼ばれています。
54
Slide 55
Slide 55 text
Reflected XSSのイメージ
55
攻撃対象のサイト
1. 悪意のあるユーザーが作成した罠サイトに
正規サイトAへのリンクが埋め込まれてい
る。（パラメータに攻撃用のスクリプトが含
まれている）
罠サイト
3. 罠サイト経由でアクセス
4. ユーザーのブラウザ上で悪意の
あるスクリプトが実行される
2. ユーザーが
罠サイトで罠を閲覧
Slide 56
Slide 56 text
Stored XSS
事前に攻撃者は悪意のあるスプリクトをWebサイトのデータベース等に保存させます。
その後、ユーザーが閲覧する度、保存されている悪意のあるスクリプトが実行されます。Reflected XSS
と比較して、誘導する手間がかからないため攻撃難易度は低いと言えます。
典型的な例では、掲示板やブログのコメント機能等が挙げられます。
56
Slide 57
Slide 57 text
Stored XSSのイメージ
57
攻撃対象のサイト
1. 悪意のあるユーザーが事前に攻撃対象
サイトのDB等にスクリプトを登録する。
2. ユーザーがアクセス
3. ユーザーのブラウザ上で悪意の
あるスクリプトが実行される
Slide 58
Slide 58 text
DOM-based XSS
サーバ側ではなく、フロントエンド側のコード脆弱性を悪用した攻撃です。
利用方法について注意を払うべく代表的な機能には
● document.write
● innerHTML/outerHTML
● location.href
● eval
等が挙げられます。
58
Slide 59
Slide 59 text
XSSを探してみよう🔍①
ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()を実行してください。
PortSwigger. Lab: Reflected XSS into HTML context with nothing encoded.
https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded
💡ヒント
● Reflected-XSS
59
Slide 60
Slide 60 text
解説
60
URLクエリに含まれる文字列をそのまま出力してしまっている。
PortSwigger. Lab: Reflected XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded
Slide 61
Slide 61 text
XSSを探してみよう🔍②
ブログのコメント機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()`
を実行してください。
PortSwigger. Lab: Stored XSS into HTML context with nothing encoded.
https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded
💡ヒント
● Stored-XSS
61
Slide 62
Slide 62 text
解説
62
以前登録したデータがエスケープされずに保存されてしまった
ため、データ取得時にスクリプトが実行されてしまっている。
PortSwigger. Lab: Stored XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded
Slide 63
Slide 63 text
XSSを探してみよう🔍③
ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()`
を実行してください。
PortSwigger. Lab: DOM XSS in document.write sink using source location.search.
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink
💡ヒント
● DOM-Based XSS
63
Slide 64
Slide 64 text
解説
64
document.writeで書き込んでいるため、HTMLのリテラルが
破壊された。
PortSwigger. Lab: DOM XSS in document.write sink using source location.search. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink
Slide 65
Slide 65 text
XSSを探してみよう🔍④
ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()`
を実行してください。
PortSwigger. Lab: DOM XSS in innerHTML sink using source location.search.
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink
💡ヒント
● scriptタグ以外の方法でJavaScriptを実行する方法を考えてみてください。
● DOM-Based XSS
● ロード時にアラートが出ないとダメかも？
65
Slide 66
Slide 66 text
解説
66
W3C. Scripting. https://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html#the-script-element
innerHTMLだとScriptタグの内容は実行されないので、imgタグ等にあるイベントハンドラを利用する。
エスケープされていないため、URLクエリに書かれた内容がそのままHTMLタグとして解釈されてしまった。
PortSwigger. Lab: DOM XSS in innerHTML sink using source location.search.
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-inn
erhtml-sink
Slide 67
Slide 67 text
XSSを探してみよう🔍⑤
フィードバック送信ページにXSS脆弱性が含まれています。「Back」をクリックした時にクライアントに
保存されているCookieをalertしてください。
PortSwigger. Lab: DOM XSS in jQuery anchor href attribute sink using location.search source.
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-jquery-href-attribute-sink
💡ヒント
● Anchorタグからjavascriptを発火させるにはどのようにしたら良いでしょうか。
● Reflected-XSS
67
Slide 68
Slide 68 text
解説
68
JavaScriptスキームの仕組みを使った攻撃です。
エスケープ無しでURLクエリの内容を画面要素に反映させてしまっている。
Slide 69
Slide 69 text
XSSを探してみよう🔍⑥
ブログの検索機能にXSS脆弱性が隠されています。検索ワード入力ボックスにマウスオーバーしたら
alert()を実行するようにしてください。
PortSwigger. Lab: Reflected XSS into attribute with angle brackets HTML-encoded.
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-attribute-angle-brackets-html-encoded
💡ヒント
● ここまで進んだ人達であれば自力で解けるはず。。。！
69
Slide 70
Slide 70 text
解説
70
PortSwigger. Lab: Reflected XSS into attribute with angle brackets HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-attribute-angle-brackets-html-encoded
Slide 71
Slide 71 text
XSSを探してみよう🔍⑦
ブログのコメント機能にXSS脆弱性があります。コメント作成者名がクリックされた時にalert()が実行さ
れるようにしてください。（コメントの「Website」を入力しないと作成者名がリンクにならないので注
意！）
PortSwigger. Lab: Stored XSS into anchor href attribute with double quotes HTML-encoded.
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-href-attribute-double-quotes-html-encoded
💡ヒント
● ここまで進んだ人達であれば自力で解けるはず。。。！
71
Slide 72
Slide 72 text
解説
72
PortSwigger. Lab: Stored XSS into anchor href attribute with double quotes HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-href-attribute-double-quotes-html-encoded
Slide 73
Slide 73 text
XSSを探してみよう🔍⑧
ブログの検索機能にXSS脆弱性が隠されています。検索を実行した時にalert()が実行されるようにしてく
ださい。
PortSwigger. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded.
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-javascript-string-angle-brackets-html-encoded
💡ヒント
● JavaScriptのコードリテラルを破壊してください。
73
Slide 74
Slide 74 text
解説
74
サーバでHTMLを生成する際にURLクエリの内容をエスケープせず、HTMLに書き出してしまっている。
PortSwigger. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded.
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-javascript-string-angle-brackets-html-encoded
Slide 75
Slide 75 text
XSSの必須対策
一般的には以下のような対策が取られます。
● リテラルを破壊するメタ文字のエスケープ
HTMLであれば「<」「>」「”」「&」等。Scriptであれば「\」「’」「”」等。
● HTTPレスポンスに文字エンコーディングのセット
75
Slide 76
Slide 76 text
XSSの緩和対策
また、その他に緩和策として以下の方法が取られます。
● ユーザーからの入力値の検証
● Content-security Policyの設定 ※1
● X-XSS-Protectionの設定(レガシーブラウザのサポートが必要な場合のみ)
● CookieのHttpOnly属性の有効化（セッションハイジャックのみ）
※1 Mozilla. コンテンツセキュリティポリシー (CSP). https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
76
Slide 77
Slide 77 text
SQL injection
Slide 78
Slide 78 text
SQL injection
外部から受け取ったパラメータでSQLを実行する場合に、意図しないクエリが発行され、データベースが
不正に操作される脆弱性。
データベースの内容を直接閲覧、改ざんされる等、非常に影響が大きい脆弱性のため絶対に混入させて
はいけないです。
Slide 79
Slide 79 text
イメージ
メールアドレス、パスワードが一致したらログインできる。
内部的には以下のようなクエリが発行される。
SELECT * FROM users
WHERE email = ‘[email protected]’ and password = ‘password’;
// OR 1 = 1で必ずtrueが返る
SELECT * FROM users
WHERE email = '[email protected]' OR 1 = 1 --' and password = '';
メールアドレスに[email protected]’ OR 1 = 1 –-と入力することで
パスワードの認証を突破できてしまう。
Slide 80
Slide 80 text
SQL injectionの原因
パラメータ化された部分を実際の値に展開する時、リテラルとして文法的に正しく文を生成していない
ためです。
SQL文として意味のある文字列が適切にエスケープされていないために、パラメータに与えられた値がリ
テラルの外にはみ出した状態になり、リテラルの後ろに続く文として解釈され、SQLインジェクションが
発生します。
// シングルクォートが適切にエスケープされていれば、SQLインジェクションは発生しなかった
SELECT * FROM users WHERE email = '[email protected]\' OR 1 = 1 --' and password = 'password';
Slide 81
Slide 81 text
SQL injectionを探してみよう①🔍
商品カテゴリの検索機能に SQL インジェクションの脆弱性があります。脆弱性を見つけ、未リリースも
含んだ全ての商品の一覧を表示してください。
PortSwigger. Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data.
https://portswigger.net/web-security/sql-injection/lab-retrieve-hidden-data
💡 ヒント
● ソースコードの内部では受け取ったパラメータからどのようにクエリを作成するのか想像してみま
しょう。
Slide 82
Slide 82 text
解説
82
const db = new DB();
db.open();
const sql = `SELECT * FROM products WHERE category_name = '${category}' AND
release = 1`;
db.query(sql);
db.close();
以下のようなスクリプトが組まれているのではないか、と推
測できる。
categoryに’+OR+1=1+--に書き換えてリクエストすると以
下のクエリが発行される。（+はスペースの代わり）
SELECT * FROM products WHERE categories = '' OR 1=1 --' AND release = 1
Slide 83
Slide 83 text
SQL injectionを探してみよう②🔍
商品カテゴリの検索機能に SQL インジェクションの脆弱性があります。
データベースにはusersという別のテーブルがあり、usernameとpasswordというカラムが存在します。すべての
ユーザー名とパスワードを取得し、その情報を使用して管理者ユーザーとしてログインしてください。
PortSwigger. Lab: SQL injection UNION attack, retrieving data from other tables.
https://portswigger.net/web-security/sql-injection/union-attacks/lab-retrieve-data-from-other-tables
💡ヒント
● まず、ユーザーから受け取った値でクエリを生成している箇所を見つけてください。
● そのクエリを利用してusersテーブルからデータを取得する方法を考えてください。（UNION）
○ 脆弱性のあるクエリのカラム数を探索してみてください。
○ カラム数が特定できたらカラムのデータ型を探索してみてください。
○ カラム数とデータ型が特定できたらusersテーブルと結合してみてください。
Slide 84
Slide 84 text
解説
84
1. まず、カラム数を特定するために、Nullが入ったダミーテーブルをUNIONで連結してみる。
2. カラム数が特定できたら、次にデータ型を特定するために様々なデータ型のダミーテーブルをUNIONで連結してみる。
3. データ型の特定ができたら、それに合わせてusersテーブルを取得するクエリをUNIONで連結する。
PortSwigger. Lab: SQL injection UNION attack, retrieving data from other tables. https://portswigger.net/web-security/sql-injection/union-attacks/lab-retrieve-data-from-other-tables
Slide 85
Slide 85 text
SQL injectionの対策
基本的な対策は、プレースホルダーを利用してSQL文を組み立てるようにすること。
IPA. 安全なSQLの呼び出し方. https://www.ipa.go.jp/files/000017320.pdf
その他に、SQLの詳細なエラーメッセージをユーザーに出力しない対策も有効です。エラーメッセージか
らテーブルの構成等が漏れ、攻撃に利用されるのを防ぎます。
// パラメータ部分に?を割り当てている
db.query('SELECT * FROM products WHERE categories = ?', 'Gift')
Slide 86
Slide 86 text
OS command injection
Slide 87
Slide 87 text
OS command injection
外部から受け取ったパラメータでOSコマンドを実行する場合に、任意のコマンドが実行されてしまう脆
弱性。
利用シーンは少ないはずですが、OSコマンドを利用して処理を行う場合は別の方法がないか検討し直し
てください。利用しないことがこの脆弱性からアプリケーションを守る一番の対策になります。
Slide 88
Slide 88 text
OS command injectionを探してみよう🔍
商品の在庫確認機能にOSコマンドインジェクションの脆弱性が存在します。パラメータで渡された商品
IDと店舗IDをもとにシェルスクリプトを実行して、標準出力された内容を返却します。
whoamiコマンドを実行して、現在のユーザ名を出力してください。
PortSwigger. Lab: OS command injection, simple case. https://portswigger.net/web-security/os-command-injection/lab-simple
💡 ヒント
● whoamiはunix系列の現在のユーザーを表示するコマンドです。
● リクエストのパラメータが直接シェルスクリプトに引数として渡されると想定してください。
● ディレクトリの中身の参照やファイルの追加、削除等も行ってみてください。
Slide 89
Slide 89 text
解説
89
PortSwigger. Lab: OS command injection, simple case.
https://portswigger.net/web-security/os-command-injection/lab-simple
Slide 90
Slide 90 text
OS command injectionの対策
基本的な対策は、OSコマンドを利用しない実装を検討すること。
やむを得ず利用しなければいけないケースは
● ユーザーから渡された値は検証する。
● OSコマンドのメタ文字をエスケープする。（ライブラリに頼るのが吉）
等の対策が考えられます。
90
Slide 91
Slide 91 text
Directory traversal
Slide 92
Slide 92 text
Directory traversal
外部から受け取ったパラメータでファイルの内容を表示させる場合に、意図しないファイルが閲覧され
てしまうような脆弱性。
実装によっては、改ざん・削除等もありえるため、非常に影響が大きいです。SQLインジェクション同様
絶対に混入しないようにすべき脆弱性です。
Slide 93
Slide 93 text
Directory traversalを探してみよう🔍
商品の詳細ページの画像表示にDirectory traversalの脆弱性があります。/etc/passwdのファイル内容を表
示してください。
PortSwigger. Lab: File path traversal, simple case. https://portswigger.net/web-security/file-path-traversal/lab-simple
💡 ヒント
● HTTP Historyから通信の内容を確認してみてください。
● パス指定には絶対パスの他に、相対パス指定もある。
リクエストの内容を変更した場合は、HTTP History
のOriginal requestからEdited requestを選択すると変
更後のリクエストの内容を確認できます。
Slide 94
Slide 94 text
解説
94
Slide 95
Slide 95 text
意図しないファイルの公開
公開する必要のないファイルが公開ディレクトリに置かれていたり、公開不要なディレクトリが公開
ディレクトリになっている等の設定ミスが起因で意図しないファイルが公開されてしまうケースもあり
ます。
以下は、nginxにおける設定ミスで起きるディレクトリトラバーサルの例です。
Qiita. @no1zy_sec(no1zy). 「nginxの設定ミスで起こるパス トラバーサル」. https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb, 2018年06月
10日
Slide 96
Slide 96 text
Directory traversalの対策
基本的な対策は、外部からファイル名を指定できる仕様を避ける。
その他に
● ファイル名にディレクトリを含めないようにする。（想定しているディレクトリ以外はアクセスさ
せない）
● 非公開ファイルを公開フォルダに設置しない。
アプリケーションの範疇を超えて対策できる場合は
● WAF（Web Application Firewall）の設置。
● ディレクトリリスティングの無効化。
等の対策が考えられます。
Slide 97
Slide 97 text
Conclusion
Slide 98
Slide 98 text
最後に
今回紹介した脆弱性の殆どは、ユーザーから入力されるデータが原因です。どんなユーザーがそのサー
ビスを利用するか分かりません。いつでもサービスは危険に晒されています。
入力されたデータは検証、サニタイズすることを忘れないでください。
今回触れた内容はごく一部です。まだまだ注意するべき点はたくさんあります。研修資料作成にあたっ
て参考にした以下の書籍、サイトを見ることをオススメします。
● 徳丸 浩. 「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実
践」. https://www.amazon.co.jp/dp/4797393165/ref=cm_sw_r_tw_dp_3HAS2XYB4CYVNE9TYWA6
● PortSwigger. Web Security Academy. https://portswigger.net/web-security
Slide 99
Slide 99 text
End