🌈【にじいろ式ポイント解説】支援士 R6春 SC 午後問3 ｜XXS・CSRF・IDOR｜Webセキュリティ
こんにちは。
事務職をしながら情報処理安全確保支援士の勉強をしている、にじいろです。
今回の令和6年春 午後問3ですが、
webセキュリティの問題になります。
この問題がとても難しかったので、ChatGPTにお願いをして
設問1（XSS）
設問2（CSRF）
設問3（認可不備 / IDOR）
を小テスト形式で整理していきました。
こちらがとても為になったので皆さんもよかったらご利用ください。
紙と鉛筆があるとよりよいと思います。
使い方は、
1️⃣回目
ヒントまで見て穴埋めをします。
2️⃣回目
ヒントを見ないで穴埋めをします。
3️⃣回目穴埋めなしで答えます。
🌐 問題の状況
あるWebサイトZでは以下の機能がある。
問合せ機能：入力内容が管理画面に表示される
注文履歴：URLの order-id で取得
外部URL取得機能：指定したURLの内容を表示
セッション管理：cookie（HttpOnlyなし、SameSite未設定）
order-code：注文年月6桁とランダム英大文字6桁で構成されている
異なる利用者アカウントで取得したcsrf_tokenでも正常処理される
注文番号の値から利用者を特定することができる
📝 小テスト①（XSS）
問合せ機能に悪意のあるスクリプトを入力した場合、
管理者権限を取得できる理由を説明せよ。
穴埋め
攻撃者が＿＿＿＿＿＿を用意し、
管理者にそのリンクを踏ませることで、
管理者権限の＿＿＿＿＿＿を攻撃者のWebサイトに送信させ、
その値を利用することで、
＿＿＿＿＿＿としてサイトXにアクセスできるため
🌟 ヒント
✴️ XSSを利用といえば
👉 ◎◎リンク
✴️ 格納型XSS
👉 入力したスクリプトが、あとで別画面に表示されて実行される
✴️ CookieパラメータにはSecure属性しかない
👉 HttpOnly属性がセットされていない
👉 JavaScriptから※※※を読み取れる
✴️ サーバ側のセッションの有効期間は24時間
👉 例え攻撃者であっても、同じ管理者としてみなされる
↓
↓
✅ 答え
攻撃者がわなリンクを用意し、
管理者にそのリンクを踏ませることで、
管理者権限のcookieを攻撃者のWebサイトに送信させ、
その値を利用することで、
管理者としてサイトXにアクセスできるため
📝 小テスト②（CSRF）
SameSite属性が設定されていない環境において、
利用者情報を変更させる攻撃手順を説明せよ。
穴埋め
攻撃者が自らのアカウントで取得した＿＿＿＿＿＿と一緒に、
利用者情報をサイトXに送るよう構成した＿＿＿＿＿＿を用意する。
その後、＿＿＿＿＿＿などで利用者を誘導し、
利用者情報を＿＿＿＿＿＿させる。
✴️ CSRF対策
👉 ※※※※_token を利用する
✴️ 問題文では
👉 「異なる利用者アカウントで取得した※※※※_token」でも正常処理→脆弱性有
✴️ ブラウザは
👉 cookieを自動送信する
✴️ SameSite属性が設定されていない場合
👉 外部サイトからのリクエストでもcookieが送信される
✴️ その結果
👉 攻撃者サイトからのリクエストでも、ログイン中の本人として扱われる
✴️ CSRF攻撃といえば
👉 ※※フォーム
✴️ 利用者を誘導する代表例
👉 詐欺メール
↓
↓
✅ 答え
攻撃者が自らのアカウントで取得したcsrf_tokenと一緒に、
利用者情報をサイトXに送るよう構成したわなフォームを用意する。
その後、詐欺メールなどで利用者を誘導し、利用者情報を変更させる。
📝 小テスト③（SameSite）
次の表の a ～ d に入る内容を、
「○（cookieが送られる）」または
「×（cookieが送られない）」から選べ。
🌟 ヒント
✴️ SameSiteは
👉 「外部サイトから来たときにcookieを送るか」を制御する
✴️ Strict
👉 外部サイトからは送らない
✴️ Lax
👉 GETだけ送る
✴️ None
👉 全部送る（危険）
↓
↓
✅ 答え
a ：×
b ：×
c ：○
d ：×
📝 小テスト④（認可不備 / IDOR）
注文履歴機能では、
order-code を指定することで注文履歴を表示できる。攻撃者が、他人の注文履歴を閲覧するために用いた攻撃手法を説明せよ。
※order-code：注文年月6桁とランダム英大文字6桁で構成されている
穴埋め
＿＿＿＿＿＿ の下6桁を、
＿＿＿＿＿＿ で試行する。
🌟 ヒント
✴️ order-code
注文年月6桁
ランダム英大文字6桁
で構成されている
✴️ 攻撃者は
👉 他人のorder-codeを知らない
↓
↓
✅ 答え
order-code の下6桁を、
総当たりで試行する。
📝 小テスト⑤（認可不備 / IDOR 対策）
注文履歴機能では、
order-code を指定することで注文履歴を表示できる。この機能に追加すべき処理を説明せよ。
穴埋め
＿＿＿＿＿＿ の値から特定した利用者アカウントと、
＿＿＿＿＿＿ の値から特定した利用者アカウントが一致することを確認する。
一致しなければ＿＿＿＿＿＿ にする。
🌟 ヒント
✴️ 今回の問題の本質
👉 「ログインしているか」ではなく
👉 「そのデータを見てよいか」
✴️ 認可不備
👉 他人のデータを見られる状態
✴️ サーバ側で確認すべきもの
👉 「この order-code は本当に本人のもの？」
✴️ cookie
👉 ログイン中の利用者を識別する
✴️ order-code
👉 注文履歴の利用者を特定できる
✴️ 一致しなかったら？
👉 他人の情報なので拒否
↓
↓
✅ 答え
cookie の値から特定した利用者アカウントと、
order-code の値から特定した利用者アカウントが一致することを確認する。
一致しなければエラーにする。
📚 必要な知識まとめ
午後問3で必要な知識を、“攻撃者の視点”で整理します。
🧪 ① XSS（格納型）
成立条件
入力値がそのまま別画面に表示される
HttpOnly が付いていない cookie
管理者がその画面を開く
攻撃者の狙い
管理者の cookie を盗む
盗んだ cookie を使って「管理者として」ログインする
にじいろ式ワンフレーズ
「HttpOnlyなし → JSでcookie読める → 管理者が踏んだら終わり」
🧪 ② CSRF（SameSiteなし）
成立条件
SameSite が None（未設定）
偽フォームを踏ませる誘導が可能
CSRFトークンの検証が甘い（今回の問題の肝）
攻撃者の狙い
利用者のブラウザに「勝手にリクエストさせる」
cookie は自動送信されるので、本人として扱われる
にじいろ式ワンフレーズ
「偽フォーム＋自動送信cookie → 本人のふりができる」
🧪 ③ SameSite 属性
属性外部サイトからのリクエスト送信されるcookieStrict全部拒否「×」LaxGETだけOK「〇」（GETのみ）None全部送る「〇」（危険）
にじいろ式ワンフレーズ
Strict：絶対送らない Lax：GETだけ送る None：全部送る（危険）
🧪 ④ 認可不備 / IDOR（推測可能な識別子）
成立条件
URLパラメータで他人の情報を取得できる
推測可能な識別子（今回の場合：ランダム英大文字6桁）
認可チェックがない
攻撃者の狙い
order-code を総当たりして他人の注文履歴を閲覧
にじいろ式ワンフレーズ
「推測できるID＋認可チェックなし → IDOR成立」
🌈 全体まとめ
令和6年午後問3は、 「セッション管理が甘いと、複数の攻撃が連鎖する」 という典型的な問題でした。
HttpOnlyなし → XSSでcookie盗まれる JavaScriptからcookieが読めるため。
SameSiteなし → CSRF成立 外部サイトからのリクエストでもcookieが自動送信されるため。
認可チェックなし → IDOR成立 「このユーザが見てよいデータか」をサーバが確認しないため。
推測可能ID → 総当たりで突破される IDに規則性があり、攻撃者が当たるまで試せるため。
“セッション管理・入力値処理・認可チェック”の3つが揃わないと、Webアプリは簡単に破られる
という意味が込められています。
本日の記事は、ほぼ、生成AIのコピペでした。
AIとした小テストがとても為になったためです。
自分の勉強記録として、見返せるように保存しておきます。
webセキュリティは同じような問題がたくさん出るので、過去10年分を解いた方が良い、とYouTubeで聞きました。
ただ、難易度が高すぎますね。
そんな時は、小テスト作戦がおすすめです。
わたしも余力があったら、設問4️⃣（かなりの難問）も先ほどAIと学習したのでアップします。
ではでは☂️
