Hello there, ('ω')ノ
1. SQLインジェクション（SQLi）
| 覚え方 | SQL 文に“悪意ある命令”を混ぜてデータベースを操作する |
|---|---|
| よくある症状 | ― ログインを通り抜けられる ― データベース全件ダンプ |
| 簡易チェック | フォームや URL パラメータに ' OR '1'='1 を入れてエラー内容・挙動を確認 |
| 再現ポイント | 1. Burp Repeater でパラメータを書き換え 2. -- などコメントアウトも試す |
| 予防策 | - プレースホルダー付きの 準備済み文（Prepared Statement） を使う - ORM でもバインド変数を徹底 |
2. クロスサイトスクリプティング（XSS）
| 覚え方 | 入力欄にスクリプトを仕込み、他ユーザーのブラウザで実行させる |
|---|---|
| ３タイプ | Stored（保存型）／Reflected（反射型）／DOM-based |
| チェック例 | コメント欄に <script>alert(1)</script> を投稿 → 表示時に実行されるか |
| Burp Tips | “Inspector” で HTML エンコードの有無確認 → 漏れていれば脆弱 |
| 予防策 | 任意入力は < > " などエスケープ＋CSP で二重ロック |
3. CSRF（クロスサイトリクエストフォージェリ）
| 覚え方 | “だましリンク”を踏ませて 被害者の権限 で操作させる |
|---|---|
| 小テスト | 1. ログイン中に自作 HTML フォームを送信 2. 設定変更できれば CSRF 成功 |
| 着眼点 | - 重要操作に CSRF Token が付いているか？ - SameSite Cookie が Lax/Strict？ |
| 防御策 | CSRF トークン＋参照元ヘッダー検証＋SameSite=Strict が王道 |
4. IDOR（不適切な直接オブジェクト参照）
| 覚え方 | URL の ID を変えただけで 他人のデータ が見えてしまう |
|---|---|
| 検証手順 | /api/user/123 → /api/user/124 に書き換えてレスポンス比較 |
| ヒント | GraphQL API はフィールド名を変えず ID だけで参照しがち＝狙い目 |
| 予防策 | サーバー側で必ず認可チェック（ユーザーID⇔所有者） |
5. XXE / SSRF（外部エンティティ / サーバーサイドリクエスト）
| 用途 | サーバーが内部で別URLを取得する機能に“改ざんURL”を渡す攻撃 |
|---|---|
| よくある入口 | ファイルアップロードの XML 処理／画像変換 API の URL パラメータ |
| 実害 | 内部ネットワークへポートスキャン／メタデータ収集（AWS 169.254.169.254） |
| 簡易確認 | file:///etc/passwd や http://localhost:80 を指定し挙動を観察 |
| 予防策 | ― XXE: 外部エンティティ無効化 ― SSRF: アウトバウンド URL ホワイトリスト＋メタデータIP遮断 |
6. どう調べ、どう報告するか？“共通フロー”
- 入力点リストアップ（フォーム／URL／ヘッダー）
- 改ざん → 反応観察（エラー・挙動差分）
- PoC 化（curl / Burp 実行手順 + スクショ）
- 影響度を定義（何が取れる・操作できる？）
- 再現手順 & 修正案 を添えて報告
影響度を数字で示せると説得力アップ 例： • 50 万ユーザーの個人情報閲覧可能 • 任意コード実行でサーバー完全掌握
まとめ：定番は“見つけやすく、直されやすい”
- まずは SQLi / XSS / CSRF / IDOR の基礎を押さえる
- “教科書どおり”でも、 設定ミスや新機能追加 で再発は日常茶飯事
- 見つけたら PoC + 影響説明 + 再発防止策 をセットで提案すると評価UP
基本を極めることが“ハイレベル”への最短ルートです。
Best regards, (^^ゞ
