ToppyMicroServices

RFC 3986 Quiz

URIのコンポーネントとエンコード

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 3986はURIのgeneric syntax, reference resolution, comparison methodを定義します. security profileは, authorizationで受理するURI formと有効なequivalence ruleを別途定義する必要があります.

Q1: URIでauthorityが存在する場合, その開始を示す区切りはどれ

Multiple Choice
**Explanation:** RFC 3986 Section 3では, `//`がauthorityを含むgrammar branchを選びます. authorityは次の`/`, `?`, `#`の直前まで続き, userinfo, host, portを含み得ます. 一方, `?`はquery, `#`はfragmentの開始です. authorityは必須ではありません. 例えば`mailto:user@example.com`は`//`なしのpath-rootless formを使います. parser, proxy, router, security filterは, routingやpolicy判断の前にこのgrammar boundaryを同じように解釈する必要があります.

Q2: URI https://user:pass@example.com:8443/a?x=1#frag のauthorityはどれ

Multiple Choice
RFC 3986 は, URI を 1 本の文字列ではなく component の並びとして読みます. 例を分解して, どこまでが authority なのかを目で追えるようにすると混乱しにくくなります.
scheme https authority user:pass@example.com:8443 path /a query x=1 fragment frag # の後ろ
**Explanation:** hostだけをauthorityとして扱うと, 同じcomponentに属するuserinfoやportを落とします. authority境界はproxy設定, origin比較, access log, URL security reviewで使います. RFC 3986 Section 3.2のauthorityは`[userinfo@]host[:port]`です. この例では`//`の直後から`/a`の手前まで, つまり`user:pass@example.com:8443`が該当します. userinfoは`user:pass`, hostは`example.com`, portは`8443`です. `example.com:8443/a?x=1`はauthorityを越えてpathとqueryまで含みます. `https://user:pass@example.com`はschemeを含みportを落としているため,authority componentそのものではありません. こうした境界の誤りはproxy routing, origin比較, logging, authorizationの結果を変え得ます. またRFC 3986はuserinfo内のcleartext passwordをdeprecatedとしています. このpassword風の文字列はgrammarの説明用であり, applicationがcredentialとして表示・保存するための例ではありません.

Q3: RFC 3986でreservedに分類される文字はどれ (複数選択)

Multi-Select
**Explanation:** RFC 3986 Sections 2.2と2.3はURI characterをreservedとunreservedに分けます. `?`と`#`はgen-delims, `&`はsub-delimsであり, `~`はunreservedです. reservedはforbiddenやunsafeという意味ではなく, componentやschemeによってdelimiterになり得るという分類です. query構築, signature処理, redirect validationでは, 文字がsyntaxなのかdataなのかを保つ必要があります. reserved characterをdataとして使う場合はpercent-encodingが必要になり得ます.

Q4: 意図したtask identifierを保つcomponent contractはどれか?

Multiple Choice

A2A endpointは/tasks/の後ろに1つのtask identifierを置きます. identifierは3文字の値a/bで, slashはpath-segment delimiterではなくdataです. producerとbackendで1つのURI表現へ合意する必要があります.

**Explanation:** RFC 3986 Sections 2.1, 2.4, and 7.3はreserved delimiterとencoded dataを区別します. applicationはoctetをdecodeする前にURIをcomponentとsubcomponentへ分割しなければなりません. そうしないとdecoded dataがsyntaxと誤認されます. RFC 3986はtask-ID modelを定義しないため, 1つのsegmentを使うことはprofile側で定めます. A: 構造上のseparatorまでencodeするとgeneric path構造を壊します. B: raw slashは別segmentを作り, identityをparser固有の推測へ委ねます. C: 正解. syntaxとdataの役割を保ち, 両側へ1つのdecoding boundaryを与えます. D: parse前のdecodeはencoded dataをdelimiterへ変え, component boundaryを変え得ます.

Q5: verifierはsigned targetとrequest targetを同一視してよいか?

Multiple Choice

signed grantはHTTPS://EXAMPLE.COM/tasks/Aを示し, request targetはhttps://example.com/tasks/aです. profileはRFC 3986のgeneric normalizationだけを採用し, pathの大小文字を同一視する規則を定義していません.

**Explanation:** RFC 3986 Sections 6.1 and 6.2.2.1では, generic syntaxのschemeとhostはcase-insensitiveです. 他のgeneric componentはschemeが別途定義しない限りcase-sensitiveと仮定されます. URI comparisonは目的依存であり, false-positive equivalenceを避ける必要があります. A: hostの規則はpathへ広がりません. B: 正解. 許可された正規化後も, このprofileでは/tasks/Aと/tasks/aは異なるidentifierです. C: pathの小文字化はRFCにもprofileにもないequivalenceを作ります. D: ある時点で同じcontentでもauthorization identifierの同一性は証明されません.

Q6: URIで#の後ろの部分は___コンポーネントと呼ばれる

Short Text
**Explanation:** RFC 3986 Section 3.5は`#`の後ろをfragmentと呼びます. fragmentはprimary resourceに対するsecondary resourceを識別し, 解釈方法はmedia typeやclient contextに依存します. fragmentはdereference前に分離されるため, user agentは通常HTTP requestへ含めません. これは`?`で始まりresource requestの一部になるqueryとは異なります. 両者の混同はparsingとpolicy判断の双方を変えます.

Q7: URIをsecurity policyの識別子として使う場合, 最も安全なcanonicalization境界はどれか

Multiple Choice

署名済みgrantのtarget URIと受信requestのtargetを比較します. schemeやhostの大小文字だけでなく, pathの大小文字や別host名などのaliasも入力され得ます.

**Explanation:** RFC 3986 Sections 6.1 and 6.2はURI comparisonに単一の万能規則を置いていません. 比較目的によってtrade-offが異なり, scheme定義やapplication固有の規則が必要になるためです. 特にsecurity decisionでは, 別のidentifierを同一と誤認するfalse positiveを避ける必要があります. ある時点で同じ表現を返すことは, authorization上のidentity equivalenceを証明しません. redirect, virtual hosting, shared content, 一時的なroutingによって結果が一致することがあります. RFC 3986は不要なaliasを減らすため, URI producerがalready-normalized formを一貫して出す考え方を示します. security profileでは, そのcanonical formと比較規則をtrusted boundaryで固定すると, verifierごとの推測をなくせます. schemeとhostのcase normalizationはgeneric ruleですが, pathやその他のcomponentはscheme依存です. alias解決やdisplay-name matchingまで受信側が追加すると, attacker-controlled inputから新しいequivalenceを作ってしまいます. このdraftはこの原則をさらに限定し, decision-sensitive valueを発行またはtrusted policy comparisonの前にcanonicalにし, final acceptance pathではpeerのalias, case variant, URI variant, natural-language interpretationを修復しない設計を採ります. 「入力側でcanonicalizationする」とは, **profileが定めた決定的な変換を信頼済み境界で一度だけ行う**ことであり, verifierが都合よく意味を推測することではありません.

Q8: parser differentialを防ぐprocessing contractはどれか?

Multiple Choice

gatewayはpercent-decode前のraw pathをauthorizeします. backendは後から%2Fと%2eをdecodeし, dot-segmentを除去してstorageへ対応付けます. attackerはgatewayには許可されたtask, backendにはadministrative pathと解釈されるencoded pathを送ります.

**Explanation:** RFC 3986 Sections 2.4 and 7.3はcomponent分割後にdecodeし, security checkをdecode後のdataへ適用するよう定めます. Section 5.2.4はcomplete path segmentに対するdot-segment removalを定義します. RFCはA2A storageのauthorization policyを定めないため, profileが全enforcement pointを1つのidentityへbindする必要があります. A: raw valueとdecoded backend valueでは別resourceをauthorizeし得ます. B: repeated decodingはliteral percent dataを再変換し, 危険な変換後にparseすることにもなります. C: 正解. URI boundaryを保ち, security-relevant valueを検査し, backendでの再解釈を防ぎます. D: encoded octetはdereference中にsecurity-significant characterになり得るため不十分です.

Q9: rare-address-format bypassへ対応するdestination checkはどれか?

Multiple Choice

Agent fetcherは127.で始まるURI hostをblockし, 他の文字列をplatform resolverへ渡します. resolverは2130706433と0x7f000001をloopbackとして受理します. profileはlocal destinationを拒否する方針です.

**Explanation:** RFC 3986 Section 7.4はdecimal, octal, hexadecimalによるalternate IPv4 formをURI syntax外とし, platform routineがそれらを受理し得ると警告します. address filteringを行う場合は文字列prefixやsuffixではなくnumeric valueで判定すべきです. A: 文字表現とresolver semanticsの差がまさにbypassです. B: resolution成功はdestinationの許可を意味しません. C: 正解. accepted syntaxとpolicyを実際のnumeric destinationへ揃えます. redirectやname-resolutionの再検査は追加のapplication policyであり, RFC 3986が定める規則ではありません. D: suffix比較もrepresentation依存の文字列検査です.

Q10: このAgent Card URLから導くべきreview findingはどれか?

Multi-Select

profileはaccess tokenがbrowser history, proxy log, application logへ露出することをsuccessful attackとします. clientはhttps://trusted.example@attacker.example/card?access_token=SECRETを渡され, UIは@より前を強調し, fetcherはgeneric URI parsingを行い, loggerは完全なURIを保存します.

**Explanation:** RFC 3986 Sections 3.2.1, 7.5, and 7.6ではuserinfoをhostの前に置き, userinfo内のpassword-like secretをdeprecatedとし, URIが表示・記録されることとmisleading userinfoによるsemantic attackを警告します. ここでのrejectとno-secret-URI ruleは宣言されたprofile threat modelに由来し, RFC 3986のuniversal userinfo banではありません. A: 非選択. hostは@の後ろで, 前の文字列はuserinfoです. B: 選択. generic parsingではattacker.exampleへrequestを送ります. C: 選択. logging前にdisplay deceptionとprofile-defined disclosure attackの両方を止めます. D: 非選択. あるhostの認証はuserinfo文字列へのauthorityを示しません. E: 非選択. RFCはuserinfo syntaxを認めつつriskを警告し, cleartext passwordをdeprecatedとしています.