HOME»情報処理安全確保支援士掲示板»令和6年春期試験『午後試験【問3】』
投稿する

[1561] 令和6年春期試験『午後試験【問3】』

 管理人(No.1) 
令和6年春期試験 午後試験【問3】についての投稿を受け付けるスレッドです。
2024.4.21 00:01
りんごニキさん(No.2) 
読めばわかるみたいな問いが多くなかったですか、、??
初期パスワードのままみたいな伏線がいっぱい張られたまま回収されずに終わった感
2024.04.21 15:09
目指せ一夜漬け合格さん(No.3) 
大問3は死んだ気がする
2024.04.21 15:10
cocoさん(No.4) 
初期パスワードのままみたいな伏線がいっぱい張られたまま回収されずに終わった感
→これわかります
あと、ストレージWも使われなかった気がするのですが使われましたかね?
2024.04.21 15:14
つーさん(No.5) 
ストレージWはクレデンシャルが流出したらヤバい要因として使われてた
2024.04.21 15:18
いまいさんさん(No.6) 
samesite属性
さっぱり分からず
勇気の全バツ
2024.04.21 15:19
りんごニキさん(No.7) 
>ストレージWも使われなかった気がするのですが使われましたかね?
これはSSRFのクレデンシャル情報あたりで使われてると言えば使われてると思います
2024.04.21 15:19
ゆうちゃんさん(No.8) 
ストレージWのクレデンシャル情報を方法2を使用して取得する方法ですよね
2024.04.21 15:20
製造部スタッフさん(No.9) 
苦手な内容だったので当てずっぽうにしか書けなかったです(⁠+⁠_⁠+⁠)
もう少しヒントが書いてあってほしかった…
また半年後ガンバります
2024.04.21 15:22
りんごニキさん(No.10) 
Samesite属性は私も全く存じ上げなかったんですが、文中にGETからは認めちゃうわよ、的な記述があった気がしていて、strictは両方バツでリラックス的なやつはGetだけ◯なんかあって奇跡的に導き出せてしまいました
2024.04.21 15:24
やばちさん(No.11) 
りんごニキさん

Getポストだけ拒否するやつは、CRMサーバへのアクセスだけだった気が
2024.04.21 15:38
さくさん(No.12) 
わからない箇所だったので〇〇✖️〇にしてしまった😫
あってたら奇跡😭
2024.04.21 15:42
cocoさん(No.13) 
>> これはSSRFのクレデンシャル情報あたりで使われてると言えば使われてると思います
確かにおっしゃる通りでした!
2024.04.21 15:52
いまいさんさん(No.14) 
Q3-2
sessionIDに紐付く利用者IDと、注文管理番号に紐付く利用者IDが一致するか検証する処理

自信あるんだが?
2024.04.21 15:52
cocoさん(No.15) 
samesiteは❌❌⭕️❌にしました
2024.04.21 15:55
cocoさん(No.16) 
sessionIDに紐付く利用者IDと、注文管理番号に紐付く利用者IDが一致するか検証する処理

私も同じです!
2024.04.21 15:56
ゆうちゃんさん(No.17) 
模範解答と比較用に自分の解答の書き留め
最後時間なくて問題文そのまま抜き出したので自信ないです…
設問1
(1)5
(2)問い合せ管理機能へアクセスした利用者のcookieを利用して利用者になりすまして、会員管理機能から利用者情報を取得する
設問2
(1)「無念の空白」(攻撃者のセッションIDと偽サイトにアクセスした利用者のcrlf_tokenを紐付けてリクエストするとこまでは分かったけど書けんかった…)
(2)(正解は××○×であることは調べたんでここは不正解)
a.×
b.×
c.×
d.○
設問3
(1)注文管理番号の後ろ6桁を総当たりでリクエストする
(2)セッションIDに割り当てた利用者と注文管理番号から特定した利用者の一致を確認する処理
設問4
(1)利用者がGETメソッドでリクエストしているから(ここは記憶ちょっと曖昧)
(2)IMDSでクレデンシャル情報を取得したいプライベートIPアドレスを含むURLへアクセスする
(3)トークンを発行するURLにPUTメソッドでアクセスし、レスポンスボディに含まれるトークンをリクエストヘッダに含めてストレージWへアクセスする
(4)アクセス元のIPアドレスを制限する処理
2024.04.21 16:02
edさん(No.18) 
SESSIONIDに紐づく利用者の注文履歴であることを検証

丸であってくれ
2024.04.21 16:03
ansuliumさん(No.19) 
この投稿は投稿者により削除されました。(2024.04.21 16:09)
2024.04.21 16:09
もはやさん(No.20) 
webアプリ脆弱性診断士とかに試験名改名したら?
2024.04.21 16:10
ssdさん(No.21) 
色々厳しい戦いでした、、
設問1(2)は全利用者の情報を取得できる方法という旨だったので

問い合わせ機能にて不正なログイン画面を作成するコードを仕込む→管理者が管理機能で問い合わせを呼び出した際にコードが発動→偽サイトにログインID/PWを入力すると攻撃者に管理者ID/PWが搾取され管理者画面にログインして利用者情報を取得可能
みたいな感じで書きました。

得点調整お願いします。。
2024.04.21 16:31
てすてすさん(No.22) 
1.1は9にしました。
1.2は、管理者が問い合わせ情報を見たときにスクリプトが実行され、Cookieを取得した攻撃者が管理者権限で利用者情報を取得する。と書きました
2024.04.21 16:38
Hogeさん(No.23) 
1.1 1.2同じ人いて安心した😮‍💨
2024.04.21 16:47
ものものさん(No.24) 
問い合わせ情報を管理者が開いた際に、会員管理機能のURLの内容を攻撃者PCに送信するスクリプトを埋め込むと書きました。
2024.04.21 16:48
ドムドムハンバーガーさん(No.25) 
問3だけでなく全体的に行間が広めに出題されて難しかったです。。
前の午後2より難しいと思う。
2024.04.21 17:10
cocoさん(No.26) 
メモとして書き残します

設問1
(1)9
(2)図3中のリクエスト内のスクリプトcookieを攻撃サーバに送出するコードを埋め込み、取得したjsessionidを利用して会員管理機能から利用者情報を取得する
設問2
(1)利用者がサイトXにログインしている状態で、偽サイトに誘導してcookieを不正に取得する。取得したcookieからjsessionidと攻撃者のアカウントで取得したcsrf_tokenを利用してサイトXにユーザAになりすましアクセスする
(2)
a.×
b.×
c.⚪︎
d. ×
設問3
(1)注文年月を固定し、英大文字6桁の値を総当たり攻撃する
(2)セッションIDから取得した利用者idと注文管理番号から特定した利用者idが一致することのチェック処理
設問4
(1)GETメソッドでのログインが許可されていないため
(2)クレデンシャル情報を取得するURLをpageパラメタに設定する
(3)トークンを発行するURLにPUTメソッドでアクセスし、返却されたトークンをリクエストヘッダに含めてクレデンシャル情報を取得する
(4)pageパラメタのドメインがサイトPのものであることの確認処理
2024.04.21 17:10
はまななさん(No.27) 
注文管理番号から特定した利用者id

これって特定できるんですか?
2024.04.21 17:26
通りすがりさん(No.28) 
俺も英語大文字6字総当たりにしたわ
昔Twitterかなんかへの攻撃で見た気がするけどオンラインで6文字総当たりって現実的にどうなんやろ
部分的に総当たりする行為自体は技術的には可能
2024.04.21 17:33
ゆうちゃんさん(No.29) 
リクエストの下に(小さく)注意書きの記載がありました。
2024.04.21 17:36
怒りのトマトさん(No.30) 
小文字含めた英数字記号6桁ならまだしも、大文字英固定6なんて手動でもいけるレベル
2024.04.21 17:38
次もSCさん(No.31) 
設問3(1)SQLインジェクションついて書いてしまったんですけど私は大バカですかね...
2024.04.21 17:45
Kingshuさん(No.32) 
問題3は全部記述問題で、答えをはっきり覚えていませんが
以下のいメッセージで解答しています、


設問1
(1)9
(2)まず管理者のログインIDとパスワードを不正に窃取して、その情報で問合せ管理機能で
    事前に登録した利用者情報を取得するスクリプトを実行させる問合せの画面を照会する
設問2
(1)csrf_tokenを取得する不正リンクを利用者に送り、クリックさせた後、攻撃者サーバに
    送信されたcsrf_tokenで会員機能の編集リクエストをPOSTする
(2)a.❌ b.❌ c.⭕️ d.❌ 
設問3
(1)オーダIDの推測し、複数のオーダIDのをブルートフォースしながら、履歴照会をする
(2)order-codeがそのセッションIDに該当利用者のものかどうかをチェックして、不一致の場合、エラーとする
設問4
(1)CMS管理画面へのアクセスが管理者PCとVPC内に限定するから
(2)pageにクレデンシャルを取得するURLにして、クレデンシャルを取得後、それを利用してクラウドWのストレージサービスにアクセスする
(3)WebサーバYに送るリクエストのメソッドをPUTに変更後、pageにトークンを発行するURLにして、レスポンスからクレデンシャルを取得する、それを利用してクラウドWのストレージサービスにアクセスする
(4)pageに指定するURLが事前に許可されているものではない場合、遷移エラーとする
2024.04.21 18:02
ドムドムハンバーガーさん(No.33) 
設問3(1)については自分もオーダIDを総当りで調べて閲覧履歴を参照すると書いた気がします
2024.04.21 18:33
製造部スタッフさん(No.34) 
こういう問題の基礎を学ぶのに良い参考書をご存知でしたら教えていただけませんか?
(小生は応用情報しか持っていません)
2024.04.21 20:18
インドからさん(No.35) 
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

実際にwebサーバを立てて脆弱性を学べるのでいい参考書です。
2024.04.21 20:28
通りすがりさん(No.36) 
問1(1)のリクエストがPOST /shop/contactになってて.jp/adminではないから管理者画面の9ではなく5では?
2024.04.21 20:42
ponponさん(No.37) 
>問1(1)のリクエストがPOST /shop/contactになってて.jp/adminではないから管理者画面の9ではなく5では?
これは所謂ストアドXSSっていうやつで、5に対して送られた問い合わせ内容を9で閲覧したときに出力されてスクリプトが動く
だから答えは9


だと思ってるんだけど合ってるよね?ね?正直よくわからん
2024.04.21 21:12
通りすがりさん(No.38) 
>ponponさん
そもそも別の機能の画面って書いてあるので9っぽいですね、物凄い凡ミスで悲しくなります…
2024.04.21 21:37
びろたさん(No.39) 
設問3の(2)は、皆さんの上であげていただのを見てなるほどと思いました。注文管理番号の注釈にはマークをつけてましたが、試験中に思いつきたかった〜
2024.04.21 23:12
製造部スタッフさん(No.40) 
〉インドからさん
ありがとうございます。頑張って読んでみます。
2024.04.22 01:58
imaixxx00さん(No.41) 
この投稿は投稿者により削除されました。(2024.04.22 11:53)
2024.04.22 11:53
いまいさんさん(No.42) 
Q1-1は9かぁ・・・
最初5にして、違う画面でって書いてあるから5じゃないんかぁ。。。って思って

name= にスクリプトが入ってるから、画面に名前が表示されないと行けないよなぁって
利用者情報が表示される  8  にしたンゴ・・・
2024.04.22 11:53
ゆうちゃんさん(No.43) 
Q1-1.
スクリプトを含むのリクエストを送る機能は5だけど問題文はそのスクリプトが実行される機能を問うてるから答えは9
問題よく読んでない方が悪いけどIPA嫌い😠
2024.04.22 12:53
一晩寝てから考えたさん(No.44) 
Q1-1について、

答えは9、かなと素直に考えていたんですが、考えてみたら5から9へ渡し5に戻るのは普通の状態遷移かも?

で、24P図3を確認し、「subject_id」が  004  になっているため、
もしかしたら項番4「会員機能(編集)」が見えるようになってしまっていたかもと。

うがち過ぎでしょうか?
2024.04.22 16:45
いまいさんさん(No.45) 
------------------------------図3-------------------------
[リクエスト]
POST /shop/contact HTTP1.1
Host:(省略)
(省略)
Content-Type: ・・・・
Content-Length: (省略)
Cookie: ・・・・
<ここは改行>
subject_id=004&name=<ここにスクリプト>&tel=(省略)&・・・・

[レスポンス]
(省略)
<ここも改行>
<h1>問い合わせを受付ました。</h1>
(省略)
----------------------------------------------------------

図3の記載から、subject_id=~はリクエストのbody部分。このbodyの内容を表示させる画面を選ぶ必要がある。

9で  の  件名004  を開くと、こんな表示になるはず
ーーーーーーーーーーーーーーーーーーーーーーーーーー
【問合わせ管理機能】
件名  004
名前  <ここにスクリプト>
電話  (省略)
ーーーーーーーーーーーーーーーーーーーーーーーーーー

名前部分のスクリプトが発動する。
1問目はもっと優しくあってくれ・・・
2024.04.22 18:26
ていくさん(No.46) 
設問2(2)
まったく理解してない私。
私にとっては、  
全て◯  or  全て✕
の2択でしたw

全て✕にしたが、2択の賭けには勝った!?
我ながら、情けねーw
2024.04.22 18:46
今度こそ受かりたいさん(No.47) 
>一晩寝てから考えたさん

はい。私もそう考えて4にしました。。
みなさん9にされているので、どうなんでしょう?
2024.04.22 19:17
むぐむぐさん(No.48) 
設問1(1)
答えは間違いなく9です。

問い合わせ時の名前欄に攻撃コードを仕込み送信ボタンを押します。
すると問い合わせを受け付けました。と表示されて処理が終わります。
(このあと画面遷移すると勘違いされているように見受けられますが、何も起きません。)
しかし、この際にDB等に攻撃コードが保存されてしまいます。

ではDBの攻撃コードを表示するのはどこかというと、9の問い合わせ管理機能になります。

管理者がお問い合わせ内容を確認しようと、9の画面を開くとサーバ上でDBに仕込まれた攻撃コードをHTMLに書き込んで管理者のブラウザへ送信してしまいます。
すると管理者の画面上で、攻撃コードが発火してしまいます。

このように利用者の立場から、管理者へ攻撃するのが目的のStored型XSSになります。

(2)にもつながりますがこの際に管理者のcookieをjsによって外部サーバへ送信することで、攻撃者が管理者のcookieを盗み出し、管理機能にアクセス可能になります。
問題文中でSESSIONIDにはSecure属性のみと記載があるのはここのヒントですね。
2024.04.22 20:14
5pt獲得さん(No.49) 
問3,時間足りず。。5点の答案晒すのでマジで5点かどうかコメントください
PS)皆さんどうか自信持ってください。私は最低レベルで大ゴケしていますので、、

1(1)  

1(2)
問い合わせ機能へ登録された会員の利用者情報についてを表示させるようなスクリプトを送信する

2(1)
利用者側が一度ログイン機能でログインしている状態にて、サーバー側とのセッションが有効な24時間の間に当該リクエスト内のcsrf tokenの値を設定して会員情報の変更を行う
2(2)XXXO

3(1)
他の利用者のセッションIDを盗む
3(2)
【残念ながら時間切れで何も書いてないお】

4(1)
サイトPとサイトYは異なるオリジンなのでCookieが送られないため
4(2)(3)
【残念ながら時間切れで何も書いてないお】
4(4)
許可されていないオリジンへのアクセスは禁止とする処理

※この回答は支離滅裂なのであてにしないこと
時間管理が悪過ぎて成長してないです...普通に解ける皆さんがすごい...
5点あるかも怪しくないすか?
2024.04.22 20:35
さかなさん(No.50) 
>5pt獲得さん

1(1)で2点
2(1)セッションの有効期間について言及しているので部分点で1〜2点
2(2)strictの2つは合っているので2×2として4点
くらいで採点して7〜8点てところでしょうか。
2024.04.22 20:44
KSさん(No.51) 
見当違いな質問の場合申し訳ありません。

XSSの設問で、subject_idから利用者情報を取得することはできないのでしょうか。
セッションIDではなくそちらに着目してしまいました。
有識の方、ご回答頂けますと幸いです。
2024.04.22 20:46
むぐむぐさん(No.52) 
>KSさん

subject_idはこの問において意味のない数字になります。

説明がないので推測ですが、おそらくお問い合わせ時の内容を選択するような機能ではないかと思います。

例として以下のような項目を、ラジオボタンやプルダウンで選ぶ機能です。
001 商品の故障について
002 サポート情報について
003 ご意見・ご感想
2024.04.22 21:18
cocoさん(No.53) 
配点予想どんな感じですかね??
10問あるので一つあたり5点か…??
2024.04.22 22:29
さかなさん(No.54) 
こんな感じでしょうか?
設問1
(1)2点
(2)6点
設問2
(1)6点
(2)2点×4
設問3
(1)4点
(2)5点
設問4
(1)4点
(2)5点
(3)6点
(4)4点
2024.04.22 23:01
一晩寝てから考えたさん(No.55) 
いまいさん様
むぐむぐ様
今度こそ受かりたい様
お返事ありがとうございました。

まず、リクエストとレスポンスを状態遷移などで書いてしまって申し訳ありません。(まだ寝ていたようです)
コードまで書いて頂いて大変わかりやすかったです。
又004が項目ではなく、ラジオボタンは納得です。
フォームなんてもう何年も作ってなかったので、

「あれ?もしかして格納じゃなくて反射型?私、やらかしちゃったかな?」

と焦りました。
もしかしたらあえて004にしてひっかけ反射型攻撃を作問者に食らったのかもしれません。
9で管理者狙いの格納型XSSで間違いないですね。
流行っているのだろうか、最近よく聞きます。末恐ろしいです。
2024.04.22 23:32
一晩寝てから考えたさん(No.56) 
すみません。ID違いますが、間違いなく同一人物です。(クッキー保持してませんでした)
2024.04.22 23:36
KSさん(No.57) 
>むぐむぐさん
ありがとうございます。
2024.04.23 04:16
いまいさんさん(No.58) 
subject_id ってそういうか!
まじで解説助かりますぅ!!
問題の解像度が爆上がりしました…!!
2024.04.23 08:37
SCさん(No.59) 
設問3(1)はSQLインジェクションでも行けると思うのですが、
誰か有識者の方いらっしゃいませんか?
2024.04.24 13:41
むぐむぐさん(No.60) 
>SCさん
SQLインジェクションでは得点はもらえないと思います。

前提条件として問題文にサイトXから検出した脆弱性はXSS、CSRF、認可制御の不備の3つであると明記してあります。よってサイトXにはSQLインジェクションの脆弱性が存在しておらず、攻撃しても成功することはありません。

また、設問3に[認可制御の不備について]について答えよ。と明記してあります。
よってSQLインジェクションは認可制御の不備ではないため、的外れは回答になってしまっております。
2024.04.24 15:03
しょうゆさん(No.61) 
Itecの解答速報来ましたね。

設問1(2)はこれだと問い合わせ機能を利用した会員の利用者情報しか取得できず、問題文にある「全会員の利用者情報」を取得できないですね。
CookieのHttpOnly属性が設定されていないことに着目して、スクリプトからセッション情報を攻撃者のサーバに送信させ、セッションの有効期間内にセッション情報を用いて管理者アカウントに不正にログインし、利用者管理画面から取得するのが正しいと思われます。
2024.04.24 20:28
しょうゆさん(No.62) 
この投稿は投稿者により削除されました。(2024.04.25 10:32)
2024.04.25 10:32
ponponさん(No.63) 
4-3
方法Gを使ってクレデンシャルをとる方法を具体的に答えろってやつ
方法Gって徳丸さんの記事「SSRF対策としてAmazonから発表されたIMDSv2の効果と限界」に記載があるGopherプロトコルってやつだよね?頭文字も一緒やし

こんなん毎日WEBアプリケーション診断してる人でもちゃんと知ってて解答できるのどんだけいるんじゃい!受験者の1%も解けてないやろ!
自分は別サーバー建てて攻撃リクエストを送信するHTMLを置くみたいなこと書いたけど0点やろなぁ
2024.04.24 22:49
ミッキーヌチバナさん(No.64) 
問1(2)、管理者のsessionID含むCookie情報で不正にログインし、管理者画面から会員情報にアクセスする

問3(2)、リクエストに上限回数を設け、不自然なリクエストがあったら通知して一時凍結

問3(1)、POSTメソッドしか受け付けないから←SSRFに言及してって何???

問3(3)、だいたい似たようなこと書いてるけどPUTメソッドに言及しないとダメ?

問3(4)、リクエストを受ける際に文字列エスケープ処理を施す


この辺りが非常に怪しいのですが……部分点貰えるかなあ
2024.04.25 09:29
しょうゆさん(No.65) 
この投稿は投稿者により削除されました。(2024.04.25 10:30)
2024.04.25 10:30
しょうゆさん(No.66) 
>ミッキーヌチバナさん

>問1(2)、管理者のsessionID含むCookie情報で不正にログインし、管理者画面から会員情報にアクセスする
管理者のsessionID含むCookie情報の取得方法が入っていないので部分点ですかね。

>問3(1)、POSTメソッドしか受け付けないから←SSRFに言及してって何???
SSRF攻撃の特徴として、GETメソッドによって攻撃が行われていることに着目するっていうことだと思います。
「SSRF攻撃はログインが許可されないGETメソッドでのリクエストだから」みたいな感じでしょうか。
私が採点者なら「POSTメソッドしか受け付けないから」でも正答にすると思います。

>問3(3)、だいたい似たようなこと書いてるけどPUTメソッドに言及しないとダメ?
PUTメソッドの単語が入っていないと減点はされそうですね。
2024.04.25 10:30
ミッキーヌチバナさん(No.67) 
しょうゆさん
ありがとうございます〜〜ギリギリだ……

ちなみに問2(1)、
XSS攻撃によりcsrf_tokenを盗み、ユーザになりすましてアクセス後、不正に値を上書きする

などではダメかな……(問1(2)とほぼ同じ攻撃手段)
2024.04.25 17:29
しょうゆさん(No.68) 
>ミッキーヌチバナさん

設問1が[XSSについて」
設問2が[CSRFについて]
というように攻撃手法毎に設問が分けられているので、設問2ではCSRFに言及した解答でないと厳しそうな気はしますね。。。
2024.04.25 18:26
ひでまるさん(No.69) 
設問4(1)CMS管理画面へのアクセスが管理者PCとVPC内に限定するから

部分点はもらえるかな〜?
2024.04.30 13:34
返信投稿用フォーム

お名前

顔アイコン


本文(コミュニティガイドライン⇱を順守して適切な投稿を心がけましょう)

投稿削除用のパスワード(20文字以内)

投稿プレビュー
※SQL文は全角文字で記載してください。
※宣伝や迷惑行為を防止するため、当サイトとIPAサイト以外のURLを含む文章の投稿は禁止されています。

投稿記事削除用フォーム

投稿No. パスワード 
© 2014-2024 情報処理安全確保支援士ドットコム All Rights Reserved.

Pagetop