RFC 6265 Quiz

Q1: How should a gateway forward multiple Set-Cookie fields?

Multiple Choice

An origin returns two Set-Cookie fields. One contains an Expires date with a comma. A gateway normally combines repeated fields into one comma-separated value.

A. Combine them because every repeated HTTP field has identical list semantics B. Preserve separate fields because folding can change Set-Cookie semantics C. Keep only the last field because a response can create only one cookie D. Convert them into one Cookie field because clients store request headers

**Explanation:** A: RFC 6265 Section 3 identifies Set-Cookie as an exception: comma also appears in its syntax, so ordinary folding can alter meaning. B: Section 3 says origin servers SHOULD NOT fold multiple Set-Cookie fields. Preserving the separate fields avoids that ambiguity. C: An origin can include multiple Set-Cookie fields; the recommendation concerns duplicate names and races, not a one-cookie response limit. D: Cookie is the request field by which a user agent returns applicable stored cookies; it cannot replace response-side Set-Cookie.

Q2: Is Path a security boundary between two services?

Multiple Choice

Two mutually distrusting applications share example.com. The administrator assigns /finance and /games and relies on Path attributes to keep each application's security-sensitive cookies isolated.

A. Yes, because a service can set cookies only for paths beneath its request path B. Yes, if both cookies also use HttpOnly, because scripts then enforce path isolation C. No; Path controls request selection but does not provide integrity isolation between the services D. No, because RFC 6265 requires every cookie to use the root path instead

**Explanation:** A: RFC 6265 Section 8.6 notes that a response can set an arbitrary Path; the request path does not confine what Path it may set. B: HttpOnly limits exposure through non-HTTP APIs. It does not turn Path into an integrity boundary. C: Sections 4.1.2.4 and 8.6 distinguish path matching from security isolation and advise against security-sensitive cookies for mutually distrusting services on different paths of one host. D: The RFC permits non-root Path values. The defect is relying on them for isolation, not using them at all.

Q3: What guarantee does Secure fail to provide?

Multiple Choice

An HTTPS service marks its session cookie Secure. Its review concludes that an active network attacker cannot inject a replacement cookie because the real cookie is never sent over HTTP.

A. The conclusion follows because Secure signs the cookie before storage B. The conclusion follows if HttpOnly is added, because it authenticates Set-Cookie responses C. The conclusion follows whenever the HTTPS endpoint refuses all plain HTTP requests D. The conclusion is too strong; Secure limits sending but does not by itself protect cookie integrity

**Explanation:** A: Secure sets a transmission flag; RFC 6265 defines no browser signature operation for it. B: HttpOnly constrains non-HTTP API access and is independent of Secure; it does not authenticate response headers. C: Section 8.6 explains that an attacker can impersonate an insecure response and inject Set-Cookie even when the genuine service uses HTTPS exclusively. D: Sections 4.1.2.5 and 8.6 limit Secure's guarantee and explicitly describe overwrite attacks. Additional integrity and session controls belong to the application and deployment.

Q4: What does the cookie check fail to establish?

Multiple Choice

An agent opens an attacker-selected page. That page causes the browser to submit a transfer request to bank.example. The browser automatically attaches a valid Secure, HttpOnly session cookie, and the bank authorizes the transfer solely from that cookie.

A. Nothing is missing because possession by the browser proves who selected the transfer B. The session cookie is valid, but it does not prove that a trusted party designated this transfer C. Only cookie confidentiality is missing, so encrypting the value establishes request intent D. Only cookie persistence is missing, so a longer Max-Age establishes request intent

**Explanation:** A: Automatic attachment lets an attacker designate a request while the user agent supplies ambient authority. B: RFC 6265 Section 8.2 identifies this separation of designation and authorization as the basis of CSRF/confused-deputy risk. The concrete request-authorization defense is an application design choice, not a cookie-processing rule defined by RFC 6265. C: Encryption can protect cookie contents but does not prove who selected the operation carried by the request. D: Lifetime affects retention, not the relationship between session authority and the requested action.

Q5: May a server treat the first same-name cookie as authoritative?

Multiple Choice

A request contains `SID=finance; SID=other`, created from same-name cookies with different Path values. The backend always trusts the first value because Section 5.4 recommends longer paths first.

A. Yes; the Section 5.4 ordering is a MUST that every sender follows B. Yes; the Cookie field carries each cookie's Path so the server can verify the order C. No; the server should avoid order-dependent authority and disambiguate its cookie design D. No; a user agent is forbidden from sending two cookies with the same name

**Explanation:** A: Section 5.4 says the user agent SHOULD sort, and notes that not all user agents do so. That is not a universal MUST. B: Section 4.2.2 states that Cookie does not return attributes such as Path or Domain. C: Section 4.2.2 says servers SHOULD NOT rely on serialization order, especially for same-name cookies. Unique names or unambiguous server-side handling avoid making authority depend on unavailable metadata. D: Same-name cookies with different Domain or Path values can legitimately appear together.

Q6: Can a server rely on a cookie remaining stored until Max-Age?

Multiple Choice

A workflow cookie has Max-Age=86400. The server treats its absence during that day as proof of tampering and permanently rejects the user's account.

A. No; absence is expected state because a user agent may evict the cookie earlier B. Yes; Max-Age requires retention for exactly the stated number of seconds C. Yes; early eviction is permitted only after the server sends an expired replacement D. No; Max-Age is display metadata and never influences cookie expiry

**Explanation:** A: Section 4.1.2.2 calls Max-Age a maximum lifetime and says the user agent need not retain the cookie for that duration. Sections 5.3 and 8.6 also permit capacity-driven removal and warn servers not to rely on retention. Recovery and reauthentication policy are application choices. B: Max-Age determines an expiry time when processed; it does not impose a minimum retention period. C: Replacement with a past expiry is one deletion mechanism, but users, privacy controls, and storage limits can also remove cookies. D: Max-Age has defined processing semantics and takes precedence over Expires when both occur.

HTTP State Management Mechanism

References (URLs)

Q1: How should a gateway forward multiple Set-Cookie fields?

Q2: Is Path a security boundary between two services?

Q3: What guarantee does Secure fail to provide?

Q4: What does the cookie check fail to establish?

Q5: May a server treat the first same-name cookie as authoritative?

Q6: Can a server rely on a cookie remaining stored until Max-Age?