How to validate if a non-compliant HTTP cookie is handled correctly?-CodePudding

Summary: A client's code is generating invalid cookies with a secure, attribute (note the illegal trailing comma). The IETF spec says unknown attributes for cookies must be ignored, but the cookies themselves can still be used. Thus, we might have unsecure cookies being generated. Is this the case?

Full background:

I'm trying to track down some bugs in how a client's code generates cookies and I've stumbled across the following Set-Cookie header (broken over several lines to make it easier to read):

foo=wtf; expires=Tue, 28-Jul-2022 GMT; secure,
foo=bar; expires=Tue, 28-Jul-2022 GMT; secure,
baz=qux; expires=Tue, 28-Jul-2022 GMT; secure

In a careful reading of the IETF specification for HTTP State Management Mechanism, I've found several things.

First, duplicate cookie names should not be there:

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.

I've fixed that (it was the cause of the bug I was working on). However, there are other concerns ...

The expires attribute, 28-Jul-2022, requires spaces (28 Jul 2022) instead of dashes, but it looks like most cookie parsers are fairly tolerant of this.

However, the cookie generation library is joining cookies with commas. Thus, we have an attribute named secure, for the first two cookies. According to the spec:

User agents ignore unrecognized cookie attributes (but not the entire cookie).

Thus, we might be trying to mark cookies as secure, but having our secure, attribute ignored.

I've struggled to find resources detailing this particular condition and it looks like it might be a serious security bug if the cookie parsing code is strict. I could just try testing this out in various user agents, but I can't try it with all user agents, different versions of those user agents, or (to be Captain Obvious) future versions of those user agents.

Is that trailing comma allowed? It certainly doesn't seem to be. If it's not allowed, is there a resource I can check to find out how permissive cookie parsers are in general?

I don't know that I have the time to fix this, but I can at least raise the issue internally.

CodePudding user response：

RFC 6265 § 3 also states

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in RFC2616) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

So at the very least your cookie generation library is misbehaving (although whether that can answer if this is invalid or not I guess depends on how closely you want to adhere to the RFC's recommendations).