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

最後の自分で改善案書くやつ、模範解答なんなんでしょう、、、

自分は
・APIKeyの有効期限を短くする
・ログインに多要素認証を入れる
の2つを書きました、が、これで満点もらえるか自信ないです

APIは求職者属性情報を問合せあった企業だけ見れるようにする

アプリはパスワード変更の時も再設定同様にメアド認証を挟む

って書きました
APIは文字列が日付依存なのをランダムな値にするって書くのと迷いました

求職者のidが日付から生成されるのはまずいってことでランダムに生成するように書きました。。。

僕は最後
・有効期間内のAPIkeyを無効化できるようにする
・パスワード認証の連続失敗で制限がかかるようにする
にしました。
模範解答がなんなのかすごく気になりますね…

お疲れ様でした。
自分はラストの問題、

社員証などでその企業の担当者であることを証明するなど、多要素認証にする。

1利用者のAPIkeyの発行を複数としない。

と書きました。複数所持できるなら、有効期間の意味がないのでは？と思ったのですがどうでしょうか。

利用者のIDは数種類の文字種を使って、規則性のない割り当てをするって書きました

あとAPIkeyは複数発行しない

gとhが全然わからなかった
gはインジェクション文字列を会社名のところに入力、hはAPIを新しく発行と書いたけど自信ない

ghはそれしかないと思ってました。
いや、正確にはapiで発行しなくても既存一覧表示でも良いなとは思いましたけど、些細な違いだと切り捨てました

gは図Bの手順1~3を実行
hはAPIKeyを新規発行

ぶっちゃけhは全然分からん

gh、多分これだろなって頭に入れてたとこが前後の手順で書かれてて
やることないじゃん！ってビックリしたあと長考して図3の文字列とKey再発行にしました
ここで時間取られて最後の問題の時間配分キツかった〜

gfはそれしかないと思いました
私は新しいapi発行するのではなく、既存のものを取得にしました。
ab はみなさん何にしましたか

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

a:ア
b(省略).jp/
c:利用者IDとPWが入力されてログイン
d:他の画面遷移と使用するセッションIDを別にする

にしました

X-content-type-options違ってた
content-typeの内容書いてた…

>13
同じです
dは変更と書きましたが、新しいものの方が確かにいいかも…

i.jのwebAPIの仕様改善って何なんだ
APIkeyを期間内に一つのユーザーにつき一つしか発行できなくすればいいのか？

最後の丸投げ問題、どんな採点基準になるんだ？
もっとも有効な対策を一つって書いてましたけど、契約時のkey一つにするのと、アクセス元制限つけるの二つ書いちゃったw

Strict-Transport-Securityが分かんなくて落としたけどHSTSのことらしくて泣いた
基礎力足りてないなぁ

APIの仕様改善はAPI keyだけじゃなくて利用者IDもAPI要求時に確認するって書きました……が全く自信なし
模範解答発表までずっと悶々としそうです……

X-content-type-optionsって午前で出てたんで、逆にクリックジャッキングを防ぐって書きましたけど、詳細は分からなかった、、、

aが、アの理由ってなんでしょう、、イだとおもいました、、、

ログイン情報なくてもセッションID取ってこれるのがアかなと思ったんで……全く分かりません

P33の注記1を読んでログイン前に02画面にアクセスしたら（できたら）エラー画面になると思って、aをアにしました。

二つ目か三つ目の「a」でログインさせようとしてたのでアにした気がします

aはイにしました。ログイン成功した後にセッションID変わってれば例の不正ログイン防げるわけで。

最後の改善案は、WebAPIのIP制限と、MFA導入にしました。

設問3ですが
API
方針：APIの改善は電子署名を利用する
理由：APIkeyが漏洩しても秘密鍵が漏れない限り悪用されないから

WebApp
方針：登録内容やパスワードの変更時に現在のパスワード入力を要求する
理由：パスワードを知らない攻撃者に変更させないため
と書きました

APIはAPIkeyの一致だけで正当な利用者と判断しているところ、WebAppはパスワードの再設定にパスワードを要求していないところが問題かなという判断です

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

自身ないけどこんな感じで書いた。

API
APIの発行１個だけにして漏洩時は削除を可能に
今のままだとなすすべがないから

WebApp
固定セッションIDはやめる
ハイジャックされるから

APIの有効期間が14日って自分は短く感じたから書けなかったけどどうなんでしょうね。

WebAppの方は、図にCSRFありなしが敢えて描かれていたので、ログインCSRFで攻撃者のセッションでログインしてしまうことが問題だと思ってました

図にCSRFの線があったので、CSRFトークンを発行するにしました。
多要素認証も考えたけどサーバの追加がいるのでちょっと大掛かりすぎるかなと思いました。

APIkeyの有効期限、14日間ってかなり微妙な数字ですよね...どういう使い方を想定してこの数字になったのか...
自動で定期実行するようなケースなら有効期限は1年とかにしておけば便利だし慎重に取り扱われると思う。
逆に手動で動かすプログラムに入れるために都度発行するにしては長すぎる。
この数字だとユーザーの手間は増えるし、そのせいで扱いも雑になりそうだしでアンチパターンだと思うんですよね。

APIKeyの細かな権限管理：各 API キーに特定の権限を割り当て、特定のデータ（例えば三か月以内の特定の属性）へのアクセスを制限。→  今回の攻撃で全てのデータが漏洩するおそれがあるため、その最悪を防げる。

APIの方は、現仕様に問い合わせなどがあった求職者IDを取得と、任意の求職者IDで情報取得でき、求職者IDが連番と書かれていたので、連番にしないにしました。
連番だと問い合わせない求職者IDでも順番に試せば情報取得できてしまうので。
その意味では、問い合わせのあった求職者IDのみに限定でも良い気がしてきました。

攻撃者のがAPIKeyの閲覧と新規発行のどちらをするかですが、登録済みのAPIKeyは
①被害企業が日時範囲を制限している可能性がある
②14日以上経過し、失効している可能性がある
という理由で、新規発行画面への遷移としました

ijklは何でも正解！ボーナス問題と思ってるけど違いますかね。
jwt認証を追加する→認められた接続元のみ許容し不正利用を防ぐ
多要素認識を追加する→認識機能を強化して不正ログインを防ぐ
間違いではないでしょう？？

私もそのようなことを書きました
aは私はイとしたのですが、皆さん何選びましたか
bはb(省略).jp/としました

gはメールヘッダーインジェクションを行う必要がありますね。その上で検査文字列そのままではなくtoのアドレスは攻撃者である必要があります。で、攻撃者メアドに送られた確認メール内のリンクを押下して反映されるメアドはインジェクション文字列なので今度は普通に攻撃者メアドで変更する流れです。
hは発行してもいいし確認でもいいと思いました。確認だとダメな理由が見当たりませんでしたので両方書きました。字数制限があったら発行にしてたと思いますを

問4のiって、
問い合わせした企業のみ、属性情報を見れるようにする、じゃダメなの？

ランダムな文字列にしても見えるんじゃ意味なくない？

＞TACの過去問を見た感想

ｓｋさん

>ランダムな文字列にしても見えるんじゃ意味なくない？
世の中のセキュリティはランダムな文字列に頼っているんです。
パスワードもランダムな文字列ですし、暗号に出てくる鍵もランダムな文字列です。

十分な桁数と文字種があればランダムな文字列をあてることは天文学的な確率になり、総当たりにも実現不可能な時間がかかります。
この状態のことを安全としているんです。

>問い合わせした企業のみ、属性情報を見れるようにする
予想にはなりますが回答の幅は広そうなので、ある程度技術的に具体的な実現方法が提示できていればいいのではないでしょうか？