HOME»情報処理安全確保支援士掲示板»令和6年秋期試験『午後試験【問4】』
投稿する
令和6年秋期試験『午後試験【問4】』 [1766]
管理人(No.1)
令和6年秋期試験 午後試験【問4】についての投稿を受け付けるスレッドです。
2024.10.13 00:00
OCSPレスポンダ君さん(No.2)
最後の自分で改善案書くやつ、模範解答なんなんでしょう、、、
自分は
・APIKeyの有効期限を短くする
・ログインに多要素認証を入れる
の2つを書きました、が、これで満点もらえるか自信ないです
自分は
・APIKeyの有効期限を短くする
・ログインに多要素認証を入れる
の2つを書きました、が、これで満点もらえるか自信ないです
2024.10.13 15:17
すこさん(No.3)
APIは求職者属性情報を問合せあった企業だけ見れるようにする
アプリはパスワード変更の時も再設定同様にメアド認証を挟む
って書きました
APIは文字列が日付依存なのをランダムな値にするって書くのと迷いました
アプリはパスワード変更の時も再設定同様にメアド認証を挟む
って書きました
APIは文字列が日付依存なのをランダムな値にするって書くのと迷いました
2024.10.13 15:22
おちたさん(No.4)
求職者のidが日付から生成されるのはまずいってことでランダムに生成するように書きました。。。
2024.10.13 15:23
pdさん(No.5)
僕は最後
・有効期間内のAPIkeyを無効化できるようにする
・パスワード認証の連続失敗で制限がかかるようにする
にしました。
模範解答がなんなのかすごく気になりますね…
・有効期間内のAPIkeyを無効化できるようにする
・パスワード認証の連続失敗で制限がかかるようにする
にしました。
模範解答がなんなのかすごく気になりますね…
2024.10.13 15:23
ぱせりさん(No.6)
お疲れ様でした。
自分はラストの問題、
社員証などでその企業の担当者であることを証明するなど、多要素認証にする。
1利用者のAPIkeyの発行を複数としない。
と書きました。複数所持できるなら、有効期間の意味がないのでは?と思ったのですがどうでしょうか。
自分はラストの問題、
社員証などでその企業の担当者であることを証明するなど、多要素認証にする。
1利用者のAPIkeyの発行を複数としない。
と書きました。複数所持できるなら、有効期間の意味がないのでは?と思ったのですがどうでしょうか。
2024.10.13 15:25
レッドぽちさん(No.7)
利用者のIDは数種類の文字種を使って、規則性のない割り当てをするって書きました
あとAPIkeyは複数発行しない
あとAPIkeyは複数発行しない
2024.10.13 15:32
すこさん(No.8)
gとhが全然わからなかった
gはインジェクション文字列を会社名のところに入力、hはAPIを新しく発行と書いたけど自信ない
gはインジェクション文字列を会社名のところに入力、hはAPIを新しく発行と書いたけど自信ない
2024.10.13 15:42
はつさん(No.9)
ghはそれしかないと思ってました。
いや、正確にはapiで発行しなくても既存一覧表示でも良いなとは思いましたけど、些細な違いだと切り捨てました
いや、正確にはapiで発行しなくても既存一覧表示でも良いなとは思いましたけど、些細な違いだと切り捨てました
2024.10.13 15:47
おーんさん(No.10)
gは図Bの手順1~3を実行
hはAPIKeyを新規発行
ぶっちゃけhは全然分からん
hはAPIKeyを新規発行
ぶっちゃけhは全然分からん
2024.10.13 15:51
しげるさん(No.11)
gh、多分これだろなって頭に入れてたとこが前後の手順で書かれてて
やることないじゃん!ってビックリしたあと長考して図3の文字列とKey再発行にしました
ここで時間取られて最後の問題の時間配分キツかった〜
やることないじゃん!ってビックリしたあと長考して図3の文字列とKey再発行にしました
ここで時間取られて最後の問題の時間配分キツかった〜
2024.10.13 15:53
spfさん(No.12)
gfはそれしかないと思いました
私は新しいapi発行するのではなく、既存のものを取得にしました。
ab はみなさん何にしましたか
私は新しいapi発行するのではなく、既存のものを取得にしました。
ab はみなさん何にしましたか
2024.10.13 15:54
あいうさん(No.13)
この投稿は投稿者により削除されました。(2024.10.13 16:02)
2024.10.13 16:02
あいうさん(No.14)
a:ア
b(省略).jp/
c:利用者IDとPWが入力されてログイン
d:他の画面遷移と使用するセッションIDを別にする
にしました
b(省略).jp/
c:利用者IDとPWが入力されてログイン
d:他の画面遷移と使用するセッションIDを別にする
にしました
2024.10.13 16:03
すこさん(No.15)
X-content-type-options違ってた
content-typeの内容書いてた…
同じです
dは変更と書きましたが、新しいものの方が確かにいいかも…
content-typeの内容書いてた…
>13
同じです
dは変更と書きましたが、新しいものの方が確かにいいかも…
2024.10.13 16:04
monkeyさん(No.16)
i.jのwebAPIの仕様改善って何なんだ
APIkeyを期間内に一つのユーザーにつき一つしか発行できなくすればいいのか?
APIkeyを期間内に一つのユーザーにつき一つしか発行できなくすればいいのか?
2024.10.13 16:16
はつさん(No.17)
最後の丸投げ問題、どんな採点基準になるんだ?
もっとも有効な対策を一つって書いてましたけど、契約時のkey一つにするのと、アクセス元制限つけるの二つ書いちゃったw
もっとも有効な対策を一つって書いてましたけど、契約時のkey一つにするのと、アクセス元制限つけるの二つ書いちゃったw
2024.10.13 16:21
おちたさん(No.18)
Strict-Transport-Securityが分かんなくて落としたけどHSTSのことらしくて泣いた
基礎力足りてないなぁ
APIの仕様改善はAPI keyだけじゃなくて利用者IDもAPI要求時に確認するって書きました……が全く自信なし
模範解答発表までずっと悶々としそうです……
基礎力足りてないなぁ
APIの仕様改善はAPI keyだけじゃなくて利用者IDもAPI要求時に確認するって書きました……が全く自信なし
模範解答発表までずっと悶々としそうです……
2024.10.13 16:26
はつさん(No.19)
X-content-type-optionsって午前で出てたんで、逆にクリックジャッキングを防ぐって書きましたけど、詳細は分からなかった、、、
2024.10.13 16:32
spfさん(No.20)
aが、アの理由ってなんでしょう、、イだとおもいました、、、
2024.10.13 16:37
あいうさん(No.21)
ログイン情報なくてもセッションID取ってこれるのがアかなと思ったんで……全く分かりません
2024.10.13 16:43
まいことさん(No.22)
P33の注記1を読んでログイン前に02画面にアクセスしたら(できたら)エラー画面になると思って、aをアにしました。
2024.10.13 16:46
はつさん(No.23)
二つ目か三つ目の「a」でログインさせようとしてたのでアにした気がします
2024.10.13 16:50
ぽちろさん(No.24)
aはイにしました。ログイン成功した後にセッションID変わってれば例の不正ログイン防げるわけで。
最後の改善案は、WebAPIのIP制限と、MFA導入にしました。
最後の改善案は、WebAPIのIP制限と、MFA導入にしました。
2024.10.13 16:52
おにぎりがつぶれたさん(No.25)
設問3ですが
API
方針:APIの改善は電子署名を利用する
理由:APIkeyが漏洩しても秘密鍵が漏れない限り悪用されないから
WebApp
方針:登録内容やパスワードの変更時に現在のパスワード入力を要求する
理由:パスワードを知らない攻撃者に変更させないため
と書きました
APIはAPIkeyの一致だけで正当な利用者と判断しているところ、WebAppはパスワードの再設定にパスワードを要求していないところが問題かなという判断です
API
方針:APIの改善は電子署名を利用する
理由:APIkeyが漏洩しても秘密鍵が漏れない限り悪用されないから
WebApp
方針:登録内容やパスワードの変更時に現在のパスワード入力を要求する
理由:パスワードを知らない攻撃者に変更させないため
と書きました
APIはAPIkeyの一致だけで正当な利用者と判断しているところ、WebAppはパスワードの再設定にパスワードを要求していないところが問題かなという判断です
2024.10.13 16:53
zvq10423さん(No.26)
この投稿は投稿者により削除されました。(2024.10.13 17:39)
2024.10.13 17:39
バルーンフェスタさん(No.27)
自身ないけどこんな感じで書いた。
API
APIの発行1個だけにして漏洩時は削除を可能に
今のままだとなすすべがないから
WebApp
固定セッションIDはやめる
ハイジャックされるから
APIの有効期間が14日って自分は短く感じたから書けなかったけどどうなんでしょうね。
API
APIの発行1個だけにして漏洩時は削除を可能に
今のままだとなすすべがないから
WebApp
固定セッションIDはやめる
ハイジャックされるから
APIの有効期間が14日って自分は短く感じたから書けなかったけどどうなんでしょうね。
2024.10.13 19:05
初受験さん(No.28)
WebAppの方は、図にCSRFありなしが敢えて描かれていたので、ログインCSRFで攻撃者のセッションでログインしてしまうことが問題だと思ってました
2024.10.13 20:41
初セキスペさん(No.29)
図にCSRFの線があったので、CSRFトークンを発行するにしました。
多要素認証も考えたけどサーバの追加がいるのでちょっと大掛かりすぎるかなと思いました。
多要素認証も考えたけどサーバの追加がいるのでちょっと大掛かりすぎるかなと思いました。
2024.10.13 20:55
X8bWwさん(No.30)
APIkeyの有効期限、14日間ってかなり微妙な数字ですよね...どういう使い方を想定してこの数字になったのか...
自動で定期実行するようなケースなら有効期限は1年とかにしておけば便利だし慎重に取り扱われると思う。
逆に手動で動かすプログラムに入れるために都度発行するにしては長すぎる。
この数字だとユーザーの手間は増えるし、そのせいで扱いも雑になりそうだしでアンチパターンだと思うんですよね。
自動で定期実行するようなケースなら有効期限は1年とかにしておけば便利だし慎重に取り扱われると思う。
逆に手動で動かすプログラムに入れるために都度発行するにしては長すぎる。
この数字だとユーザーの手間は増えるし、そのせいで扱いも雑になりそうだしでアンチパターンだと思うんですよね。
2024.10.13 21:45
言葉遊びはクソ問さん(No.31)
APIKeyの細かな権限管理:各 API キーに特定の権限を割り当て、特定のデータ(例えば三か月以内の特定の属性)へのアクセスを制限。→ 今回の攻撃で全てのデータが漏洩するおそれがあるため、その最悪を防げる。
2024.10.13 23:54
初受験さん(No.32)
APIの方は、現仕様に問い合わせなどがあった求職者IDを取得と、任意の求職者IDで情報取得でき、求職者IDが連番と書かれていたので、連番にしないにしました。
連番だと問い合わせない求職者IDでも順番に試せば情報取得できてしまうので。
その意味では、問い合わせのあった求職者IDのみに限定でも良い気がしてきました。
連番だと問い合わせない求職者IDでも順番に試せば情報取得できてしまうので。
その意味では、問い合わせのあった求職者IDのみに限定でも良い気がしてきました。
2024.10.14 17:18
mindcさん(No.33)
攻撃者のがAPIKeyの閲覧と新規発行のどちらをするかですが、登録済みのAPIKeyは
①被害企業が日時範囲を制限している可能性がある
②14日以上経過し、失効している可能性がある
という理由で、新規発行画面への遷移としました
①被害企業が日時範囲を制限している可能性がある
②14日以上経過し、失効している可能性がある
という理由で、新規発行画面への遷移としました
2024.10.14 17:40
焼き鳥さん(No.34)
ijklは何でも正解!ボーナス問題と思ってるけど違いますかね。
jwt認証を追加する→認められた接続元のみ許容し不正利用を防ぐ
多要素認識を追加する→認識機能を強化して不正ログインを防ぐ
間違いではないでしょう??
jwt認証を追加する→認められた接続元のみ許容し不正利用を防ぐ
多要素認識を追加する→認識機能を強化して不正ログインを防ぐ
間違いではないでしょう??
2024.10.15 23:27
お疲れ様でしたさん(No.35)
私もそのようなことを書きました
aは私はイとしたのですが、皆さん何選びましたか
bはb(省略).jp/としました
aは私はイとしたのですが、皆さん何選びましたか
bはb(省略).jp/としました
2024.10.15 23:36
焼き鳥さん(No.36)
gはメールヘッダーインジェクションを行う必要がありますね。その上で検査文字列そのままではなくtoのアドレスは攻撃者である必要があります。で、攻撃者メアドに送られた確認メール内のリンクを押下して反映されるメアドはインジェクション文字列なので今度は普通に攻撃者メアドで変更する流れです。
hは発行してもいいし確認でもいいと思いました。確認だとダメな理由が見当たりませんでしたので両方書きました。字数制限があったら発行にしてたと思いますを
hは発行してもいいし確認でもいいと思いました。確認だとダメな理由が見当たりませんでしたので両方書きました。字数制限があったら発行にしてたと思いますを
2024.10.16 22:25
skさん(No.37)
問4のiって、
問い合わせした企業のみ、属性情報を見れるようにする、じゃダメなの?
ランダムな文字列にしても見えるんじゃ意味なくない?
問い合わせした企業のみ、属性情報を見れるようにする、じゃダメなの?
ランダムな文字列にしても見えるんじゃ意味なくない?
>TACの過去問を見た感想
2024.10.17 18:23
むぐむぐさん(No.38)
skさん
世の中のセキュリティはランダムな文字列に頼っているんです。
パスワードもランダムな文字列ですし、暗号に出てくる鍵もランダムな文字列です。
十分な桁数と文字種があればランダムな文字列をあてることは天文学的な確率になり、総当たりにも実現不可能な時間がかかります。
この状態のことを安全としているんです。
予想にはなりますが回答の幅は広そうなので、ある程度技術的に具体的な実現方法が提示できていればいいのではないでしょうか?
>ランダムな文字列にしても見えるんじゃ意味なくない?
世の中のセキュリティはランダムな文字列に頼っているんです。
パスワードもランダムな文字列ですし、暗号に出てくる鍵もランダムな文字列です。
十分な桁数と文字種があればランダムな文字列をあてることは天文学的な確率になり、総当たりにも実現不可能な時間がかかります。
この状態のことを安全としているんです。
>問い合わせした企業のみ、属性情報を見れるようにする
予想にはなりますが回答の幅は広そうなので、ある程度技術的に具体的な実現方法が提示できていればいいのではないでしょうか?
2024.10.17 20:32
橙色文書さん(No.39)
受験していないのでいまごろ問題を読み終わりました。
改善案は「効果があり」「実現可能で」「新たな脆弱性を生じない」答案であれば得点できるでしょう。
利便性が大きく下がったり、効果に見合わないコストがかかるような案は減点や無得点になるかもしれません。
持ち時間が各問70分ほどしかないのに画面遷移の遷移先が番号になっている箇所がありますから、3色か4色ボールペンの持ち込みが許可されなければ問4は選択する気になれません。
改善案は「効果があり」「実現可能で」「新たな脆弱性を生じない」答案であれば得点できるでしょう。
利便性が大きく下がったり、効果に見合わないコストがかかるような案は減点や無得点になるかもしれません。
持ち時間が各問70分ほどしかないのに画面遷移の遷移先が番号になっている箇所がありますから、3色か4色ボールペンの持ち込みが許可されなければ問4は選択する気になれません。
2024.10.29 20:14
しょがくしゃさん(No.40)
API
送信元の検証を追加する
APIキーが意図せず流出した際の影響を軽減するため
WebApp
APIの使用履歴を確認できる画面を追加する
意図しないAPIの利用を検知できるように
といったニュアンスの回答をしたのですが、さすがに部分点も貰えないですかね...
送信元の検証を追加する
APIキーが意図せず流出した際の影響を軽減するため
WebApp
APIの使用履歴を確認できる画面を追加する
意図しないAPIの利用を検知できるように
といったニュアンスの回答をしたのですが、さすがに部分点も貰えないですかね...
2024.10.30 12:53
いまだけネスペ落ち美さん(No.41)
結局WebAPI側の改善策は図3で受け渡しされてるパラメータ関連の改善、Webアプリ側の改善策は図3の仕様そのものの改善を挙げればよかったってことなんですかね?ゆっくり解き直してたらWebAPIとWebアプリの区別が付かなくなってきました…(大沼)
こういうのに強い方いらっしゃったら教えて下さると嬉しいです
こういうのに強い方いらっしゃったら教えて下さると嬉しいです
2024.10.30 20:03