Hello there, ('ω')ノ
まずおさらい：HTTPとは？
- リクエスト → 「このページください！」とお願いする
- レスポンス → 「どうぞ！」と返してくれる
というやり取りです。
✅ 例えば： https://intra.example.co.jp/profile?id=123
- このURLを開く → リクエスト
- ページ内容が返ってくる → レスポンス
実際の中身：ブラウザ開発者ツールで確認する
Chromeの場合：
- F12キーを押す
- 「Network」タブを開く
- 画面を操作してリクエスト内容を観察
そこでチェックすべき具体項目は以下の通りです。
脆弱性チェックポイント① リクエスト編
✅ パラメーター（URLの後ろの?以降）
例：
GET /profile?id=123 HTTP/1.1
→ この数字や文字列を変えてみることで：
- IDOR（不正なデータ閲覧）
- SQLインジェクション
などの脆弱性が見つかることがあります。
✅ Cookie情報
リクエストヘッダー内：
Cookie: sessionid=abcdef123456
→ Cookieが簡単な値の場合、乗っ取りリスク。
✅ ボディ部分（POSTの場合）
フォーム送信時などは以下のようなデータが含まれます：
POST /login HTTP/1.1 Content-Type: application/x-www-form-urlencoded username=admin&password=123456
→ パスワードが平文（暗号化なし）で送られていないか？
脆弱性チェックポイント② レスポンス編
✅ ステータスコード
- 200 → 正常
- 302 → リダイレクト
- 403 → アクセス禁止
- 500 → サーバーエラー
→ 意図しない403や500が出た場合、それ自体が脆弱性情報になります。
✅ Set-Cookieヘッダー
Set-Cookie: sessionid=abcdef; HttpOnly; Secure
→ HttpOnlyとSecureが付いていない場合、セキュリティリスク。
✅ レスポンス内容
- 社内システム名やサーバー情報が含まれていないか
- 例えば：
X-Powered-By: PHP/7.4.12
→ 攻撃者にヒントを与える可能性あり。
実際の手順イメージ
① ログインフォームで入力 → リクエスト確認
② 正しいIDでアクセス → レスポンス確認
③ わざと存在しないIDでアクセス → エラー画面の違いを見る
④ Cookie内容を観察 → セキュリティ設定確認
まとめ：チェックリスト化
- [ ] URLパラメーターにIDやパスワードが含まれていないか？
- [ ] Cookie情報が暗号化されているか？
- [ ] エラー画面でサーバー情報が漏れていないか？
- [ ] ステータスコードが想定通りか？
Best regards, (^^ゞ
