https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000009sgk-att/2022r04h_sc_pm2_qs.pdf
以下のおすすめ問題の解説となります。
良書。
[サイトXのクリックジャッキング脆弱性]
サイトXでは、クリックジャッキングによって、利用者が気付かずに利用者情報の公開範囲を変更させられてしまう脆弱性が検出された。攻撃者が図3の画面を用いてクリックジャッキングを行う場合を仮定してみる。このとき、クリックイベントは、利用者から見て手前にある画面上で発生するものとする。
攻撃者は、画面（c）を利用者から見て（d）に（e）状態で罠サイトに公開し、サイトXの画面（f）を利用者から見て（g）に（h）状態で重ねて表示する。この状態のサイトにアクセスした利用者は、意図せず利用者情報の公開範囲を変更させられてしまう可能性がある。
クリックジャッキング脆弱性の対策には、レスポンスヘッダに（i）を含める方法を（j）を含める方法がある。後者は標準化されている。
c：β d：奥 e：可視な f：α g：手前 h：透明
利用者に押させたいのは、利用者情報の公開範囲を変えることができるものである
こいつの制限なしを押させるためにどうするかという問題
この画面を手前に置き、透明にすることで、誘導可能だ
ユーザは、ここをクリックを押したときに、裏側で利用者更新を押すことになる
①ここを押して次にここを押すという順序で更新させるわけだ。ただ、こんな怪しいクリックするのだろうか、こんなUI作るか？ってツッコミどころのある問題である
画面βを利用者から見て奥に可視状態で罠サイトを置き
サイトXの画面αを利用者から見て手前に不可視状態で重ねると罠を張ることができる
i：x frame-options j：Content Security Polocy
クリックジャッキング脆弱性の対策には、レスポンスヘッダに（i）を含める方法を（j）を含める方法がある。後者は標準化されている。
クリックジャッキングの脆弱性対策をどうするかという問題。
IPAの資料を参考にする。
9-(i)-a HTTPレスポンスヘッダに、X-Frame-Optionsヘッダフィールドを出力し、他ドメインのサイトからのframe要素やiframe要素による読み込みを制限する。
9-(i)-b 処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
が存在する。
Content Security Policyについての記載がないが、一般的な解説には、X-Frame-Optionsと同時に書いている。パスワード認証のほうがあまり推奨されないようだ
