令和4年春午後2問1設問5(2)
広告
ruruさん
(No.1)
https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05h_sc_pm2_qs.pdf
令和4年春午後2問1設問5(2)
SSRF脆弱性の問題で、P社用のAuthorizationヘッダをエラーページにアクセスする際にそのまま利用していることにとても違和感があります。
エラーページにアクセスする際には不要なAuthorizationヘッダを削除や変更していないことは脆弱性の要因ではないのですか。
(2)の回答が「returnURLの値を固定値にする」というものだったため、この違和感が正しいものか教えて頂けると助かります。
令和4年春午後2問1設問5(2)
SSRF脆弱性の問題で、P社用のAuthorizationヘッダをエラーページにアクセスする際にそのまま利用していることにとても違和感があります。
エラーページにアクセスする際には不要なAuthorizationヘッダを削除や変更していないことは脆弱性の要因ではないのですか。
(2)の回答が「returnURLの値を固定値にする」というものだったため、この違和感が正しいものか教えて頂けると助かります。
2025.04.03 15:36
vavatyaさん
(No.2)
「P社用のAuthorizationヘッダをエラーページにアクセスする際にそのまま利用している」確かにそうですよね。必要のない認証情報を渡してるんで危険ですよね。
ただ、今回に限って言えば、問題はどうすればSSRFの脆弱性が解消されるのか?ということなので、Authorizationヘッダを削除したとて、SSRFそのものの脆弱性は解消されません。だから解答は、「returnURLの値を固定値にする」というSSCRの脆弱性の根本を解決する方法になってるんだと思います。(本来意図しないリクエストを防ぎたい)
Authorizationヘッダを削除したら、Authorizationヘッダの情報はわたらなくなるけど、予期せぬリダイレクトができることには変わりないから的な考えから。
ただ、今回に限って言えば、問題はどうすればSSRFの脆弱性が解消されるのか?ということなので、Authorizationヘッダを削除したとて、SSRFそのものの脆弱性は解消されません。だから解答は、「returnURLの値を固定値にする」というSSCRの脆弱性の根本を解決する方法になってるんだと思います。(本来意図しないリクエストを防ぎたい)
Authorizationヘッダを削除したら、Authorizationヘッダの情報はわたらなくなるけど、予期せぬリダイレクトができることには変わりないから的な考えから。
2025.04.04 08:52
ruruさん
(No.3)
vavatyaさん
設問の解答の適切性とは別に、危険性の認識は正しいとのことで、安心しました。
回答ありがとうございます。
設問の解答の適切性とは別に、危険性の認識は正しいとのことで、安心しました。
回答ありがとうございます。
2025.04.04 09:45
広告
返信投稿用フォーム
スパム防止のためにスレッド作成日から40日経過したスレッドへの投稿はできません。
広告