情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

令和7年春期試験 午後試験【問3】についての投稿を受け付けるスレッドです。

果たして、署名URLの生成は（え）なのか（い）なのか…。
ファイル名わからんと生成できないよな？（え）だよな…？確信が持てねぇよ

フロントエンド寄りの問題と思って解き始めたらバックエンド寄りの話に変わってトホホでした

ハンドシェイクはマジで知らんがな！！！！！
今回撃沈した人多そうですが合格率で調整入るんでしょうか。。

サーバが生成するとか書いてた気がして(イ)にしましたけど、どうなんでしょうか...?
自信ないすね

やっぱり（い）かなぁ…。最初（い）、って書いてたんだけど、署名対象の範囲を見て、ﾑﾑｯ、ってなって変えちゃったんだよなぁ…

R7春の良心

署名URL、ファイルごとの権限だからって（え）にしちゃってるわ、、、どうなんだこれ

AI先生に全部読み込ませて答えさせてみてぇよ

NEだけどTLSハンドシェイクを暗記してる奴なんて見た事ないよ
現場でもググりながらログ見るぞ
IPAくん我々をどうしたいんだ

IPA「安全確保支援士ならTLSハンドシェイクの手順ぐらい暗記してて当然でしょ？」
こういうことっすか……？

TLS最初のClientHelloしかあってる自信ないわ
ひとつミスると芋づるで罰になりそうだからどこにくるかわからない選択肢を2箇所書いて片方当たれば無問題戦法してた

no.2同意

設問1
1 authorizationヘッダ見る
2 アプリ内にある鍵でアプリ内にあるアクセスキー復号
3 摂取したアクセスキー使って GET /e-service
4 www.a-sha.co.jp.k-sha.co.jp

設問2
1 www.a-sha.co.jp
2 無理！

設問3
え

設問4（わからん）
1 独自スキーム使ってるから
2 サーバ証明書検証

署名URLってファイル名わからんとパス作れないから（え）だと思ったけど
（う）の時点でもファイル名作れるしそもそもファイル名がストレージ上でも同じかどうかわからんのか？

設問4の2、サーバ証明書検証か。うーむ確かに。。。
そもそも、アプリを呼び出すF-URLにA社のFQDN以外が含まれてたら起動しない、みたいに書いたなぁ

この投稿は投稿者により削除されました。(2025.04.20 16:17)

ファイル名は注文番号.zipになるので注文番号を採番した後作れて、図5に「利用システムは、署名付きURLを生成し」とあるので、A社Webサーバが作るだろうということで（い）にしました。

アクセス先をA社Webサーバのみにする。みたいな感じの事を書きました

no.13の回答に近いかな。
設問3はファイル名が必要だから「え」にした。zip化したファイル名が必要だって判断で「う」じゃなくて「え」

でも全体的に見るとボロボロだわ……お前ら俺と一緒に傷の舐め合いしようや。とりあえず今日はお疲れ様。しっかり休もうな。

tlsハンドシェイクの簡易フローが見えたのでこの問3選びました。アクセスキー、ストレージ名、署名URLあたりの問題が怪しいなぁ

かなり難しかったです。
設問4
1
webviesでhtmlの内容をアプリ画面に出してるだけなのでアクセス先にユーザは気付かない的なことを書きました。

2
アクセス先がa社のFQDN以外は弾くのようなことを書きました。

TLSのところは全てわけわからず、最初の２つはclient hello とserver helloですかね？

設問1
(1)CサービスへのHTTPリクエストのAuthorizationヘッダー値を読み取って取得する。
(2)Fアプリをリバースエンジニアリングによって解析して暗号化されたアクセスキー、AES-CBCの共通鍵及び初期ベクトルを特定し、AES-CBCアルゴリズムによって復号化する。
(3)Cサービスのパス/e-service/nnnnnnnn(ただしnnnnnnnnは8桁の十進数)を総当たりしてGETリクエストを送ってダウンロードする。
(4)www.a-sha.co.jp:pass＠k-sha.co.jp
(www.a-sha.co.jp.k-sha.co.jp等でも良いかと)

設問2
(1)○○○. ○○○. ○○○. ○○○
(2)a: エ、b: ケ、c: ウ、d: コ、e: ア、f: イ、g: カ、h: キ
(3)通信解析ツールのCA証明書を信頼できるものとして登録しておき、生成されたサーバ証明書を正しく検証できる様にする。

設問3
(い)
(アクセスキーをFアプリ内に埋め込まない様にするのが目的の為、A社サーバー側で生成する必要があります。)

設問4
(1)アクセスしているURLが表示されない点。
(2)F-URLのurlパラメータに設定されたURLのアクセス先がA社Webサーバーである事を厳密に確認してから、そこにアクセスしてキャンペーンページのHTMLを取得する様にする機能。

TLSの穴埋めは
図9の左側にTLSハンドシェイクの範囲が書いてあったので、cをclient helloにしました

bは最後の方にもあったのでなんとなくfinished
となるとaは？？？

その他も不明

やっぱりaがclient helloなんでしょうか？

webブラウザと比べて、っていうヒント？あったから、
WEBブラウザ→サイトのurl出るからわかる
アプリ→urlでないからわからない
だと思って、アプリがurlでないのは独自スキームだからだ！（なんで？）で書いちゃいました
no.21さんの回答が正解に近い気がします

(2)はFQDNでの制御はスクリプトの修正でやるから…となると証明書みるくらいしかないか？（思考放棄）
わからーーん

zipファイル名は注文番号が決まれば決まってるから間違いなく(い)だね

ハンドシェイクはたぶんこれで間違いない
a:CONNECT www.a-sha.co.jp
b:HTTP 200
c:Client Hello
d:Server Hello
e:Certificate
f:Certificate Verefy
g:Finished
h:GET

設問2のTLSは以下にしました。
(1)www.a-sha.co.jp 
 (A社Webサーバに合わせないとドメイン名不一致のエラーになると思うので)
(2)オケウコアイカキ
(3)通信解析ツールのルートCA証明書を信頼させる(みたいなこと書いた気がする)

No.25
TLSフローのやつはそれで合ってると思う

署名URLの件、（え）なような気もするがなぁ。。。
わざわざ（う）と（え）の間に、ファイル名をFアプリで変えるような示唆がある中で、果たしてファイル名は（い）の段階で確定した、と言えるだろうかという疑問があるんだけど。。。

署名付きURLは利用システムで生成すると方式bの説明にあって、方式bの説明で利用システムと利用者は分けて書かれている
だから利用者=Fアプリ、利用システム=A社Webサーバ以外考えられなく、消去法で注文番号決まった後の(い)しかない

設問1 
（1）危たい化した鍵によるサーバ証明書を、使用していた場合、盗聴されたパケットを複合化する。
（2）Authorizationヘッダーがリクエストヘッダーに書かれているため、A社Webサーバーのアクセスログから確認する。
（3）Cサービスのアカウントはテナント管理権限を持っているため、各ユーザーのストレージやファイル名を確認してダウンロードする。

（4）www.a-sha co.jp.k-sha.co.jp
設問2
（1）○○○. ○○○. ○○○. ○○○
（2）a: オ、b: ケ、c: ウ、d: コ、e: ア、f: ク、g: イ、h: キ
設問3
（1）え
設問4
（1）サーバ証明書の検証を無視しているため、エラーが出ない。
（2） www.a-sha.co.jp及びstorage.c-sha.jpへアクセスする際にはサーバ証明書の検証を行う。

署名URLの件、No29さんのロジックもわかるんだよね。
私も最初そのロジックで（い）にしたから。
ただ、どうしても、ファイル名だけが引っかかり続けている。。。

スマホ内のオリジナルの画像ファイルは注文番号.jpgではないから、圧縮するときに注文番号.zipにしましょうね、ということだと思ってました。

落ちた気しかない。

ファイル名のくだりってどこに記載あるの？
図4中に明らかに注文番号で決まるように書かれている箇所しか見当たらないんだけど

あ、署名URLの件、（い）だわ。。
完全に今理解した

設問4(1)はFアプリの仕様上の問題点とあったので
仕様をそのままかきました。

私は「スマホアプリの画面の一部にＷｅｂページを表示する点」みたいな感じにしました。

ああ、本当だわ。
ファイル名のnnnnnnは注文番号なのか。完全に見落としてた。これは（い）やね。

良かった、みんなもTLS問題分からないのか。自分も試験中（なんで自分はこの問題を選んだのか、自分がわからねぇ）と半笑いで解いてたっす

1-1 httpリクのAuthヘッダー見る（盗聴する方法は聞かれてないからこれでいいのかな
1-2 暗号化されたアクセスキーをコード内の定数で復号化
1-3 /e-service/nnnnnnnn.zipにgetリクエスト
1-4 www.a-〜.k-〜/
2-1 ◯◯◯. ◯◯◯. ◯◯◯. ◯◯◯ （SANとかいう単語初見だけど、当てはまりそうなのがこれだけだった
2-2 オケエクアオエキ （ズレてるどころか少しも合ってる気がしない
2-3 解析ツールのIPをプロキシに設定（アプリの設定じゃなくてスマホの設定で弄れそうなのがこれしか思いつかん
3 お（署名を生成する利用サービスをcサービスだと思いこんでたけど、い、っぽいなぁ
4-1 URLが表示されない
4-2 URLパラを◻︎◻︎◻︎の指定に変更

gptに聞いたら署名urlの回答は（う）だそうです。

取得しなさい系が３つ出ると思ってなかった💦
かつ、、、クラッカー視点もいるってこと？笑笑
つまり、、、、クラッカーになるってこと！？🥲
深掘りにふかぼって、、撃沈！！！

浅はかでした。。。。
攻撃こそ、最大の防御ですか。。

全く関係ないんですが、すみません。
プロポーズするときの初めて出会ってご飯行った後のアイスの味聞かれてるみたいな気持ちになりました。
出直してきます。。

全然わかりませんでした・・・

問3
設問1
(1)偽のAPとサーバーを用意して、HTTPで通信させて、アクセスキーとストレージ名を盗み見る
(2)偽のAPとサーバーを用意して、GETリクエストのクエリストリングとヘッダーからアクセスキーとストレージ名を取得する
 →定数の件見逃してた・・・
(3)盗んだアクセスキーをヘッダーにセットし、盗んだストレージ名../といった親ディレクトリへの遷移を含めたパス名を指定する。
 →連番の件も見逃してた・・・
(4)w ww.a.～/campaign/□□□/redirect:k-sya.co.jp
 →適当

設問2
(1)a -sya.co.jp
 →A社サーバとのプロキシみたいなものかと思ったため
(2)
a:エ
b:ク
c:コ
d:ウ
e:ア
f:イ
g:カ
h:オ
→分からない・・・

(3)接続先のサーバ証明書が信頼できなくても通信する設定
→本番環境に影響が出るくらいならテストのときだけの設定と割り切る

設問3
い

設問4
(1)アクセスしているサイトのURLが見えない
(2)a-sya.co.jp以外のアクセス先へのリクエストが生成されたら破棄する

時間もなくて落ちた。何を言ってるのかわからない問題が多数。
でももしかしたら考える時間あったら回答できたものもあったかもしれないが、時間ないので特に後半意味不明な回答連発。。
わかるわけもないTLSハンドシェイクとかに時間かけるんじゃなかった（どうせ配点1点なのに。）
もう試験3回目。どうすれば午後対策できるのか謎。どうしたら受かるのこの試験。この問題で6割取れる人はどんな勉強をしているの？
そもそも問題選択ミス？(問4選んでも結局時間足りなそう、どちらにしても15点、運良くて20点が関の山)

(1)CサービスへのリクエストのヘッダーフィールドのAuthorizationの値より取得する。
(2)「Fアプリ内にある暗号化されたアクセスキー」および、定数としてある「Cサービスのストレージ名並びにAES-CBCの共通鍵及び初期ベクトル」から復号化して取得する。
(3) GET /e-service としてアクセスする 
(4)www.k-sha.co.jp 

設問2
(1)www.a-sha.co.jp 
(2)a: ウ、b: ケ、c: エ、d: コ、e: イ、f: カ、g: ク、h: キ
(3)通信解析ツールをテストの時のみ使用するように設定する。

設問3
(い)

設問4
(1)エラーとなっても通知がされない点。
(2)キャンペーンサイトをホワイトリスト化しておき、そのサイトのみアクセスできるようにする。

問1の(4)のURLについて、素直にwww.k-sha.co.jpと書き、
これで攻撃者がトークンを取得できるのか?と悩んでしまいましたが
先の方が回答されたような「www.a-sha co.jp.k-sha.co.jp」という方法があったとは…
言われると納得ですが、これは本番で思いつけないなぁ

www.a-sha.co.jp.k-sha.co.jp
あーなるほどサブドメインなんですね！
やっと理解しました。

回答できた方はご存じだったのでしょうか？
それとも問題見て試験中に思いついたのでしょうか？
…そういう方こそセキスペなんでしょうね。

設問1
(1) HTTPS通信を解読できるプロキシーを用意し、アプリからの通信を傍受する。通信に含まれるHTTPリクエストのAuthorizationヘッダーからアクセスキーを得る
(2) 端末からアプリのパッケージを入手し、解析する。アプリ内に含まれる暗号化されたアクセスキーと暗号化鍵、初期化ベクトルを用いてキーを復号する ((1)同様にプロキシーから見ることもできますが、別の脆弱性として認識されているので、こちらのほうが望ましいかなと思いました)
(3) ファイル名は連番で生成されるため推測が可能である。取得したアクセスキーを用いて、連番でファイル名を変更しながら全てのファイルに対してGETリクエストを行う
(4) www.a-sha.co.jpevil.com (jpが先頭に入っているドメインであれば、攻撃者が取得できるドメインなら何でもよい。.で繋げて別のドメインを用いることもできるはず)

設問2
(1) www.a-sha.co.jp
(2) オ、ケ、ウ、コ、ア、イ、カ、キ
(3) 通信解析ツールのプライベート認証局が用いるルート証明書を開発用のスマホにインストールし、信頼するよう設定する

設問3
(い)
注文番号を採番した段階で、アップロード先のファイル名は一意に決まるため署名付きURLの生成が可能。注文番号を通知するタイミングで、署名付きURLを一緒に渡せばよい。正確には (う) (え) でもタイミングとしては問題ないが、クライアント側の処理として記載されているうえ、注文番号の通知後だと、処理の流れ上サーバーからクライアントに通信するタイミングがないため、おそらく (い) で生成して注文番号ともに通知する想定だと思います。
Amazon S3やAzure Blob Storageを使ったモバイルアプリ向けの実装でよく利用するパターンとほぼ同じものだと思いました。

設問4
(1) WebViewではURLをすべて表示できない
(2) WebViewが開くURLを常にチェックし、キャンペーンサイトに用いるURL以外にアクセスできないようにする

すみません、 設問1(4) のドメインの制約を読み飛ばしていたことに気づきました…
www.a-sha.co.jp.k-sha.co.jp ですね。

設問1
（1）盗聴したHTTPリクエストのヘッダフィールドからアクセスキーを、リクエストラインからストレージ名を取得する。
（2）Fアプリに保存されたリソースからAES-CBC暗号化されたアクセスキーを抽出し、アプリ内で定義された共通鍵と初期ベクトルを用いて復号する。
（3）ストレージ名e-serviceと連番ファイル名を用いて、HTTPのGETリクエストを繰り返し送信する。

設問2
（1）www.a-sha.co.jp
（2）
a）エ
b）ケ
c）ウ
d）コ
e）ア
f）イ
g）カ
h）キ

（3）通信解析ツールが生成するプライベートCAのルート証明書を、スマホに信頼済みCAとしてインストールする。
設問3
い
設問4
（1）F-URLの正当性を確認しないこと。
（2）F-URLのリンク先が正規のドメインであるかを検証する機能。

設問1（4）は空欄。
多分他の方が記載している「www.a-sha.co.jp.k-sha.co.jp」が正答でしょうね。

これどうでしょうか

1(1)
偽サイト(偽URL)に誘導して、HTTPリクエストをさせる

1(3)
HTTPのGETメソッドでアクセスキーを指定して、ストレージ名とファイル名でパスを指定してアクセスを繰り返す
※繰り返すのがポイントかと

2(3)
プロキシサーバのサーバ証明書を信頼する証明書として登録する
※通信解析ツールとすべきでした

4(1)
サーバ証明書の検証エラーを無視すること
※これでと辻褄はあうような？

www.a-sha.co.jp.k-sha.co.jp
知ってたらまぁって感じですが、本番でこの回答を思いついたら天才すぎる...
サブドメインって言われたら納得なんですがサブドメインに.とか文字列として使えるのか？とか邪念が湧きそう...

「URLの例」とあるので「～.k-sha.co.jp/index.html」と解答したんですがダメそうですかね？

んー、むしろサブドメインの問題ってそんな知識って存在するもんですかね
自分の場合は全然過去問出来てないこともあって、知識を思い出すというよりその場で創作する意識が強かったというのが大きいかも（実際試験中、サブドメインってこういうフォーマットだっけ？？？とはなりました）

前回R6秋期合格して４月から登録したものやけど難しくなってるね。でもとりあえず設問1-1は間違えてる人多いよ。これは「サーバ証明書の検証に不備がある」つまりはクライアント側であるアプリ側がちょっといけてないって話で正規のサーバに接続していなくとも通信を継続してしまうってことやで。では盗聴するためにはどうするか？正規ではない偽サーバを自前で用意してアクセスキーを採取するが◯やで。検証に不備があっても正規のサーバとの通信（つまり検証成功した通信）は盗聴なんてできへんよ。

＜完全解答＞
偽サーバに誘導してアクセスキーを採取する

設問1（4）は「www.a-sha.co.jp.k-sha.co.jp」ですか・・・
なるほど言われてみればって感じだけどどうしてもdその場で思いつかなかったorz

設問1-1は

「利用者を攻撃者が作成した偽のEサービスサイトへ誘導し、通信内容を盗聴する」

って書きました。ここだけは過去問チックに感じたので・・・

設問１−４見てみるわ

解答用紙で設問1は（1）が2行で（2）（3）が3行なのが気になった。（1）の枠が足りなくなった。

下線①に、「盗聴した内容から」と記載があるにも関わらず、盗聴なんてできないから偽サイトに・・・、という思考をする必要がある、ということです・・・？
盗聴する方法を聞かれている、のではなく、
盗聴した内容からどう抜き取るか、を聞かれているようにみえますが。。

これは図８そのままなんやけど、F-URLは
「f-app://campaign?url=えいちてーてーぴーえす://A社/campaign/＊＊＊」
注記２から＊＊＊がURLパスやから
「f-app://campaign?url=えいちてーてーぴーえす://A社/campaign/英知テーテーP.S.://K社/」
が正解やで。www.a-sha.co.jp.k-sha.co.jpってなんやねん笑
えいちてーてーぴーえすって書かないと書き込めんかったわ

検証成功したHTTPSの盗聴なんて不可能やで。これは大前提。米軍とかならできるんか笑。

下線①は「盗聴した内容から・・・」だから、盗聴した前提なんやで。

日本語の問題と言われた昔のままですね。

解答用紙に「https://」て書いてあるからね。そら、www.～と続けるでしょ。

なるほどな。A社の通信をマジカルパワーで盗聴できた前提なんか。解答用紙のhttps://〜って書いてるのは公開された問題しか見てないからわからんかったわ。ごめんな

そもそも、問題文は「F-URLのurlクエリパラメータに、④（細工したURL）が指定される・・・」

答えるべきはurlクエリパラメータの値であり、F-URLの例ではないです。

設問2(1)はwww.a-sha.co.jpでいいんですかね

解答用紙にhttps://
まで書いてあってそれならK社ドメインやね！ごめんねぇ

私が持ち帰った問題冊子とIPAが公開した問題の内容が異なるなら、「F-URLのurlクエリパラメータに、④（細工したURL）が指定される・・・」も公開されないかもしれないですね。。。。

何がとは言いませんけど皆さんお優しいですね

シーケンスの問題、なんかネスペの過去問に似た図があるみたいです
試験全体で有識者がURL貼ってくれてました

設問2-1は丸々やで。解析サーバのまるまるや。zscalerとか使ってたらわかるけど検証済みのHTTPSや解読不可やからどうしても中間に入りたい場合は中間で一旦暗号複合化を解いて解いた中間が代わりにリクエストするんやで

zscalerごしでgoogleアクセスして証明書確認してみ。zscalerの証明書やから

そもそも他人の解析サーバなるものが、なりすましA社の証明書発行できたらやばいやんw

>む！さん(No.67) 
すみません、こっちに書けばよかったですね。全体のスレッドの流れが早すぎて追うのがつらいですね。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000009sgk-att/2022r04h_nw_pm2_qs.pdf
P8図3とかです

No.65
なんか的外れな回答してるからちゃんと問題解いてから書き込んだ方が良いよ

いろいろミスってますね...

 (1) FアプリとCサーバの通信を中継して、HTTPリクエストのAuthorizationヘッダーからアクセスキーを取得する
 (2) Fアプリ内のリソースとして保存されているアクセスキーを取得したのち、Fアプリのコード中に定数として定義されているAES-CBC共通鍵および初期ベクトルを用いて復号してアクセスキーを取得する
 (3) URLのパスに取得したストレージメイト”nnnnnnnn.zip”の注文番号の全ての組み合わせのファイル名を指定してGETメソッドでCサービスからダウンロードする
 (4) www.a-sha..co.jp.k-sha.co.jp

設問2
(1)www.a-sha..co.jp
(2) 
a. エ b. ケ c. ウ d. コ
e. ア f. イ g. カ h. キ
 (3) 覚えていない

設問3
 i. (い)

設問4
 (1) URLの先頭のみチェックするという問題 17文字
 (2)覚えていない

設問１（１）は中間者攻撃する（大意）と書きましたが、
「盗取した内容から～取得するおそれ」に対して取得する方法を具体的に、なので違いましたね。。。

設問４（１）はFアプリ上で表示されることが問題点と考えました。
webブラウザならともかく、正規のアプリが起動しているのにフィッシングサイトが表示されていると利用者が気づくのは無理かなと。
（２）は修正したgetTokenで正しいURLと検証するまでHTMLを表示しないと書きましたが、webviewはそんな操作が可能なのだろうか。

URLの先頭がｗｗｗ.a-sha.co.jpかどうかを調べるのは、転送先のurlではなくて、転送先urlに飛ばされたあとのgetTokeの呼び出し元urlなので、すでに転送されてしまった状態では関係ないんでないかな

~~/campaign/□□□

の□□□の注記にurlパスと書いてあったので、これを素直に信じればよかったけど、□□□は、campaign配下の相対パスで、一般的には転送先urlをurl=えっちててぺｓ://k-shaのように直接指定するのが普通ではと思って、前者を書き直して、えちててぺｓ://k-sha.co.jpと回答してしまった。
問題文からは前者がツッコミどころがない正解な気がするけど。。。

設問2(2)の配点がどれくらいかな
全滅だからこれ次第になりそう

この投稿は投稿者により削除されました。(2025.04.21 01:23)

設問4の(2)ってURLの検証っぽくも思えるんだけど、発端としてそれが上手くいかない場合があるから何か別の手段じゃないのかなぁとも思いました。

・URLを検証する機能が必要と考えて図７のフローを実装してみたが、検証方法として不十分だった。
・設問4(2)は、上記を解消する方法を「具体的に答えよ」
→「URLを検証する」だけだと具体的でないのでNGで、図７よりリッチな検証方法を具体的に書くことを求められているんですかね？
だとしても何が適当かは分かりませんが。

>おねまえさん(No.79) 
問題文を見ると、「図７の修正に加えて、⑧フィッシングサイトにアクセスできない機能」とあるので、図７とは異なるURL検証方法（＝図７の修正）以外の方法を問われていそうですね。

設問2の(1)はツールのIPじゃないかな？この時点だとツールが作ったオレオレ証明書？なのでは。だから、エラーが出る。
aドメインのは図の右下のツールとa社webサーバとのハンドシェイク時に使われる証明書と思ったけど違うかな。

ハンドシェイクのところ、クライアントハローしか合ってないやんけ。。。
終わった。。。

2-1って以下のページ（2.復号機能を持つプロキシサーバ）と同じ話だと思ってwww.a-sha〜にしたんですけど違いますかね
://nw.seeeko.com/archives/proxyserver

SANって複数のドメインもしくはIPを設定できる的なやつだから、ドメインとIP、ドメインだけ、IPだけの3パターンの解答がありそう…？
自分はドメイン書いたけど、確か◯で表されてるIPもあったよな
あれも答えになるんかな

2の(1)はサーバのドメインが正解か。。IPじゃなさそうですね。。つらい。

設問１の４番の、加工されたURLって
a-sha.co.jp/campaign/k-sha.co.jp
は間違いですかね…？

初学者過ぎてみなさまのお話についていけず…

すみません
TLS通信の流れを書かせる問題って全くわからなかったんですが常識なんですか？
かなり自信を無くしました

1-4はK社のサブドメインとして誘導させないとダメやから
a-sha.co.jp.k-sha.co.jp
が正解やね

4-1はWEBブラウザと比べてとなると、
利用者がドメイン名を確認できない問題
とかになるのかな？？

TLSの流れはネスペでも割と出るので支援士なら尚更把握しておくところかなと思いました
TLS1.2と1.3の違いでどこから暗号化されるのかの違いとかは割と知ってる扱いなのかなと
とは言え支援士は受験者のバックグラウンドも多彩だし試験範囲広いから大変ですよね

盗聴の話が出ているけど、プロキシサーバなどの盗聴してからの転送は証明書エラーがでてhttpsでも暗号化されないから盗聴できるという旨の記載をするのかと思いしたが、違うのでしょうか。

問3は最初の質問みてhttps盗聴しても暗号化されてるやん、無理無理で問3は回避したけど、盗聴した内容を量子コンピュータ使って暗号を解除して、ヘッダーの中からアクセスキーを取得するって書いたらどうだったか。
終わってからもう一度問題読み直したら、通信解析サーバを間にたててそこを経由させてアクセスさせる図、tlsハンドシェイクのやつがあった。
通信解析サーバがサーバ証明書を送ってたので、よくよく考えたら盗聴も同じようなやり方をしたら、復号可能。そう考えたら、ところどころにヒントはあったんかな。

> めるとこさん(No.84)
> SANって複数のドメインもしくはIPを設定できる的なやつだから
複数設定できるのは確かですが、「複数設定するために」あるわけではありません。なので、複数パターン解答があるというのは、今回考える必要はないでしょう。
ただ、複数のデータ種を設定できる項目なのは確かなので、裸の www.a-sha.co.jp じゃなくて DNS:www.a-sha.co.jp じゃないと不十分では? という意見はありうると思います。そんな細かい採点はしないと思いますが。
※ツールで見ると "DNS:ドメイン名" だけど、規格的な表現は "dNSName" じゃね? とか、言い出すとキリがないし

No.93
うぐっ…ガチで細かいとこまで書くとなるとそうなるんですね…知らなんだ…
勉強になります
合格怪しいし、次回はそのレベルまで突っ込まれるぞ！って気で勉強していきます…今回の感じが今後も続くなら、そのぐらいがちょうど良さそうだし

フィッシングでURLにBasic認証のIDとパスワードを埋め込む構文を悪用したものがあるらしくてこれだ！！と思ったけど書き方思い出せなくてあかんかった…

設問4-2
getTokenの呼び出しもとは www.a-sha.co.jp から始まるかをチェックされるけど、攻撃者のwebページへ誘導するだけなら hｔｔps://k-sha.co.jp でも良くないですかね？

この投稿は投稿者により削除されました。(2025.04.22 22:47)

> なーあさん (No.96)
> 攻撃者のwebページへ誘導するだけなら
※設問1-(4)ですよね?
表中の解説が「だけ」を意図してない可能性がそれなりにあるので、正答にならないか減点になるリスクはあるかなと思います。「また、攻撃者が…」の「また」の意図次第ですね。結局は公式な解答待ちになるかと思います。
そこは曖昧じゃないのとも思いますが、F-URL関連の不備として挙げた項目で「トークン取得のおそれ」を挙げている以上、「トークン取得につながるような細工」を期待されていたとしても、不当とは言い辛いのではないかな、と。

設問１ー（４）
問題文は「攻撃者のWebサイトにアクセスさせることができるように細工したURLの例」やからな。k-sha.co.jpだけでも正解じゃないとおかしい。

設問1-(4)
k-sha.co.jpにアクセスさせる且つgetToken関数を発動させる方法を求められていると思っていた。。結果、a-sha.co.jpのキャンペーンページとk-sha.co.jpのどっちにもアクセスさせるURLを考えていたら世にも不思議なURLに仕上がりました（未だに正解がわからない）
次回はゆっくり問題文を読む時間を確保できるようにがんばります。

iTecの解答速報出たけどやっぱ設問3が（い）なのは納得できない。署名付きURLはファイル操作を許可するものだし、あのフロー変えないならファイル操作はFアプリがするものだし、そうなると（え）な気がするけど。

>生きたいさん (No.101)
>設問3が（い）なのは納得できない
いえ、アプリが署名を作るとなると「アプリは任意の署名を作れるだけの情報を握ってる」ということになるので、問題の解決にならないのですよ。なのでWebサーバ側で署名を作るのは絶対です。
で、実際のファイル操作を行うのがアプリだったとしても、そのファイル名はWebサーバ側でわかっています。なぜなら、Webサーバで採番した番号から一定のルールで決めているからです。だから、Webサーバで署名を作ることは十分可能です。
蛇足ながら、この方式変更によって、フローにある「注文番号を通知」は「注文番号と署名付きURLを通知」に通知内容を拡大することになります。問題ではそこまで話を進めてないですが。

署名付きURLをWEBサーバーで生成してスマホに渡して経由させてサービスに送るんですね。考えてみればトークンとかもそうですね。有り難うございます、秋に活かします。

itec.co.jp/wp-content/uploads/shiken/2025s/2025h_sc_pm_kaito_n.pdf

アイテックの回答速報出てますね。
設問2(1) 
www.a-sha.co.jp
設問3
(い)
みたいですが、信頼してよいのでしょうか？
ここの掲示板に乗せられていた回答とも結構異なりますね

ちなみにTACは:16：30公開予定のようです。(TACはおそらく予想配点あり)

TACも同様でしたね。
ChatGPTに推論モードで採点してもらった所26点でした（甘々採点な気がしますが）
トータルで61点！受かったことにしておきます！

設問１ー（４）
は問題文が攻撃者のWebサイトにアクセスさせることができるように細工したURL
なんだからk-sha.co.jpで十分条件でしょ。これバツなら問題文がおかしい。抗議レベル。

なんでこんなに解釈が分かれる問題を作るんだろうなぁ…。
結局国語の問題なんすね。

以下、Gemini先生の考え方。

設問1(4)が、getToken関数を欺く方法まで含めて問われているのか、あるいはシンプルに利用者を攻撃者のURLに誘導する方法のみを聞かれているのか、どちらだと考えるかですね。

私の考えでは、設問1(4)は、**シンプルに利用者を攻撃者のURLに誘導する方法**を聞いている可能性が高いです。

理由は以下の通りです。

1.  **設問の問いかけが「細工したURLの例」であること:**
    設問は具体的に「攻撃者のWebサイトにアクセスさせることができるように細工したURLの例」を求めています。これは、どのようなURLを作成すれば、ユーザーを攻撃者のサイトに誘導できるか、という点に焦点を当てた問いです。

2.  **下線④の文脈:**
    下線④を含む表1の解説では、「④細工したURLが指定されることによって、攻撃者のWebサイトにアクセスしてしまうおそれがある。**その結果**、攻撃者が会員の認証トークンを取得するおそれがある。(③)」と述べられています。
    ここで、「その結果」という言葉が使われていることから、攻撃者のWebサイトへのアクセス（下線④の結果）と認証トークンの取得（下線③）は、原因と結果の関係にあることが示唆されます。つまり、まず細工したURLによって攻撃者のサイトへ誘導され、**その後に**攻撃者のサイト上のスクリプトなどがgetToken関数を呼び出すなどして認証トークンを取得しようとすると考えられます。

3.  **getToken関数のチェックは、トークン「取得」の防御:**
    図7のgetToken関数の処理は、WebViewの呼び出し元URLを確認することで、認証トークンが安易に盗まれることを防ぐための防御策です。しかし、設問1(4)が問うているのは、そもそもユーザーを「攻撃者のWebサイトにアクセスさせる」ためのURLの例です。getToken関数のチェックをどう欺くかは、アクセス後の「認証トークンの取得」の段階に関わる問題であり、アクセスそのものを引き起こす「細工したURL」の例とは直接の問いが異なると考えられます。

これらの理由から、設問1(4)は、ユーザーを攻撃者のサイトに誘導するために、F-URLのパラメータにどのようなURLを指定すればよいか、という点を聞いており、getToken関数を欺く具体的な手法まで含めて問われている可能性は低いと判断します。

したがって、シンプルに攻撃者のドメイン名やそのドメイン上のページのURLをF-URLに含める方法を示すことが、この設問で求められている解答であると考えます。

---

この考えに基づくと、前回の解答（設問1(4): www.k-sha.co.jp）は、攻撃者がユーザーを誘導したい先のドメイン名を示す例として適切であると言えます。

↑ の方、おっしゃりたい意は何となくわかります。

認証周りは秋のネスペで注目してたので出るかなぁ、と予想してざっくりおさらいしてたのですが、もう速報と全然一致してないので落ち込んでます。

たぶんサブドメインテイクオーバーを問いたかったのではないかな？
自信があるのは最後の問だけ、
パスキー導入してMITMを不可にする
と回答した方、他に誰もいない？いないですか？泣