皆さんの回答も教えていただきたいです！
分からないところの質問などもし合いましょう！
私は知識がなかったのでほとんど勘ですが、載せておきます。
(文章問題はきちんとメモってないので、文字数は気にしないでください)

設問1
  (1)a:コンテンツ(完全な勘)
  (2)b:DoS
  (3)c:CNAME(完全な勘)
  (4)Y-CDN-U-FQDNに割り当てられているWebサイトと、転送先のWebサイト
設問2
  (1)STの発行には認証サーバの鍵を使用しておらず、検証ができないから
  (2)攻撃者が作成したハッシュ値とSTの鍵を比較してパスワードを総当たりするから
設問3
  (1)e:エ
  (2)f:ア
  (3)g:改ざん
  (4)h:1  i:3  j:4
設問4
  (1)k:ウ  l:イ  m:ア
  (2)n:エ
  (3)o:3  p:5
  (4)q:エ
設問5
  (1)r:オ  s:エ  t:ウ
  (2)u:5
  (3)v:イ
  (4)w:認証要求  x:IDトークンの署名

設問1
  (1)a:エッジ
  (2)b:DDoS
  (3)c:host

にしました。

自信は無いです。
午後2問2 
設1 
(1)キャッシュ
(2)DoS 
(3)Host 
(4) Y社Webサイトのうち、Y-CDN-U-FQDNが割り当てられているサイト
(5) Y-CDN-U-FQDN？
設2 
(1)STの処理はアクセス対象のサーバで行われるから 
(2)奪取されたSTへの攻撃時に、ログイン試行が行われないため
設3 
(1)ウ (2)ア (3)改ざん(4) h:1 i,j:2,4 
設4 
(1)k:ウ l:イ m:ア (2)エ (3)o:3 p:5 (4) ウ 
設5 
(1)r:オ s:エ t:ウ (2)8 (3) イ (4)w:トークン要求 x:APIを使った投稿

設1 
(1)コンテンツ (キャッシュだと思われ)
(2)DoS 
(3)- (Hostと思われ)
(4) CDN-Uに割り当てられたwebサイト(意味わからん)
(5) 接続先のIPアドレス(意味わからん)
設2 
(1)偽造したSTは認証サーバに送信されないから
(2)ローカルで総当たり攻撃を実施可能であるため
設3 
(1)ウ (2)ア (3)改ざん
(4) h:1, i:3, j:4 
設4 
(1)k:ウ l:イ m:ア 
(2)エ 
(3)o:1 p:6 
(4)ウ 
設5 
(1)r:オ s:エ t:ウ 
(2)8 
(3) イ 
(4)w:トークン要求 x:トークン応答

いやーこれは厳しいですよね...

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

その2

設2 
(1)パスワードハッシュ値がアクセス対象のサーバ内に保管されているため。
(2)総当たり攻撃はオフラインで実行できるため。

設問4
  (1)k:ウ  l:ア  m:イ

にしました。

グループウェアのリソースに対する認可要求だと思いましたので。。。

私も「ウ、ア、イ」(従って設問4はウ)としました...

設問2(2)
STへの総当たりパスワードクラックが成功し復号に成功した時点でパスワードは入手済みという理解で
「入手済みのパスワードを固定し、IDを変更してログインを試行するから」としました。(所謂リバースブルートフォース攻撃がアカウントロックされないのと同じ理屈です)

kerberosチケットの脆弱性を2つに分けて解説しているので

ST偽造の脆弱性
STに対する総当たり攻撃の脆弱性

については切り離して考えるべきではないでしょうか?

チケット類はパスワードハッシュがあれば偽造できてしまいます。

TGTのパスワードハッシュはKDC(TGSを兼ねる認証サーバ)でのみ管理されています。(もちろんSTを作成するためのハッシュも管理しています)

STのパスワードハッシュはサービスを提供するサーバでも管理されていますので、サービスサーバへの不正アクセスで抜き取られてしまう可能性があります。

設1 
(1)キャッシュ
(2)DDOS 
(3)Host
(4)CDN-Uを利用している全てのwebサイト
(5)Y-FQDN
設2 
(1)STを検証するのは認証サーバでなく各サーバだから
(2)ローカルで総当たり攻撃を実施可能であるため
設3 
(1)ウ (2)ア (3)改ざん
(4) h:1, i:3, j:4 
設4 
(1)k:ウ l:イ m:ア 
(2)エ 
(3)o:3 p:7 
(4)ウ 
設5 
(1)r:オ s:エ t:ウ 
(2)8 
(3) イ 
(4)w:IDトークン x:認証要求

設4(1)は、利用者情報のやり取りとあるので
GrW-Gの利用者と解釈してSサービスとの間でデータ連携すると考えました。

IDaaSが絡むOAUTHのフローって関心があって試験前に色々調べたんだけど、調べきれなかったから、この設問は間違っていても非常に参考になるよね。

設問1の(2)はDoSでもDDoSでも良い気がするのですが、どう思いますか？
回答いただけると助かります。

設問1の(2)はDoSでもDDoSでも…

上記ですがCDNで対策になる、ということなので、DDoSかと思いました。

DoSなら送信元IPアドレスでブロックできるため、CDNでなくてもいいのかな、と。

少なくとも半分くらいはあたってそうですね｡

設問1 (1)コンテンツ
      (2)DDoS
      (3)HOST
      (4)Y-FQDNを使用しているすべてのY社Webサイト
      (5)宛先IPのFQDN
設問2 (1)STの検証はGrWサーバで行っているため
      (2)STの復号を行っており､サーバには行っていない
設問3 (1)オ
      (2)ア
      (3)改ざん
      (4)1､3､4
設問4 (1)ウ ､ イ ､ ア
      (2)エ
      (3)8､6
      (4)ウ
設問5 (1)オ ､ エ ､ ウ
      (2) 8
      (3) イ
      (4) ペイロード ､ IDトークン

設問4-(3)と設問5-(4)が見事にバラバラの回答ですね｡

神が降臨して説明いただけると助かります｡

以下､自分の考え
設問4-(3)
｢o｣と｢p｣の前後の文から､認可コードの照合をおこなうと読み解き､
端末側からの認可コード(6)と認可元であるIDaaS(自分の場合は｢l｣)からの､
トークン応答(8)となった｡
で､なんか付与している｢o｣をトークン応答(8)､送られてきた｢p｣を認可コード(6)にしました｡

設問5-(4)
｢x｣と｢w｣で違う言葉だけど､｢~に含めて送信｣｢送られてきた~｣なので､その前に記述された､
IDトークン関連と推察｡
nonce値とか言うのをどこに入れるか → 署名されたペイロード
送られてきたなにに含まれている → ペイロードは使用済みなのでIDトークン

ついでなんでハイブリットフローについて､調べてみたら個人で事細かにまとめてる人がいて､
レベル4試験(最上位)って何･･･｡って感じになりました｡

設問4-(3)
o: 2, p: 6

(2)
“利用者のwebブラウザが攻撃者によって生成された認可コードを受け付けてしまう実装”とあるので、この攻撃者の認可コードを送信したタイミング(6)で同時にstate値を送り、k(sサービス？)で事前に発行したstate値(2)と比較します。

(2)を選んだのは、csrfトークンの考え方に基づいています。つまり、事前にsサービスからブラウザに対してトークン(state)を送付する事で、トークンを知らない第三者が勝手にsサービスに通信を開始できなくなると考えました。

設問1 (1)キャッシュ
      (2)DDoS
      (3)HOST
      (4)CDN-Uをコンテンツの中継サーバとして利用する全てのWebサイト
      (5)外部DNSサーバに問い合わせたFQDN
       → Y-FQDNに限定せず、Hostヘッダの値と宛先のFQDNが違う場合は拒否で良いのかなと思いました。

設問2 (1)STの復号および検証はGrWサーバで行うため
      (2)STのパスワードハッシュを解読すればよく、サーバに依存しないため
設問3 (1)ウ
      (2)ア
      (3)改ざん
      (4)1､2､4
設問4 (1)ウ ､ イ ､ ア
      (2)エ
      (3)2､6
      (4)ウ
設問5 (1)オ ､ エ ､ ウ
      (2) 8
      (3) イ
      (4) クエリパラメーター､ IDトークン(openID connectを調べてみました、矢印だと2と8)

1(4)の解答ですが、
CDN-Uを利用しているY者のサイトと攻撃者サーバのサイトも見れなくなると思います

無難に行くなら
設問5  (4) 認証要求､ IDトークン

自分はIDトークンを図から判断して
トークン応答と書いてしまった

nanceは
コードを要求したクライアントアプリと
トークンを利用するクライアントアプリが
同一であるか
を判断するための値らしい。

横取りされたコードで発行されたトークンはnanceが不整合になるらしい

間池溜さん、
ということはクライアントアプリはX動画サービスなので
トークン要求、トークン応答(IDトークン)になります？

自分もそう書いちゃったけど
コードを要求している段階は、(クライアントアプリのリダイレクトによる)認証要求のときなのです。

そうですよねー
私も記号ばかりで焦ってそう答えてしまいましたー
当落線上な気がするので、祈るしかないですね、、

試験前webでOAUTHやらOpenIDやら気になって調べたけど、読んでもいまいちピンと来なかったが、この試験の内容はwebの解説を読み解くのにとてもいい足がかりになった。
自分も設問4,5はそんなに取れなかったけど、とても腑に落ちている。

> 間池留さん
nonce値自体は図の通信2:リダイレクトのリダイレクトurlのクエリパラメーターに設定されるが、このリダイレクトurlは図の通信3:認証要求で用いるため、「認証要求」が無難って解釈ですかね？

うーん

クエリパラメータだとどの段階のクエリパラメータかぼやけるような気がする。

リダイレクトによる認証要求だからね。

>間池留さん
そこなんですよね。図でリダイレクトと認証要求が別々の矢印で書かれてるからややこしい…
リダイレクトによる認証要求時にnonce値をパラメータ設定する事を問う問題だと思うので、仰る通り認証要求で良いのかもですね。

でも、そう考えると、nanceもPKCEもやってることほぼ一緒だよね。乱数の不整合をクライアント側で(トークン応答内の乱数を)チェックするか、サーバ側で(トークン要求内の乱数を)チェックするかの違いくらいか。

設問1
（4）CDN-Uによって割り当てられたY-CDN-U-FQDNとCNAMEで紐付けられたFQDNに対応するすべてのWebサイト
(5)外部DNSサーバへの名前解決で返ってきたFQDN

どうですかね、、

SC初心者さん、間池留さん

2，6 、認証要求、IDトークンで正しそうですね。
ご覧になられているかもしれませんが、
「30分でOpenID Connect完全に理解したと言えるようになる勉強会」というので、
丁寧に説明されていました。

設問1 (4)
”Y-CDN-U-FQDNを名前解決したIPアドレスを拒否”とあるので、このIPはCDN-Uの事だと考えました。結果、X,Y,Z社サイトを含む、全てのCDN-Uを利用するWebサイトに繋がらなくなると思ったのですが、どうなんでしょう？

設問1(4)
私は「Y-CDN-U-FQDNのIPアドレスと同じIPアドレスをCDN-Uから割り当てられているWebサイト」と答えました。
SC初心者さんと同じ解答ですかね？

設問1(4)
私は「Y-CDN-U-FQDNで名前解決されたIPアドレスのサーバにキャッシュされたWebサイト」
しました。

ほぼ一緒かな。

ただ、IPアドレスを割り当てられているのはCNDのキャッシュサーバです。あくまで各webサイトにCNDから割り当てられているのはFQDN。

細かすぎますかね。

このCDNのコネクトバック通信の脆弱性の問題で一つ疑問に感じたのは、

Y社のwebページに頻繁にアクセスしている前提なのに、何故キャッシュサーバにＹ社のwebページキャッシュされてないの??問題

キャッシュされていれば、攻撃者のサイトには転送されないよね?

みんな思わなかった?
条件の見落としあったらすまない!

マルウェアは、Ｙ社の存在しないコンテンツを指定すればいいだけなのかな。

設問1の(5)って答えわかります？

HTTPリクエストラインのFQDNとか?

宛先FQDNとか、名前解決でDNSサーバから得たFQDNってかんじですかね？
このあたり詳しくなくて調べてもわかりませんでした、、

まぁ、解答欄が25ほどあるので
難しい、OAUTHやOIDCあたりの記号問題は一回答4点以下は確実でしょうか。。。どうしたって記述問題のウェイトは高くなりますので。

下手したら一回答２点とかも

部分点に期待ですね。

宛先FQDNが無難なのかなと思いました。名前解決でDNSサーバから得たFQDNだとCDN-Uが各webサイトに設定されたFQDNの事を指してしまうかなと。
私は、要求時のFQDNのイメージで「外部DNSサーバに問い合わせたFQDN」と書いたけどどうなんだろう…？

私は「TLS接続先のFQDN」と書きましたが、同じっぽいですかね？

> かたさん
微妙なラインですよね、
図5によると、TLS接続はXPCとCDN-U間なのでCDN-Uが保有するFQDN(*-U-FQDN)を指していると解釈される可能性があると思います。
ただ、どこまで書くべきなのか…？(具体的にするなら、オリジンサーバーのFQDNとか？)

設問1の問5は、私も外部DNSサーバに問い合わせた際のFQDNとしました。

問4が分からなくて
CDN-Uによって割り当てられたY-CDN-U-FQDNとCNAMEで紐付けられたFQDNに対応するすべてのWebサイトとしましたが、どうなんでしょう。

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

ITECで午後2解答速報出ましたね。正答率ちょうど6割・・・

最初DDosじゃなくてDosじゃだめかな

ITECの解答速報みました。精度高そうだなって印象です。
問1の（5）の解答案は本文中にもある言葉ですね。
記述であってそうと自信もてるのは2の（1）くらい。2の（2）もオフラインのニュアンス伝わらない書き方だと部分点もほとんどこなそう。

DDoSはDoSの一部だしDoSでも丸来るんじゃないですかね。
DDOSと書いたので減点されないか不安です。DDoSともDDOSとも読めそうな微妙な大きさで書いたけど。

設問1の(4)って要は
CDN-UによってY-CDN-U-FQDNが割り当てられた全てのWebサイトってことですかね？

複数の回答を記入させる、もしくは複数の選択肢を選ばせる設問は部分点はあるのでしょうか？
例えば、今回の午後Ⅱ問2の場合、設問3の(4)や、設問5の(4)の「W」しか正解していない場合などです。

この投稿は投稿者により削除されました。(2022.04.20 19:33)

問1 (4)
解答速報見て、CDN-UをCDN内の１つのキャッシュサーバーと勘違いしていた事に気づきました…つまり、CDNの複数あるキャッシュサーバの内、Y-CDN-U-FQGNが割り当てられたキャッシュサーバー宛の通信が遮断されるという事ですね。

設問1の(4)でエンジニア志望さんが言っている、
CDN-Uによって割り当てられたY-CDN-U-FQDNとCNAMEで紐付けられたFQDNに対応するすべてのWebサイトも概ね点数もらえるんじゃないですかね。

設問1の4
Y-CDN-U-FQDNを経由するY社webサイトを含むWebサイト

だと全く意味違ってきますでしょうか？。。。

DDosじゃなくてDosにしてもーた。

1-5
「サーバ名」とFQDNは同義ですかね？
FQDNと書いたんですが、、

この投稿は投稿者により削除されました。(2022.04.21 11:46)

aaaさん
残念ながら別物です
www.abc.co.jp
とあったら
wwwがサーバ名(ホスト名)、abc.co.jpがドメイン名、www.abc.co.jpがFQDNです

CDNについて、教えていただきたいのですが、
1つのキャッシュサーバ(=IPアドレス)に複数のサービス利用者のキャッシュが格納されている。
(=CDN-UがY社以外も利用する)
って言うのが調べてみてもはっきりしませんでした。

ここについて解説されている記事など有りましたらタイトルとか教えていただけないでしょうか?

設問3  (4)
[1､2､4], [1､3､4]で分かれていますが、どちらが正しいと思いますか？

自分は[1,2,4]派ですね～。結果論ですがどちらも4が入ってるということはIDaaSが処理3で使った証明書がSaaSに共有されていることになりますし、あと必要なのはIDaaSが信頼されたSaaSかどうかを確認するSaaSの証明書な訳でそれが必要なのは処理2ってことになるって思ってます。
間違ってたら指摘お願いします

>設問3  (4)
>[1､2､4], [1､3､4]で分かれていますが、どちらが正しいと思いますか？

私は、つい反応して[1､3､4]と書きましたが、
「処理２」でIDasSがSaaSの認証を行う。
「処理４」でSaaSがIDasSの認証を行う。
と考えたら、[1､2､4]が正しいのでは無いかと思います。
（
試験中には、デジタル署名に反応して、手が滑りましたが）

SAMLの場合、証明書はあくまでIDaaSの発行したアサーションの正当性を検証するものなので、SaaSは直接関係ないですね。

証明書はSAMLResponseに含まれるのでiは3ではないでしょうかね。処理4では処理3で含めた証明書のパスの検証もするでしょうね。

ちょっと調べた限りでは、IdPがSPの信頼関係を確認するのは予めIdPに登録されたSPのメタデータを参照するようです。

処理2の「信頼関係が構築されたSaaSからの認証要求であることを検証する」ってのに事前共有した証明書使ってるんじゃないですか？
処理3は利用者(XPC)との認証処理と処理4で検証してもらうための署名付与かと。

つまるところ、
信頼関係の確認と、要求応答の真正性と完全性の確認は切り離すべきかと。

信頼関係のないSPからの要求の真正性、完全性が確認できても仕方ないですからね。

信頼関係ありきの真正性、完全性です。

sodeさん

証明書と署名は別物です。

上記問題に関して、私も3.4派ですね。
共有という観点で発行側と検証側の処理どちらにも必要かと。

別物なのはわかってますよ。だからこそ処理3で証明書使ってなくない…？ってなったわけで。

Responseに証明書を含めるという意味で利用するということにはなりませんかね?

レスポンスに付与する署名作成に証明書使ってるみたいなイメージですか？
そうなると処理2の検証って何使ってるんだろう…
自分もこの辺あやふやなんで証明書周りもう少し勉強しないとなあ

あと、処理2の第２項目と処理4の第1項目で同じことを行っているのだとしたら、明らかに表現が異なるのはおかしいですよね。

処理2信頼関係の検証はSPがIdPに事前に登録したメタデータを使うらしいです

>レスポンスに付与する署名作成に証明書使ってるみたいなイメージですか？

レスポンスに付与する署名の検証のために証明書も一緒に添付するイメージです。

「SAML リクエスト 署名」で調べたらSAMLリクエスト内に署名つけて検証する仕組み自体はあるみたいです。なので処理2の検証も可能ではあります。
お互いにお互いを検証するってやり方ならこの仕組み使って検証してそうかなと思いましたがどうでしょうか。

確かにそれで、要求の真正性と、完全性は検証可能かと思いますが、要求の署名はオプションであり実装されないことも多々あるといいます。

加えて、処理2には要求の検証がありません。

処理2には要求の署名検証がない。

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

メタデータによる信頼関係の検証→SP証明書による署名の検証(オプション)の流れでしょうか。

白熱した議論中に失礼致します。

絶対間違っていると思うのですが、自分は設問３（４）を
「h=3」「i=1」「j=2」にしてしまいました。

深く考えた訳ではなく、アサーションの属性共有とフォームの送信、が処理３にあり、
デジタル証明書が必要なのは処理１と処理２かな？と本当に何も考えず書いてました。

横紙破りでしたらすみませんでした。

レスポンスには基本署名だけで証明書の値も付与自体はできるけど普通はSPに証明書が保存されてるから不要とありましたが…
でも調べたらなんとなくわかりました。署名付与するのにどの署名使うのかってところで証明書いるよねってことですかね。

今回の試験はある意味試金石ですね。
認証のフローに加えて、まさにセキュリティ確保のためのパラメータまで深掘されて問われる。

とても良い設問でしたね。state、nonce、PKCEはノーマークもいいところでした。とても参考になりました。いい勉強代でした。設問4,5はおそらく半分くらいしか取れてない。

> 間池留さん

zennのSAMLの証明書更新のお話という記事を読んで、「要求の署名はオプションであり実装されないことも多々ある」これが腑に落ちました。ただ、処理2では「信頼関係のあるSaaSからの認証要求であることを検証」する必要があるので、今回のケースではSPの証明書を用いた検証が必要だと考えました。
処理3では、sodeさんの仰る通り、Responseに含める事が必須ではないと思います。(もちろんIDaaS側でも、どこかのタイミングで証明書を保存しているとは思いますが...)

正直、信頼関係の検証に証明書が必要であるかは仕様なのかは分かりません。

自分は、信頼関係の検証はメタデータ
応答、要求の真正性、完全性の検証は証明書

と割り切ってしまっています。

もし、リクエストに署名が付されているとしたら、処理2でリクエストの真正性、完全性の検証が問題中で全く触れられないのは不自然ですよね?

訂正

信頼関係の検証はメタデータ
アサーションの真正性、完全性の検証は証明書

> 間池留さん 
真正性や完全性周りですよね。

個人的には、信頼関係の検証=真正性(相手がなりすましでないこと)の検証であり、これは証明書によって確認可能だと思っていました。証明書付きメタデータを事前に交換し、処理2で証明書の公開鍵を利用して署名付リクエストの真正性を確保する形です。

署名付きリクエストの完全性に触れて無い点については、確かに不安です…

あと、技術的な問題として、署名をリクエストのクエリ文字列に埋め込められるかですよね。
普通はPOSTになるかと思います。

wikiより

アイデンティティ・プロバイダは、ブラウザを介してサービス・プロバイダから<samlp:AuthnRequest>要素を受け取る。アイデンティティ・プロバイダはどのようにして、サービス・プロバイダが本物であり、ユーザーに関する個人を特定できる情報を採取しようとしている悪質なサービス・プロバイダではないことを知るのか。ID プロバイダは、認証応答を発行する前に、メタデータ内の信頼できるサービス・プロバイダのリストを参照する。


ここからは私の推測

その上で、署名は信頼できるSPからのリクエストであり改ざんされていないことを検証するものと推測できます。

「メタデータ内の信頼できるサービス・プロバイダのリストを参照」
→これは、証明書を用いた検証があってこそ成立すると思います。(例えば、sp-aが信頼できるリストに入っていても、何をもってsp-aからのリクエストと判断するのでしょうか？)
メタデータ内に証明書があって、それで署名を検証することで信頼関係の確認ができると考えた方が自然かなと思いました。

SAMLを使ったSSOの挙動とSAML Response、SAML Requestの概要

で紹介されていますが、SAML Responseにも証明書は添付できる仕様のようですが、
これも、あまり使われることのないオプションのようですね。
signitureタグのX509Certificate属性
ただ、証明書送ってくれた方が、SPの方で有効期限の心配をしなくていいですよね。

正直分からんですね。。。
Requestの署名もResponseの証明書もレアケースに分類されるようで。。。

参考までに
このようなIdPもあります

AuthnRequest 要素内の Signature 要素は省略可能です。 Azure AD では、署名がある場合は署名済みの認証要求の検証を行いません。 要求元の検証は、登録されている Assertion Consumer Service の URL に応答することによってのみ提供されます。

署名を用いない、緩い？検証もあるということですね。

こうなると、ほんとに分からないですね。2、3両方正解ってないですかね

つまるところ、Azure ADはリストにあるSPの（リダイレクト）URLに応答することでTLS通信が成立すれば、その時点でSPが妥当なサーバ証明書を保有していることが担保されるということでしょうか？
そうなると、SPのサーバ証明書を共有する必要はないということになります。

TLS通信が成立しない=信頼関係のないSPからの要求

の（不整合）検証はやはり処理2ですることになるでしょう。

「キャッシュ」サーバを「プロキシ」サーバと書いたらダメですかね…?

>「キャッシュ」サーバを「プロキシ」サーバと書いたらダメですかね…?
→キャッシュかエッジなら大丈夫だと思います。
  プロキシだとダメでしょうね。リバースプロキシならCDN企業目線として言わんとしてる事はまだ伝わりそうですが文字数オーバですね。