ToppyMicroServices

RFC 6265 Quiz

HTTP Cookie basics

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 6265はCookieとSet-Cookie field, user agentの処理を定義します. Cookie valueをapplicationがどう解釈するかは定義せず, Path, Domain, Secure, HttpOnlyも完全なauthorization boundaryにはしません. CSRF対策とserver-side session policyはapplicationの責務です.

Q1: gatewayは複数のSet-Cookie fieldをどう転送すべきか

単一選択

originが二つのSet-Cookie fieldを返しました. 一方のExpires dateにはcommaが含まれます. gatewayは通常, 重複fieldを一つのcomma-separated valueへ結合します.

**解説:** A: RFC 6265 Section 3はSet-Cookieを例外として扱います. commaがsyntax内にも現れるため, 通常のfoldingは意味を変え得ます. B: Section 3はorigin serverが複数のSet-Cookie fieldをfoldしないことをSHOULD NOTとします. 別々に保てばこの曖昧さを避けられます. C: originは複数のSet-Cookie fieldを含められます. 同名cookieやraceへの勧告はありますが, 一response一cookieという制限ではありません. D: Cookieは保存済みcookieをuser agentが返すrequest fieldであり, response側のSet-Cookieを置き換えません.

Q2: このdeployment reviewとして適切なのはどれか

単一選択

相互に信頼しない二つのapplicationがexample.comを共有します. 管理者は/financeと/gamesを割り当て, Path attributeでsecurity-sensitiveなcookieを隔離できると判断しました.

**解説:** A: RFC 6265 Section 8.6ではresponseが任意のPathを設定できると説明します. request pathによる設定範囲の制限はありません. B: HttpOnlyはnon-HTTP APIからのaccessを制限します. Pathをintegrity boundaryにはしません. C: Sections 4.1.2.4と8.6はpath matchingとsecurity isolationを区別し, 同一hostの異なるpathで相互に信頼しないserviceがsecurity-sensitive cookieを使うことを避けるよう勧告します. D: non-rootのPathは許されています. 問題はPathの利用自体ではなく, isolationを依存させることです.

Q3: Secure attributeだけでは得られない保証はどれか

単一選択

HTTPS serviceがsession cookieにSecureを付けています. 本物のcookieはHTTPで送信されないため, active network attackerはreplacement cookieを注入できないとreviewしました.

**解説:** A: Secureは送信条件のflagです. RFC 6265はbrowserによる署名処理を定義しません. B: HttpOnlyはnon-HTTP APIからのaccessを制約し, Secureとは独立しています. response headerを認証しません. C: Section 8.6は, 正規serviceがHTTPSだけを使っても, attackerがinsecure responseになりすましてSet-Cookieを注入できると説明します. D: Sections 4.1.2.5と8.6はSecureの保証を限定し, overwrite attackを明記します. 追加のintegrity・session controlはapplicationとdeploymentの責務です.

Q4: cookieの確認だけでは何を確立できないか

単一選択

agentがattacker指定のpageを開きました. そのpageはbank.exampleへ送金requestを送らせます. browserは有効なSecure, HttpOnly session cookieを自動添付し, bankはそのcookieだけで送金を認可します.

**解説:** A: 自動添付ではattackerがrequestを指定し, user agentがambient authorityを付けられます. B: RFC 6265 Section 8.2はdesignationとauthorizationの分離をCSRF/confused-deputy riskの根として説明します. 具体的なrequest authorization対策はapplication設計であり, RFC 6265のcookie処理ruleではありません. C: 暗号化はcookie内容を保護できますが, request中の操作を誰が選んだかは証明しません. D: lifetimeは保持期間に関係し, session authorityと要求された操作の関係は確立しません.

Q5: serverは先頭の同名cookieをauthoritativeと扱ってよいか

単一選択

requestに`SID=finance; SID=other`があり, Pathの異なる同名cookieから生成されています. backendはSection 5.4が長いpathを先にするよう勧めるため, 常に先頭値を信頼します.

**解説:** A: Section 5.4のsortはSHOULDであり, すべてのuser agentがその順序にしないとも記載します. 普遍的なMUSTではありません. B: Section 4.2.2によればCookieはPathやDomainなどのattributeを返しません. C: Section 4.2.2は, 特に同名cookieについてserverがserialization orderへ依存しないことをSHOULD NOTとします. 一意の名前または曖昧でないserver-side処理なら, 得られないmetadataにauthorityを依存させずに済みます. D: DomainまたはPathが異なる同名cookieは同時に送られ得ます.

Q6: serverはMax-Ageまでcookieが保存されると信頼できるか

単一選択

workflow cookieにMax-Age=86400を設定しました. serverはその一日以内にcookieがなければtamperingの証拠と扱い, user accountを恒久的に拒否します.

**解説:** A: Section 4.1.2.2はMax-Ageを最大lifetimeとし, user agentがその期間保持する必要はないとします. Sections 5.3と8.6もcapacityによる削除を許し, serverが保持を信頼しないよう警告します. recoveryとreauthentication policyはapplicationの選択です. B: Max-Ageは処理時のexpiry timeを決めますが, 最小保持期間は課しません. C: past expiryによるreplacementは削除方法の一つですが, user操作, privacy control, storage limitでも削除されます. D: Max-Ageには定義された処理semanticsがあり, Expiresと両方あればMax-Ageが優先されます.