ToppyMicroServices

RFC 7617 Quiz

HTTP Basic認証

🇺🇸 🇯🇵
0 / 0

一次資料

Basic credentialをreusable secretとして扱い、syntax、protection-space reuse、peer trust、hop protection、storage、downstream authorizationを分けて判断する問題です。節番号はRFC 7617を指します。

Q1: Basic user-idにcolonが含まれる場合、どう処理するか？

単一選択 · L3

provisioning formがuser-id ops:adminとpassword secretを受け付けました。clientはBase64 encoding前にops:admin:secretと連結しようとしています。

**解説:** Bが正解です。Section 2はuser-passをuser-id、1つのcolon、passwordとして構成します。user-idにcolonがあると最初のcolonがdelimiterになるためinvalidです。この例はuser-id ops、password admin:secretとして解釈されます。user agentはserialization前に、このinputをrejectする必要があります。 Aはlast-colon ruleを作っています。CはRFC 7617がuser-passに定義していないescape layerを作っています。これはinput-validation boundaryであり、値を黙って変換するとprovisioning systemとauthentication serverが異なるprincipalを認識します。

Q2: Basic challengeのcharset=UTF-8は何を変えるか？

単一選択 · L3

serverがWWW-Authenticate: Basic realm="agents", charset="UTF-8"を送ります。clientはこのparameterをsupportし、non-ASCIIのuser-idを持ちます。

**解説:** Cが正解です。Section 2.1はcharsetをchallengeだけに定義し、case-insensitiveに比較するUTF-8だけを許します。character dataをUnicode NFCへ変換し、UTF-8 octetにしてからBase64化するというserverの期待を示します。 Aはcharacter encodingとconfidentialityを混同しています。UTF-8もBase64もreversibleな表現です。Bはextensibleなcredential structureを作っていますが、RFCはBasic credentialがsingle token68であり、この方法では拡張できないと説明します。このparameterはadvisoryですが、共通の期待に従うことでnon-ASCIIのinteroperability failureを避けられます。

Q3: このBasic credentialをpreemptiveに再利用できる範囲はどれか？

単一選択 · L3

clientがhttp://example.com/docs/index.htmlへのrequestでauthenticationに成功しました。その後、http://example.com/docs/report、http://example.com/other/、https://example.com/docs/reportへのrequestを準備します。

**解説:** Aが正解です。Section 2.2はpathの最後のslashより後を除き、http://example.com/docs/をauthentication scopeとします。そのprefixを持つresourceにはcredentialをpreemptiveに再利用できます。RFCの例では/other/とHTTPS schemeのvariantはscope外です。 Bはpathとschemeを無視しています。Cは強いtransportをcredential scope拡張のpermissionに変えていますが、そのようなruleはありません。scope内のreuseは許可（MAY）であり、すべてのmatching requestに送る義務ではありません。

Q4: このredirect先へBasic credentialをforwardすべきか？

単一選択 · L3

agentがhttps://api.example/tasks/7へHTTPS上でauthenticateします。responseはhttps://collector.example/importへredirectします。libraryは同じAuthorization valueをforwardし、decoded formをlogへ記録しようとしています。

**解説:** Cが正解です。Section 2.2がpreemptive reuseを認めるのはauthentication scope内だけです。異なるauthorityはoriginal originのprotection spaceではなく、redirectはcredentialを受け取るpermissionを作りません。new originにはapplicableなchallengeまたは明示的なapplication credential policyが必要です。 Aはprotection spaceへの所属が継承されると誤認しています。Bはreversibleな表現を変えるだけで、freshnessもconfidentialityも作りません。Section 4はBasicが容易に復元できるreusable passwordを露出すると説明します。decoded valueをlogから除外することは、このthreatから導く運用対策であり、別のBasic wire-format要件ではありません。

Q5: frontend TLSは次のhopのBasic credentialも保護するか？

単一選択 · L3

gatewayがHTTPSをterminateし、同じBasic Authorization headerをobservableなplaintext connectionでbackendへforwardします。operatorはclientがHTTPSを使ったためcredentialは安全だと説明しています。

**解説:** Bが正解です。Section 4はBasicをphysical carrier上でのcleartext password transmissionとして扱い、HTTPSなどのenhancementなしにsensitive informationを保護する用途へ使うべきでないとしています。TLS protectionはそのconnectionがterminateした地点で終わります。同じcredentialをplaintextでforwardすれば、新しいobservableな露出になります。 Aはhop protectionを、存在しないend-to-end propertyへ変えています。Cはdecodeしないことをsecrecyと混同しています。observerは誰でもBase64をdecodeできます。RFC 7617はgateway architectureを指定しませんが、reusable credentialを運ぶ各hopでprotectionとtrustを判断する必要があります。

Q6: counterfeit gatewayがBasic credentialを要求するとき、欠けている保証は何か？

単一選択 · L3

agentがvalidに見えるBasic challengeを返すhostile gatewayへ接続します。agentはpeerをauthenticateせず、ほかのserviceでも使うpasswordを送ります。

**解説:** Aが正解です。Section 4はcounterfeit-server spoofingを明示しています。hostile serverやgatewayはpasswordを要求し、保存してからerrorを装えます。TLS peerのauthenticationと、どのserverがどのcredentialを要求できるかの制限が、このtrust boundaryに必要です。 Bはfree-formなrealm labelをserver identityのproofとして扱っていますが、その性質はありません。Cはpublicなencodingを変えるだけで、credentialをreusableなままにします。password reuseがあると、hostile gatewayが同じuser-idとpasswordをunrelated serviceへ試す可能性があります。

Q7: RFC 7617が支持するpassword storage reviewはどれか？

単一選択 · L3

Basic-auth serverは全passwordをunsalted fast digestとして保存します。operatorはnetwork requestがoriginal character stringではなくBase64を運ぶため、十分に安全だと主張します。

**解説:** BがRFC 7617のsecurity guidanceに沿う答えです。Section 4はserverとproxyがpassword dataを何らかの形で必要としつつ、漏えい後の容易な復元を抑え、plaintextやunsalted digestを避けるべきだと述べます。具体的なmodern password-hashing designはこのRFCの範囲外です。 Aはreversibleなwire representationとsecure at-rest verificationを混同し、offline guessingを無視しています。Cはprotocolを過大解釈しています。Basicはclientが送る形式を定義しますが、plaintext保存を要求しません。これらは新しいBasic credential syntaxではなく、security recommendationです。

Q8: Basicをdelegation tokenに変えないA2A設計はどれか？

単一選択 · L4

gatewayが自身のrealmについてclientのBasic credentialをvalidateしました。その同じAuthorization headerを複数agentへcopyし、各backendにuserとして動作させようとしています。backendごとにresource policyとtrust domainが異なります。

**解説:** Cがapplication designとして正しい結論です。Sections 2と2.2はBasic protection space内でuser-id/password pairをauthenticateし、限定されたcredential reuseを定義します。RFC 7617はtransitive delegation、downstream audience、resource scope、unrelated backendへのauthorityを定義しません。gatewayがclientをauthenticateできても、後続hopにはそのtrust modelに適したprotectedかつ明示的にscopedなmechanismが必要です。 Aはcredential verificationをuniversal authorizationへ変え、全hopでreusable passwordを露出します。Bはlabelを変えるだけで新しいproofやpermissionを作りません。realmはprotection spaceを定義する助けでありdelegationではありません。RFC 7617はreplacement mechanismを指定しないため、applicationが選択して保護します。