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

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

1と2しか解けるやつなかったから選んだけどきっと爆死ですね…
2で稼げたらいけるかなって感じ…

わかる。1と2しか解けるやつなかった..

この投稿は投稿者により削除されました。(2024.04.21 15:41)

答案メモ（自信なし）

問1
ステートレス
100
ヘッダとペイロード改ざん
なりすまし
mid デバイス情報
サービスM
再試行不可
GETの値
PUTの値
¥W[n|N][j|J][i|I][d|D]¥W
継続
定期確認

問2
公開サーバ、プロキシサーバ  対象
誤検知
F
K
_
_
ネットから切り離し
ポートスキャン
ハッシュから逆タン困難
制限
社外からアクセス不可

模範解答と比較用に自分の解答の書き留め
一部間違ってる自信あり。
設問1ステートレス
設問2
(1)100
(2)
データ:JWT内のヘッダに指定されたアルゴリズム
内容:値にNONEが指定されていないか
(3)PUTメソッドのリクエストを受信した際に認証APIを利用して利用者を認証する処理
(4)共通モジュールP
(5)文字列を一定回数検証失敗した場合にアカウントロックする処理
設問3
(1)SシステムからLDAPリクエストWを受信したことを確認する仕組み
(2)
e.Header
f.Header
(3)¥W[jJ][nN][dD][iI]¥W
(4)
利点:正常な通信を遮断しないことで可能性が保たれること
内容:定期的に不正なログの記録がないか確認すること

header2連続で発狂しそうになってたけど同じ回答ニキいていまとても安心した

header2連続で発狂しそうになってたけど同じ回答ニキいていまとても安心した
わたしもです

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

設問2の1は四捨五入云々書いてあったから(1+100)/2から51って書いた

IPAは令和3年春期午後1問1設問2の(2)で実際に同じ解答とかいうふざけた真似しやがってるんで嫌いです。

設問3-4に誤字ですね。
可能性→可用性

パターンのやつ(j|J)で並べたんだけど、[jJ]じゃないとダメじゃろか、、、

>いたつさん
AまたはBで文字種指定すれば、AかBのいずれかを含むからどっちでも正解だと思う

設問2の1
自分は50って書きました
10回/秒で全部で10^4＝10000パターンなので、
(0.1秒(1回目で当たる場合)+1000秒(10000回目で当たる場合))/2=500.05秒
四捨五入して500秒です

設問2の1
自分も同じ考えで回答しました
500で

>自分は50って書きました
>四捨五入して500秒です
どっちやねん

桁読み間違えてた、、


>ほむほむ
1秒間で10回試行としか書かれてないから直列か並列かわからない
つまり1回目は確実に1秒かかると思う
そうなると(1+1000)/2で501かも
10分以内っていう制限にも収まりがいいし

1000個のうち、1sで通過するものが10個、2sで通過するものが10個...となるから、
10(1+2+...+100)/1000=50.5で51にした

0000〜9999までの10000個では…？

うーん落ちたな
この大問多分3割も取れてねえ(ToT)

>> (3)¥W[jJ][nN][dD][iI]¥W
これって(j|J)でも大丈夫なやつですよね…？

↑すでに大丈夫とコメントありましたね
失礼しました

自分もメモとして残します

設問1ステートレス
設問2
(1)1000
(2)
データ:ヘッダに指定されたアルゴリズム
内容:有効なアルゴリズムであることの確認
(3)JWTに含まれる利用者IDと一致していることのチェック処理
(4)サービスM
(5)一定期間で一定回数認証失敗した場合のアカウントロック
設問3
(1)SシステムからURL-Jにアクセスがあった際に通知する仕組み
(2)
e.Header
f.Header
(3)¥W[j|J][n|N][d|D][i|I]¥W
(4)
利点:遮断され得る正常なリクエストを事前に検知できる
内容:正常なリクエストが検知されていないことの確認

同じく500で解答しました。。
・4桁の数字の組み合わせは0〜9の10通り×4乗で10,000通り。
・1秒で10回トライできる→0.1秒で1回トライできる。
・パスワード探索にかかる最大時間は10,000通り目の1000秒
・パスワード探索にかかる最小時間は1通り目の0.1秒
・最大と最小の中間として500.05?
上記により500かなと。。

最初の問題って、オープンAPIと記載したのだが、、なんか他の会社からも叩きたいAPIかと思って。。この手のやつはビタで当てないと点数入らないのかな😭

設問1ステートレス
設問2
(1)500
(2)
データ:ヘッダに指定されたアルゴリズム
内容:システムが発行したアルゴリズムとの一致
(3)HTTPヘッダの内容が利用者ステータスと一致すること
(4)サービスL
(5)同一IDで連続認証失敗した場合のアカウントロック処理
設問3
(1)テストサーバの通信ログを取得する
(2)
e.Header
f.GET
(3)¥W(j|J)(n|N)(d|D)(i|I)¥W
(4)
利点:Waf追加前と同等の可用性維持
内容:管理者アラート受信後のインシデント対応手順書の策定

設問1ステートレス
設問2
(1)500
(2)
データ:JWTのヘッダに記載されているalgの値
内容:指定した文字列になっているか
(3)midがJWTの利用者IDと一致している場合にのみPを呼び出す
(4)サービスL
(5)同一IDで認証回数がしきい値を超えたら認証失敗とする
設問3
(1)SシステムからテストサーバへのHTTPリクエストがあったかどうか
(2)
e.ANY
f.Multipart
(3)¥W[jJ][nN][dD][iI]¥W
(4)
利点:パターンに当てはまる通常の通信を正常に処理できる
内容:アラートを受信した際のログの確認方法と対応手法を確立する

細かいことだと思うのですが[]と()で処理が変わってくるのでパイプで繋ぐ場合()←にしないと不正解だと思います。

設問1ステートレスをセッションステートレスって書いたらNGでしょうか？

この投稿は投稿者により削除されました。(2024.04.21 18:42)

【問１】
設問1ステートレス

設問2
(1)500
(2)
データ:ヘッダとペイロードに対する署名
内容:ヘッダとペイロードが改ざんされていないかの検証
(3)パラメータにotpを追加し、otpの検証を行う処理
(4)サービスL
(5)同一利用者IDの連続ログイン失敗にアカウントロック機能

設問3
(1)テストサーバーにJファイルが作成されダウンロードされたか確認する機能
(2)
e.Header
f.ANY
(3)¥W[jJ][nN][dD][iI]¥W
(4)
利点:WAFの誤検知による通信遮断を防ぐことができる
内容:アラートを受けたらすぐに攻撃ではないかを確認する


全く自信ありません・・・

設問1  セッションレス

設問2
(1)  500
(2)  データ:ヘッダに記載されたアルゴリズム
内容:アルゴリズムが"RS256"になっているか
(3)  GETメソッド使用時、利用者IDだけでなく名前や年齢の入力も必須とする。
(4)  共通モジュールP
(5)  認証成功までに可能な文字列Xの検証の試行回数の制限

設問3
(1)  検証コードのコマンドCが実行されたことを確かめるアクセスログの収集機能
(2)  e.ANY    f.ANY
（↑両方ANYにしておけばどっちかは当たるだろう...と思っていました。）
(3)  ¥W(j|J)(n|N)(d|D)(i|I)¥W
(4)  利点:正規の通信が遮断されることを防ぐことができる。
内容:不信なログが記録されたら迅速に遮断する。

ボロボロっぽい。

**設問1**
ステートレス

**設問2**
(1) 500
(2)
 対象.JWTのデコード結果のヘッダの”alg”
 内容.値が”RS256”以外になっていないか
(3) 利用者APIのmidの値と、JWTのデコード結果の利用者IDの一致を検証する
(4) サービスM
(5) 認証失敗回数をカウントして、しきい値を超えた場合はロックする

**設問3**
(1) Sシステムからa2.b2.c2.d2.へWGETを検知する仕組み
(2)
 e.Header
 f.Header
(3) \W(J|j)(N|n)(D|d)(I|i)\W
(4)
 利点.誤検知が発生した場合でも利用者にサービス影響がない
 内容.アラートが送信された場合を想定して対応手順を作成

対戦お願いします

一応書いておくとリクエストラインとヘッダー(Header)は別物ですよ

この投稿は投稿者により削除されました。(2024.04.21 20:51)

パターンのやつ¥Wj|Jn|N〜略  といった形でもokでしょうか...

自分も37さんと同じように書いたけど多分ダメだと思う
()が必要かと思います

>37 パターンのやつ¥Wj|Jn|N〜略  といった形でもokでしょうか...

私もこのように記述しました。図5の正規表現ルールを参照するならこれでもよさそうなものですがダメなんでしょうかね

>おわたかもさん
すでに承知かと思いますが、４文字の保証がどこでとれるかという問題が発生するのでNGかと思われます。

いくら読んでも（）つけるのとつけないの違いはない気がするのですが、だれか解説頼む

総当たりも可

設問3(3)はjndiだけじゃなくてldapも書かないといけないんじゃないかって思ったのですが…。
解答欄も広かった気がします。

この投稿は投稿者により削除されました。(2024.04.22 09:02)

自分もLDAPも書きました。[ ]にしてしまったから自信ないけど。

たろうさん

問題文に「表6中のルール1に記述すべきパターンを…」と書いてあるので、表6のルール2に該当するldapは記述しなさそうです。

失礼しました。しっかり設問を読んでませんでした。

通りすがり様へ

正規表現は久々なので自信はありませんが、同じことができる筈。
ただ[ ]の時、数でなく文字を指定する場合｜（パイプライン）が必要。
つまり、

(j|J)(n|N)(d|D)(i|I)   正解
[j|J][n|N][d|D][i|I]    正解

正規表現のBREとEREを理解しているかが問われたようです。
BRE：基本正規表現（古くからの正規表現）
ERE：拡張正規表現（新しい正規表現）

[]:文字クラス BRE、EREどちらでも使用可能
[]内の1文字を表す（文字列は書けません）
[abc] -> a or b or c

(|):文字列選択 EREのみで使用可能
|で区切った文字列を選択する
(abc|def) -> abc or def

図5の文字列選択の例で
「(x|y)z 」とあったため、xとyは1文字でなければいけないと
ミスリードした方が多かったのかもしれません。
ですが、この設問では1文字づつ指定するので、結果として同じになります。

又、文字クラスで誤って"|"を記述すると
[j|J] -> j or J or |
と"|"も含まれてしまいます。これはNGです。

以上を踏まえると解答は以下の2パターンのどちらでもよいと思われます。
¥W[jJ][nN][dD][iI]¥W
¥W(j|J)(n|N)(d|D)(i|I)¥W
また以下でもパターンとしては成立しています。
¥W(jndi|jndI|jnDi|jnDI|jNdi|jNdI|jNDi|jNDI|Jndi|JndI|JnDi|JnDI|JNdi|JNdI|JNDi|JNDI)¥W

もし実際の運用で採用するのであれば、以下のパターンが最適解です。
¥W[jJ][nN][dD][iI]¥W

pix様へ

ご指摘ありがとうございました。やはり自分が間違ってましたね。

pixさん

解答例ありがとうございます。
解答が複数ありそうだとは思っていましたが、
回答欄が文字数制限なしで広く取られていた理由がやっとわかりました。
無駄に広いなぁとは思っていたんですよ。
出題者は第3の解答例を書く人を想定していたんですね。

・・・採点者大変そうですねｗ

No46 Matsurikaさん

>問題文に「表6中のルール1に記述すべきパターンを…」と書いてある

ご指摘の通りでした。
両方書いちゃった～部分点もらえないかな～

これで59点とかだったら相当へこみます。

総当たり攻撃の計算式あるみたいです。
問題の平均時間を求めると5秒だそうです。
パスワードが何通りあるかを計算し、その半分の数を1000で割った秒数が平均時間になります。
(10000/2)/1000=5
が正解みたいです。(誰がわかんねん)

①ライブラリQを修正する（下線あり）、設問２（２）関連ですが、
具体的にどこを修正したか考えてみました。

試験中にも「あれ？」と思ったのですが、試験問題５Pの上から１１行目に

「Bearer スキーム」

とあります。
これがヒントじゃないかと考え、調べてみたら検証なしにトークンを渡し、PoPトークンのように所有者確認をきちんと行わない仕様のようです。
簡単に例えると
前者は「道に落ちていた切符を拾った人間が勝手に使って電車に乗れてしまう」
後者は「飛行機の搭乗チケットのように名前が記載されておりパスポートで確認も必須」
ほどの違いがあるそうです。
ライブラリQはここを修正し、NONEをブロックしたのではないかと。

ご意見、ご指摘があればよろしくお願いいたします。ペコリ

2-4の回答いまのとこここで出てる解答だと、サービスLとサービスMが同数で次いで共通モジュールPですけど、どれが正しいのがよく読み返しても分からず、、、
自分はサービスLにしたんですが、自信のある方いますかね？

2-4は、表２の利用者APIの解説から、呼び出し階層としてL->P->Mになっているので
[c]に送信していた～
という文面から考えて、Lではないと思います。
Pはあまり説明がなく、実質的に土管として更新してしまう末端のMかなと思いました。
、

普段アプリ開発やってるのに、ステートレスなんて語彙出てこなかったからみなさんはすごい

2-4は、「[c]に送信していた・・・」という文面の「送信」という単語から、通信が発生する観点でサービスのどれかだろうかと思いました。
かつ「指定されたパラメーターを検証せず」という文面から、検証するのはサービスL（が呼び出す共通モジュールP）が妥当かなと思い、サービスMだと最初は思いました。

ただ2つ目の文章で「[c]は利用者ステータスを変更できる」という文面から、サービスMってデータベースだよな？データベースはSQL文を受け取って処理を行う受動的なものだから、データベースが「できる(又はできない)」って能動的な表現は文章的におかしくない？？？と思い、めちゃくちゃ悩みつつサービスLに変更してしまいました・・・。

多分サービスMが正解なんだろうなと思ってます・・・

問1は結構答え割れてて安心しました。
出来が悪いのは目に見えてるので、大問ごとの得点調整に期待してます。

絶望さん
全く同意見でした。

うわーーーーん😭😭

サービスＬが答えでは？

サービスＫからサービスＬに送信
サービスＫからリクエストを送信すると、サービスＬは利用者ステータスを更新できる。

サービスＫと入れたらわかりやすいかしらん？

サービスKと書いてしまったのですが、
サービスMに見えませんかね。

表2から選べというのを見てなかった。

モジュールP  にしました。

なんとなく「ここで、送信内容を改ざんしてパラメーターstatusを追加して」と７pにあるので、
改ざんできそうなのは呼び出せるモジュールくらいしか思いつかなかった。
完全にカンです。自信ありません。

正解がサービスLだったらめちゃくちゃうれしいなぁ。

「指定されたパラメーターを検証せず」の部分が共通モジュールPではなくサービスK（APIゲートウェイ）なんだろうかと考えた部分もあり、回答をサービスMからサービスLへ変更したもののいかんせん自信がなく・・・

このあたり詳しい方いたら教えてほしい・・・

＝＝＝＝＝＝＝＝＝＝
あいすさん
ありがとうございます！

表２からPUTメソッドでのみ利用者情報を更新できるから、ここを改ざん。
もしBFLA的な脆弱性があるならば、動的メソッドが送れる共通パラメータ、
BOLA的な脆弱性があるならば、サービスLもサービスMもありかと。
ただ仕様が全然わからないし、コード例も無しなので推理とカンだけで判断。

そもそもサービスM入れさせる問題だったらわざわざ穴埋めにするかな
入口で上位のところ、つまりサービスKで検証しとけって話だろ

図3で「サービスKはそのリクエスト内容に基づき」
とあり問題文では
「追加してリクエストすると」
とあるので、サービスKに対するリクエストのことで、
サービスKが未検証のままサービスＬに送信するので、サービスLのせいで利用者ステータスが更新される

という話？

IPA公式回答がでるまで何とも言えませんが、サービスLの可能性も割とありそうですね・・・

ちなみに設問2-(2)についても疑問があり・・・

問題では「algがnoneに変更され、userの値を別の利用者に変更した」旨の文が記載されており、試験後に調べたらalg:none攻撃というものの情報が出てきて、そのことなんだろうなと思いました。

そしてその対策としては、やはりalgの値をチェックする系っぽいので、皆さんの以下のような回答が正解なんだろうなと思いました。
 対象：ヘッダの"alg"の値
 内容：値がシステム側で指定した値になっているか


ちなみに私は以下回答をしました。
データ:ヘッダとペイロードに対する署名
内容:ヘッダとペイロードが改ざんされていないかの検証

でここで疑問があります。
問題に「署名は削除した」もしくは「署名を改ざんした」といった旨の記載があれば、私の回答は×かなと思います。
ただ問題文にはそういった記述がなく、「署名が削除・改ざんされずにそのまま残っている」なら、algが改ざんされていても、とにかく署名検証さえすれば必ず検証は失敗し、改ざんを検知できると思うので、私の回答でも対策になるのでは？？？
設問の考慮不足で別解の可能性もありうるか？？？と思いました。

皆さん、ご自身が正解である可能性が高い設問にはあまり興味は湧かないと思うのですが、もし上記内容について、ご意見いただける方いたら教えていただけると嬉しいです。

4-2、共通モジュールPだと思いますよ。

サービスKは表2に無いので論外。

サービスMもただのマネージドDBなので「(c)は利用者ステータスを変更出来る」の記述がおかしい。
実際にステータス変更の処理があるのはサービスLの中です。

さらに、「指定されたパラメータを検証せず全て(c)に送信」とあります。
今回のサービスの中でパラメータの検証処理を行えるのはコンピューティングサービスであるサービスLのみです。
AWSのAPIGWのようにサービスKがリクエストの検証が行える、というな記述も問題の中にはありません。

したがって、(c)に入るのは共通モジュールPです。
恐らくモジュールPはDB操作処理がまとめられたDAOのようなモジュールなんでしょう。

アプリ開発ばっかりやってるやつですが、共通のモジュールが何かを呼び出すってシーケンスは見たことないなと思ったのでサービスMにしました。
モジュールって呼び出されるもののイメージ

No53 ゆうちゃんさん

>パスワードが何通りあるかを計算し、その半分の数を1000で割った秒数が平均時間になります。

Yahoo知恵袋でこの計算式を見ました。知恵袋では「1秒間に1000回」なので1000で割っているのだと思います。問題文は「1秒間に10回」だから10で割るのだと私は思いました。

仮に5秒が正解なら、6桁にしても500秒(≒8.3秒)で、効果がない気がします。

連投失礼します。
設問2(4)、私は共通モジュールPにしました。
サービス○が解答であれば、表1から選ばせるかな～って思い…。

問1は20点取れれば上出来です(苦笑)

「指定されたパラメータを検証せず全て(c)に送信」

ここに共通モジュールが入るのは違和感がある
全て送信されるのは、サービスKとサービスLだけ
共通モジュールはサービスLがリクエスト内容して振り分け後のもの(全てではない)

＞共通のモジュールが何かを呼び出すってシーケンスは見たことないなと思ったのでサービスMにしました。

表2中に「共通モジュールPは、サービスMを呼び出して、次の処理を行う」と記述があります。


＞共通モジュールはサービスLがリクエスト内容して振り分け後のもの(全てではない)

図3中に「サービスKは、リクエストの内容に基づき、サービスLを呼び出す」とはありますが、パラメータの内容によって振り分けという記述は文中にありません。
利用者情報の更新にPOSTではなくわざわざPUTが使われていることと実際での実装を考慮すると、メソッド単位での振り分けを考える方が自然です。

メソッド単位での振り分けだとした場合、「（各メソッドで）指定されたパラメータを検証せず全て(c)に送信していた」と読めるのではないでしょうか。

さらに、「指定されたパラメータを検証せず全て(c)に送信」とあります。
今回のサービスの中でパラメータの検証処理を行えるのはコンピューティングサービスであるサービスLのみです。


↑検証せずにサービスKがサービスLに全量送ってるので、サービスLで検証するようにプログラム改修したと読みました。

検証ロジックが抜けて各モジュールにぶん投げてるのはいただけないのでサービスLが答えでは？

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

共通モジュールP派の方は「送信」という表現をどのようにとらえたのでしょうか？

表2に「共通モジュールP,及び共通モジュールPを呼び出す処理は,サービスLに定義されており・・・」とありますが、これって要するにサービスLの内部で共通モジュールP（ライブラリ）のメソッドを使用しているってことですよね？？？

ライブラリ（又はライブラリメソッド）に「パラメーターを送信」って、違和感をかなり感じるのですがいかがでしょうか？

私も「共通モジュールP」と書きましたが、
ライブラリメソッドの引数か何かにパラメータが渡されたと考えたのが理由です。

また、私もたなかさんと同様、共通モジュールPは「DB操作等が集約されたData Access Object(DAO)のようなもの」と考えました。

パラメータを一番最初に受け取るのは、「サービス〇」ではなく共通モジュールPなのかなと思います。

それと、もし正答が共通モジュールPの場合に、2つ目の[C]の空欄の文章が「共通モジュールPは利用者ステータスを変更できる」という表現になってしまう点も違和感を感じます。

共通モジュールP（ライブラリ）はあくまでサービスL内に利用される受動的な存在であり、サービスM（データベース）同様に能動的な表現がしっくりこないような気がします・・・。

その点、サービスLもサービスKから呼出しはされるものの、サービスKは受付、サービスLは処理を行う主体という位置づけなので、処理を行う主体が「変更できる」という表現に違和感はないと思いました・・・。

＞検証せずにサービスKがサービスLに全量送ってる

そもそもサービスKに検証する機能があるとは今回書かれていませんよね？
対策であるプログラムの修正が「サービスLでの検証処理を追加」であることは同意です。
であれば、検証せずにパラメータの全量を（共通モジュールPに）送っているのはサービスLです。


＞ライブラリ（又はライブラリメソッド）に「パラメーターを送信」って、違和感をかなり感じるのですがいかがでしょうか？

分かります。パラメータは引数として渡すものですからね。
私もこの表現には違和感がありますが、そもそも表1や表2含め問題文中に「送信」という言葉は使われていません。サービスにしてもモジュールにしても全て「呼び出し」という表現が使われているんです。
また、モジュールはサービスL内の処理ではなく、あくまで切り出された外部のライブラリなので、「送信」という表現も出来るのかな、と思います。

＞共通モジュールP（ライブラリ）はあくまでサービスL内に利用される受動的な存在であり、サービスM（データベース）同様に能動的な表現がしっくりこないような気がします・・・。

？
実際にデータベース操作の処理が記述されているのは共通モジュールPですよ。全く受動的（？）な存在ではありません。
MVCモデルの考え方で言うと、サービスLそのものの役割はControllerだと思います。

私はサービスM派です。
大まかな流れは以下だと思っています。
L→P→M（M:データベースの変更を行える）
ここで、重要だと思うのはMはデータベースそのもの（ここは定義ではなくニュアンス）ではなく、ユーザーからの指示によりデータベースを変更する、「クラウド上のサービスである」ということです。
であれば、最終的に利用者情報を更新するアクターはサービスMだと考えます。

そのため、送信されたパラメータを受け取るのも、利用者ステータスを変更するものもサービスMです。

LやP出ない理由は、Mに渡されるまでのどのリクエストにおいて、改ざんが行われても、結局はサービスMがパラメータを受取り、データの更新を行うと考えるためです。
※APIでチェックされなかったユーザーによるパラメータの指定が、実装のチェックがないためMまで送信されてしまうのがよくないよねってことだと思いました

＞ユーザーからの指示によりデータベースを変更する、「クラウド上のサービスである」ということです。

ちょっと言っている意味がよく分からないのですが、サービスMはAWSのDynamoDBなどのデータベースサービスを想定するべきだと思いますよ。

データベース管理が出来るSaaS（？）のAPIを実行するような実装を想定されているのかもしれませんが、そのような記述は問題文中にありません。

サービスMはあくまで「マネージド型のデータベースサービス」としか紹介されていません。ここで言うマネージドとは、単にインフラ面の運用/管理がマネージドというだけで、データベースの更新処理等が用意されているわけではないです。

その点、サービスLもサービスKから呼出しはされるものの、サービスKは受付、サービスLは処理を行う主体という位置づけなので、処理を行う主体が「変更できる」という表現に違和感はないと思いました・・・。

↑完全同意
モジュールPとサービスMだと変更できるの言い回しがおかしいわ
少なくともサービスLが日本語的に違和感あるとこはない
これでモジュールPだったら、相当変な言い回ししてるわ

問1なんてこれ以外の問題も皆答え割れてるの多いし、地雷だったか
ただ下駄で10点プラスされそうだがw

この投稿は投稿者により削除されました。(2024.04.23 12:27)

>私もこの表現には違和感がありますが、そもそも表1や表2含め問題文中に「送信」という言葉は使われていません。サービスにしてもモジュールにしても全て「呼び出し」という表現が使われているんです。

おっしゃる通りです。
私もこの点は認識していたのですが、「サービス間であれば、コンポーネント間の通信として解釈できるかな」と思いました。


>実際にデータベース操作の処理が記述されているのは共通モジュールPですよ。全く受動的（？）な存在ではありません。
>MVCモデルの考え方で言うと、サービスLそのものの役割はControllerだと思います。

この点については以下のように考えました。
「サービスLはFaaS（AWSでいうLambdaみたいなイメージ）みたいなもんかな？
ということはサービスLにはコードが記述されたファイルが置いてあって、そのファイル内で共通モジュールP（ライブラリ）をインポートする記述があり、ライブラリメソッドを呼び出しの記述があるんじゃないだろうか？」

上記のように考え、（確かに変更処理自体は共通モジュールP内でサービスMを呼び出して行うものの）システム全体の中での粒度的に言えば、共通モジュールPはサービスLのコード内で呼び出されるレベルの存在であり、処理の主体はサービスLという位置づけがしっくりくるかな・・・と感じ、共通ライブライPはシステム内の関係性においては受動的な存在だと思いました。
※共通ライブラリPももちろん回答候補にあったのですが、他の候補（サービスL、サービスM）も含め、正直文章表現の点以外では甲乙つけがたく最終的にライブラリLにした身なので、ご記載の内容に反論点は基本的にございません。）

（確かに変更処理自体は共通モジュールP内がサービスMを呼び出して行うものの）システム全体の中での粒度的に言えば、共通モジュールPはサービスLのコード内で呼び出されるレベルの存在であり、処理の主体はサービスLという位置づけがしっくりくるかな・・・と感じ

↑その通り。モジュールPは呼ばれる受動的な存在

＞この点については以下のように考えました。
「サービスLはFaaS（AWSでいうLambdaみたいなイメージ）みたいなもんかな？

そうですね、サービスLはAWS Lambdaなイメージが一番しっくり来ると私も思います。

＞共通モジュールPはサービスLのコード内で呼び出されるレベルの存在であり、処理の主体はサービスLという位置づけがしっくりくるかな・・・と感じ

実際のコード設計を考えてみると良いと思います。
DB更新処理の主体はあくまで共通モジュールPで、サービスLは共通モジュールPを呼び出しているに過ぎません。

＞↑完全同意
モジュールPとサービスMだと変更できるの言い回しがおかしいわ

共通モジュールPであれば何もおかしくないですよ。わざわざ“共通”モジュールPと書かれているため、いくつかの処理から共通で使える形でデータベース処理が含まれている、ということを作者は表現したいんでしょう。

つまり、共通モジュールPにstatusも変更“出来る"処理が含まれていると解釈すれば、その言い回しに矛盾はありません。

>実際のコード設計を考えてみると良いと思います。
>DB更新処理の主体はあくまで共通モジュールPで、サービスLは共通モジュールPを呼び出しているに過ぎません。

異論ないです。
なので、私的には文章表現とシステム全体の中での粒度間でしか、優劣がつけられず・・・といった諦めを感じサービスＬにした次第でした。

※ほんとにこの問題の文章は、ひどいなと思ってます・・・。
情報処理安全確保支援士試験が国語の問題だと揶揄されますが、これは、「パラメーターを検証しなかった」のがどこなのかの主語の置き方によって、回答が変わり、かつそのパラメーター検証の主体に関する断定的要素がないという、国語の問題以前な気がしています。
（サービスＫもサービスＬも共通モジュールＰでも「パラメーターを検証しなかった」の主語に当てはまりそう・・・）

サービスＫ（サービスＬに渡す前にパラメーター検証しなかった）⇒サービスＬが変更可能
サービスＬ（共通モジュールＰに渡す前にパラメータ検証しなかった）⇒共通モジュールＰが変更可能
共通モジュールP（サービスＭを呼び出す前に検証しなかった）⇒サービスMが変更可能

そうですね。
問1に限らず文章表現的に気になる点はいくつか散見しました。

そういう表現の曖昧さもあり、問題文中に記述の無いことを妄想して回答した人も多いのかもしれませんね。

この投稿は投稿者により削除されました。(2024.04.23 13:03)

>そういう表現の曖昧さもあり、問題文中に記述の無いことを妄想して回答した人も多いのかもしれませんね。

そうですね。
私は・・・
①サービスK（APIゲートウェイ）が（記述にはないのでここが妄想といわれるのであれば妄想）パラメータ検証しなかった、というシナリオがそれほど不自然に思えなかったこと。
②文章表現でサービスＬしかしっくりくると思えるものがなかったこと。
・・・に基づきサービスＬにしました。

(妄想を加えた理由としては、問題文からだけでは判断ができなかったこと、および過去問演習で「そんなん書いてないだろ！」と突っ込みたくなることがたまにあったので、これは妄想追加して判断する系の問題か？と思ったことが挙げられます 笑)

あとはIPA次第ですね・・・

すみません。
「妄想」というのは2-4だけではなく、他の問題も含めての話でした。

私自身普段からAPIGWを触っているので、個人的には絶望さんの考え方にも同意出来ます。
ただあくまでAPIGWの機能はオプションなので、サービスKに検証機能があるなら問題文中に記述して欲しいな、とは思いますが。

>すみません。
>「妄想」というのは2-4だけではなく、他の問題も含めての話でした。

理解いたしました。
（ちなみに「妄想」と言われれば確かに「妄想」なのでお気になさらないでいただければ幸いです  汗）

>ただあくまでAPIGWの機能はオプションなので、サービスKに検証機能があるなら問題文中に記述して欲しいな、とは思いますが。

パラメーター検証しなかったのがサービスＫなら、ほんとまさにおっしゃる通りって感じですよね・・・。

それも含め、そもそもパラメーター検証しなかったのが、K,L,Pのどれか特定できるような情報を加えてほしかったのと、「送信」とか「変更できる」とかの表現について、国語的な整合性がとれるような問題文であってほしかったです・・・。

>おおくるいさん

ご同意いただけてうれしいです。
今ここでどれだけ文章の不整合や技術的な観点から推理しても、IPA回答が発表されたら共通モジュールP、もしくはサービスMだった、がっかり・・・となる可能性をはらんでいることは認識しつつも、心の安らぎになります 笑

私は「P呼出し処理」だと思いましたが、同じ解答の人いなそう(´;ω;｀)

直近でみんなが議論してる問題多分過去問でよくあるあなたシステム要件理解できてますか系なのにここまで答えが一致してないの気持ち悪すぎません？
やっぱ今回めちゃくちゃ難しかった(めちゃくちゃだった？)のでは…

やっぱり共通モジュールPかな。
全て共通モジュールPに送信していた。っていう文章になるのが不自然だけど、利用者情報を直接書き換えることができるのは共通モジュールPしかいない。
でもサービスLも正解で良いような気もする。
サービスKとサービスMはない。

サービスK そもそも表内にないので論外
サービスM 後半の空所がサービスMの特徴を考えると、日本語的におかしいのでダメ


共通モジュールPは前半の空所に入れたときに、送信という言い回しが微妙
サービスLなら違和感ないのかな

例えがビミョーかもしれんが、
殺⚪︎事件が起きたときに
指示役(サービスL)が悪いのか、指示を受けて手をくだした奴(共通モジュールp)が悪いのか、凶器のナイフ(サービスM)が悪いのか、を聞いているような微妙な問題
ナイフそのものが悪いということにはならんので、二択

私は共通モジュールPにしました。

「指定されたパラメータを検証せず全て(c)に送信」
とあり、仮に(c)がサービスLだとすると、パラメータを渡してサービスに送信する、
という日本語に違和感を覚えたからです。
サービスをリクエストする、ならわかるんですけど。

サービスMはたなかさんが仰る通りデータベースという器を提供するサービスであるので処理の主体ではなく除外。
消去法でモジュールPが該当すると考えました。

とはいえ、1つ目の空欄(c)と2つ目の空欄(c)両方に共通モジュールPを当てはめた時に、日本語表現が不自然でしたので、サービスLが正解のようにも解釈できるんですよね。あちらを立てればこちらが立たず。なので近いと感じる方を選びました。


大学入試のように、文章を一意に解釈できる日本語にして欲しいですね。だから割れるんだよなIPAの試験は。

ほんとですね。
案外どっちでも良いのやら

送信内容を改ざんしてリクエストを送信する先がどこかが判断ポイントやろか
インターネット経由だとすると図3の通りサービスKのことだよね
とすると空所はサービスＬが平仄揃ってて違和感はない
まさかサービスLから共通モジュールpに送られる間での改ざんの話なんか？

あと図3の通りサービスKが受けるって言い回しはあるので、サービスLが送信するという言い回しも違和感なし
モジュール呼び出すで統一されてるし

改ざんしてリクエストを送信する先〜という話をすると、そもそもその送信先はサービスKになると思います。
改ざん云々はあくまでそういうリクエストをAPIに投げるということなんじゃないですかね。改ざんする場所は考慮しなくて良いかと。

改めて問題文を読んでみました。

私は「“検証せず”全て(c)に送信していた」の“検証せず”が気になっています。
cがサービスLである場合、検証を行うのはサービスKということになります。
ですが、サービスKにそのような検証を行える機能があるとは明記されていません。

しかし、表1のサービス概要に「その内容に基づき」というものがあるのが気になってきました。
ここはあくまでもリクエストのメソッドを見て振り分けているだけだと思っていたのですが、パラメータ内容まで確認（検証）出来るという意味にも取れそうですね…。

また、表2にて共通モジュールPは既に開発済みのライブラリだと述べているにも関わらず、「共通モジュールP、及び共通モジュールPを呼び出す処理は、サービスLに定義されており〜」と記載されています。共通モジュールPの実処理もL内の処理とされているのでしょうか。


もしかしたら作問者が想定している答えはサービスLかもしれませんね。
個人的には違和感が凄いですが。

前述しましたが、この問題の答えは「パラメータの検証を行う（行える）場所はどこか」で分かれると私は思っています。

ただサービスKで検証可能だとすると、表5対策案の「プログラムの修正で対応する」はおかしいですね。「サービスKの設定を修正する」になりそうです。

パラメータの検証を行えるのはサービスLだと思います。表5の2でも利用者APIの不備を修正するのにサービスL中のP呼び出し処理を修正しているわけですから。

やはりそう考えるのが自然ですよね

もうサービスLも共通モジュールPもサービスMも全部正解な気がしてきた。
そもそもパラメータstatusの指定について定義していないのがダメダメ。
何でもHTTPリクエストで送れちゃうよね？

全部まとめて  「Sシステム」  でどうでしょう？

（表２の注記に  Sシステムとあるので）もうヤブレカブレ。

問1の計算問題の配点は6〜8点ありそうですね

20字以上の記述問題が6箇所もありますし、流石にそんなに高くないと思いますよ。
あっても4点ほどじゃないですかね。

たなかさんに同意します。記述で偏差値が高い方に配点すると思う。

計算問題は配点高いよ
エンベデッドとか8点とか10点とかザラだし
ただ安全確保士ごときの問題では6点から8点というのは的外れでもない
流石に10点はないと思うけど、あってもおかしくないが

出来の悪いitecがサービスLが答えだってさ
つまり共通モジュールPが正解の可能性アップ
共通モジュールp大勝利！

itec的には下記のものが正解らしいですね
()つけ忘れた！オワタ！と思ってただけに？マークがついてます

(3)¥W j|J n|N d|D i|I ¥W


誤答なのか、実はコードそのものを書いてるわけでないので、大意が読み取れてれば良い感じなんですかね？
これコンピューター的にはどう処理するのか改めて見るとよく分かりませんが、itecが正解と言ってるから正解ですね


ついでにサービスLが正解でこっちも草

No.68 絶望さん
> algが改ざんされていても、とにかく署名検証さえすれば必ず検証は失敗し、改ざんを検知できると思うので、私の回答でも対策になるのでは？？？

自分としてはJWTの仕様にそぐわないので対策になり得ないとの考えです。
なぜなら、JWTの形式が「必ず署名をつける」というものではなく「algで設定したアルゴリズムに基づいた加工をする」というものだからです。
設問では全く触れられてませんが仕様としてハッシュ化や暗号化アルゴリズムも設定できます。
署名アルゴリズムも「RS256」以外の種類があります。
そういった前提の元、とにかく署名検証だけやろうとしても、ヘッダ「alg」に正しい値がないとどのアルゴリズムを使って署名検証をすれば良いのかわからないのです。（algを「RS256」固定という要件にすればできなくもないかもしれないですが）
よって、algの値をバリデーションしていくのが主な正答となるのかなと考えております。

駄文失礼しました。
IPAがこの辺りをどこまで踏まえて設問を作ってるのかわからないのでご参考まで。

>もずくすみさん(No.118) 
>(3)¥Wj|Jn|Nd|Di|I¥W
これは誤検知するパターンです。
正規の文字列に偶然引っかかります。
しかし、予期せぬ文字列まで引っ掛けています。
さすがにITECも後程修正するでしょう。

この投稿は投稿者により削除されました。(2024.04.25 00:12)

この投稿は投稿者により削除されました。(2024.04.25 00:20)

>社畜さん

ありがとうございます！
（誰からもコメントいただけそうにないなと思っていたので、コメント頂けて大変ありがたいです！）

>自分としてはJWTの仕様にそぐわないので対策になり得ないとの考えです。
>なぜなら、JWTの形式が「必ず署名をつける」というものではなく「algで設定したアルゴリズムに基づいた加工をする」というものだからです。
>設問では全く触れられてませんが仕様としてハッシュ化や暗号化アルゴリズムも設定できます。

今回の設問だと「RS256で署名が付与されている」前提の設問ではないでしょうか？

問題文よりJWTの発行～改ざんまでの流れとして以下と認識しております。
①認証APIで認証後にSシステムでJWTの発行が行われる（表2の認証APIの説明より）
※その際にはalgがRS256で署名される（表4より※表4は改ざん前のJWTのヘッダーとペイロードのデコード結果という認識です）
②発行されたJWTはスマホアプリに保存される（図4の3つ目の「·」の記述より）
③JWTはスマホからAPIを叩くときに、スマホアプリによりHTTPリクエストヘッダ内のAuthorizationヘッダに設定される（図4の3つ目の「·」の記述より）

補足：algの値の改ざんは、スマホアプリがAPIを叩くために送信するHTTPリクエストを中間者として拾って、③の値を改ざんしているという認識です。

署名は①のＳシステムがJWT発行時点でRS256で生成されていると思うのですがいかがでしょうか？

>署名アルゴリズムも「RS256」以外の種類があります。
>そういった前提の元、とにかく署名検証だけやろうとしても、ヘッダ「alg」に正しい値がないとどのアルゴリズムを使って署名検証>をすれば良いのかわからないのです。（algを「RS256」固定という要件にすればできなくもないかもしれないですが）

この点に関しては、algがNoneにも関わらず、署名が付与されている時点でエラーになるのでは？（＝とにかく署名を検証すれば改ざんに気づけるのでは？）という想定をしておりました。


私も正直余りJWTに対する理解に自信はないので、おかしいと感じる点あれば教えていただければ幸いです。

>よって、algの値をバリデーションしていくのが主な正答となるのかなと考えております。

この点はおっしゃる通りだと思います・・・。

今回、改ざん内容に「署名削除」がないので、私の回答が別解として部分点でももらえないかな・・・ぐらいのすがるような、そんな気持ちからの投稿でした・・・

No.120 Pix様
ITECさんが正規表現を間違える筈がないので、エスケープできなかったからとかではないかと思います。
おっしゃる通り、あとで修正なさるでしょうね。

No.119 社畜様
（突然横から失礼しますが）おっしゃりたいこと凄くよくわかります。
JWTは自己完結型なので、サーバが署名を適切に検証しない場合かなり危険なことになります。
しかし、このような公共の場であんまり詳しい説明もできないですし、ジレンマですね。
ともかくも「Bearer スキーム」を訂正して「PoP」にすればトークンの署名を確かめる実装にはできます。

設問２（２）は    検証内容となるデータ→    ヘッダのAlgをNONEに指定
                  どのような検証を行うか→  エラーが出て、JWTの改ざん失敗を検証

に、自分はしました（自信ないけども）。本当はもっと複雑な過程があるのですが、文字制限２０までですし、全部記述すると危険かなと。
アルゴリズムもRS256の他にもまだある、のもおっしゃる通り。HS256なんかも怖いです。
あと、IPAはたぶんわかっておられると思いますよ。あんまり詳しく試験に出すと悪用されるリスクも高い、そのギリギリを狙って出題してくれたんだと思います。詐欺の手口を知らないと詐欺に対抗できませんし。（警察関係者の方、国家試験に免じて危険なコードだけどちょっとだけだから勉強させて下さい）

それにしても皆様やっぱりコード大好きですねー
一部の受験者大盛り上がりです。昔の試験みたい〜〜

私も（）をつけないで解答したものです。

¥Wj|Jn|Nd|Di|I¥W
これ誤検知するパターンありますかね？

［パターン］を変えて解答してもいいのですかね。
例えば、［xyz］と書かれているのに
［jJ］の2文字で書くのはありなのか？

ルールに従っていればitecの解説が正しいようにも見えてきます。

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

>皆コード好きでしょvさん
>しかし、このような公共の場であんまり詳しい説明もできないですし、ジレンマですね。

すみません、私の社畜さんへのお返事は的はずれだとお感じになられましたでしょうか・・・

コメントの構図的に、以下のように見えるため、社畜さんにご迷惑をおかけしてしまったのかなと思い…
・社畜さんからコメント頂く
・私が的外れな返信
・皆コード好きでしょvさんが、社畜さんへフォロー（的外れな返信に対し、回答しづらいだろうな・・・という皆コード好きでしょvさんから社畜さんへのご配慮？）のコメント

もし、上記構図なのであれば、申し訳ございませんでした。

ちなみに私は試験で回答を書いた際に、「そもそも何のための署名だよ、algが何の値に改ざんされても、その改ざん後のalgで署名の検証さえやれば、失敗するにきまってるんだから改ざん検知できて当たり前だろ」というレベルの考えで回答しただけでした。
そして試験後に調べて、以下記事でJWTに対するalg:none 攻撃のことを知った程度の付け焼刃レベルの知識です。
ttps://qiita.com/ockeghem/items/cc0b8ab74f46834d055b
（リンクが投稿できないため、先頭の"h"を削っております）

それでかなり安直ではありますが「（あくまで文章解釈上）今回の設問は署名のないJWT再生成するとは書かれてないし、署名削除とも書かれてない。よって正規のJWTの署名が残ってるのであれば「alg:noneに改ざんされているが、正規の署名が存在する」という状態のJWTと解釈できる。それならalg:noneでも署名検証すれば改ざん検知できるといえるのでは？それなら私の回答もありなのでは？」といった疑問を持った次第でした。
（これはあくまで、問題の文章に対する解釈レベルでの疑問であり、技術的に私の回答が正答であるのでは？という疑問ではありません。）

私のコメントがもし技術的な主張に見えてしまっていたら申し訳ございませんでした。
※なんか自分で投稿を見返してみても、技術的な主張しているように見えてもしょうがないなと感じるので、多分私が悪いと思います・・・

>受験生さん(No.126) 
>¥Wj|Jn|Nd|Di|I¥W
>これ誤検知するパターンありますかね？

本来は
":jndi:"や":JNDI:"という6文字にマッチさせたいはずです。
しかし、"¥Wj|Jn|Nd|Di|I¥W"は分解すると、2文字つづの5のパターンです。
¥Wj
Jn
Nd
Di
I¥W"
これは明らかに意図と異なります。
また、このパターンは偶然にも":jndi:"や":JNDI:"にマッチします。
しかし、文字列制限がないので、極端なはなし
:j:
xJnx
yNdy
zDiz
:I:
などの文字数不定のパターンにもマッチしてしまいます。
itecで正規のケースのみ確認して、誤検知ケースの確認が漏れていたのではと
想定しています。

pix様回答ありがとうございます。

制限が無いのは、:までであり、その後は
連続した文字列（JNdi）になり、また:が出てきて制限数が無くなると考えています。

:j:
xJnx
yNdy
zDiz
:I:
は、:があるのでマッチしない気が。。。
すみません。IPAの解答が出てくるまで、理解するのを諦めます。

¥Wj|Jn|Nd|Di|I¥W
これ誤検知するパターンありますかね？

↑大アリなので、模範解答はこれではない
ただ部分点はあるかも知れない。
問1は見るからに皆出来悪そうなので

［パターン］を変えて解答してもいいのですかね。
例えば、［xyz］と書かれているのに
［jJ］の2文字で書くのはありなのか？

↑無しだと思う。最低1文字×3で使うものなので

ちなみにitecの速報は、毎回結構酷いと評判です。
サービスLとitecが書いてきたので、あーこれ共通モジュールpが答えかとショックを受けてるところです
TAC一択

>社畜さん
>皆コード好きでしょvさん

申し訳ございません、私が１点誤解しているかもしれない点があり、もし可能であれば教えてください。

社畜さんのコメントを再度読み返し、以下の箇所について私が理解しきれていないのかもと思いました・・・
>署名アルゴリズムも「RS256」以外の種類があります。
>そういった前提の元、とにかく署名検証だけやろうとしても、ヘッダ「alg」に正しい値がないとどのアルゴリズムを使って署名検証>をすれば良いのかわからないのです。（algを「RS256」固定という要件にすればできなくもないかもしれないですが）

この点について、設問では以下の流れの認識なのですが・・・
①システムSがJWTが発行
②スマホアプリに保存される
③スマホアプリがAPI叩くときにシステムSに送られてくる
④システムSがJWTを検証
・・・今回のケースにおいて、algってシステム側で固定化すると不都合が生じるものなんでしょうか？？？

※システム側が特定のalgで発行したJWTを（スマホ経由で）システム自身で検証する流れなので、逆にalgは固定化しとかないとまずいのではないだろうか？スマホアプリから送られてくるJWTについて、別のalgの値が受け入れられるようにしておくのはセキュリティ的なデメリットしかないのではないだろうか？ぐらいに考えていたのですが、このそもそもの考えが私の誤解に基づく間違った認識なのかも・・・と思った次第です。

TACの回答出ましたね。
2-4は共通モジュールPとのことで安心しました。

TACしか勝たん

itecぬか喜びさせないで。。。
あー59点はやめて。

＞絶望様へ

＞すみません、私の社畜さんへのお返事は的はずれだとお感じになられましたでしょうか・・・

とんでもございません。凄く的を得ているお返事だと思います。
私の方こそお気をつかわせてしまって申し訳ありませんでした。
憶測ですが社畜様のおっしゃりたいことは以下、

①algの検証だけでチェックするのは危険
↓
②攻撃者が「こうして」「ああして」「こうすると」なりすましが成功してしまう。
↓
③なるほど。確かになりすましされちゃいますね。

みたいなことをご説明したかったのだけど②を詳しく述べると不正アクセス禁止法に抵触する恐れがあるからだろうと思ったからです。②を微に入り細に入り説明したいけどできない、がもどかしいだろうな、と。
また食い違いと言うか「alg」のみ検証と「algを用いて署名したトークン」を検証は全然違うのでそこでも混乱が生じたのだと思います。

＞ちなみに私は以下回答をしました。
＞データ:ヘッダとペイロードに対する署名
＞内容:ヘッダとペイロードが改ざんされていないかの検証

上記の絶望様のお考えはおおむね正しいと思います。
ただNONE攻撃は署名そのものを全く別物に書き換えるのでどの署名が正しいか検証する術が無いわけです。


＞でここで疑問があります。
＞問題に「署名は削除した」もしくは「署名を改ざんした」といった旨の記載があれば、私の回答は×かなと思います。
＞ただ問題文にはそういった記述がなく、「署名が削除・改ざんされずにそのまま残っている」なら、
＞algが改ざんされていても、とにかく署名検証さえすれば必ず検証は失敗し、
＞改ざんを検知できると思うので、私の回答でも対策になるのでは？？？

×ではないと思います。考え方は合ってます。
ただこの攻撃の場合「署名が削除・改ざんされずにそのまま残っている」ことは無いです。
完全に別物に書き換えられます。
問題文内の「Bearer スキーム」は全く検証せず、そのまま受け入れます。これは非常に危険です。
ただ「では他に何のスキームを使うのか？」は全くヒントが無く、PoP（所有者確認。proof-of-pasession）を使うのではないか？と推測するしか無いんですよね。難問ですよね。
実装したことが無いので確、とは言えませんがこれなら少なくとも所有者確認をとるので改ざんされたトークンを受け入れることは無いでしょう。

イメージとして

最初に正規の利用者が署名したトークンを発行する
↓
正規の利用者が署名したトークンの所有者確認をとる
↓
none攻撃で署名が書き換えられても所有者確認がとれないのでエラーになる

的な流れで。

参考までにですが自分も事前に偶然NONE攻撃のことを知って色々調べてたんですが、
まさか試験に出題されるなんて想像もしてませんでした。
国内で参考になりそうな文献はほぼ無かったです。
DB PRESS vol.134（休刊中）に「いまさら聞けないJSON Web Token」がありましたのでそれで基礎を学んで、後は海外の文献や翻訳文献を探しましたが「どう攻撃すれば成立するか？」はあっても「どう攻撃を防ぐか？」には全然言及が無いので参りました。

自分も自信がありませんので間違っている点のご指摘、ご教授頂けましたら幸いです。

あと、絶望さん、絶望なさらないで下さいね〜vこちらでこれだけしっかりご質問できるなんて絶望さんは凄いです。

失礼いたしました。

ざっくり説明になります。

JWTの検証に関しては、ヘッダーのalgの値を確認しその値で署名を検証するという流れになります。
その際に、alg:none を指定された場合、署名の検証がスキップされてしまうというのが問題になります。

RFC7515ではalgの値を確認して署名を検証することは必須となっています。
そのため、正しい実装で脆弱性に対処したと考えた際に、algの値を確認せずに必ずRS256で署名を検証するという答えは誤りになると考えます。

対策はアプリケーションでサポートしているalgであるかを検証、その後algで指定された方法で署名を検証することです。
この問の場合は、RS256のみをサポートするとし、それ以外の値は拒否する形になると思います。
このあたりは RFC 8725を参考にしてください。

また、Bearerに関しても特に問題のない実装です。JWTの検証に問題があるのみです。

詳細は以下を調べてみてください。
Bearerに関して：RFC 6750 
JWTに関して：RFC 7519
JWSに関して：RFC 7515
JWTのベストプラクティスに関して：RFC 8725

［パターン］を変えて解答してもいいのですかね。
例えば、［xyz］と書かれているのに
［jJ］の2文字で書くのはありなのか？

→これはありでしょう

＞むぐむぐ様

ご教授ありがとうございました！
JWTのベストプラクティスに関して：RFC 8725  早速確認します。

問1の計算問題の配点3はないかな
当てずっぽでは出せないので6点か8点かな
headerの問題は当てずっぽしやすいので2点とか

問1は出来悪そう
8割いけたという報告はほぼ無し
4から7割のレンジ
5割あればワンチャンかしらね

>皆コード好きでしょ続さん
>ただNONE攻撃は署名そのものを全く別物に書き換えるのでどの署名が正しいか検証する術が無いわけです。
>ただこの攻撃の場合「署名が削除・改ざんされずにそのまま残っている」ことは無いです。
>完全に別物に書き換えられます。

ありがとうございます。
そうですよね、試験後の調べでNone攻撃としての手法はそうなんだろうなとは思ったものの、その記述が問題文中になかったので、文章の不備でワンチャン部分点ないかな・・・と思った次第でした。

>むぐむぐさん
>alg:none を指定された場合、署名の検証がスキップされてしまうというのが問題になります。

ありがとうございます。
そうですよね、それも試験後の調べで認識はしておりました。
なので修正内容として「Noneで署名付いてたらエラー」という処理に修正するという回答でもよいのでは？
だったら私の回答の「検証対象のデータ:ヘッダとペイロードに対する署名」だけでもワンチャン部分点ないかな・・・と思った次第でした。
※ただこの修正では、「Noneで署名削除されたら通ってしまう」と思いますが、問題文には正規署名削除の記述ないので、あくまで設問の回答としてはその点は考慮不要でワンチャンないかな・・・と思った次第でした。

>対策はアプリケーションでサポートしているalgであるかを検証、その後algで指定された方法で署名を検証することです。

この点は、この設問の正答としておっしゃる通りだと思います。

>皆コード好きでしょ続さん
>あと、絶望さん、絶望なさらないで下さいね〜v

ありがとうございます！


私の回答が今回の設問の正答からは外れていると認識はしつつも、文章上の不備から少しでもワンチャン狙えるポイントはないか狙うような悪あがきに近い疑問だったのですが、ご回答頂けてありがたかったです。
ありがとうございました。