Re: #904: Content on GET requirement strength

[Asbjørn Ulsberg <[e-mail]>]

fre. 16. jul. 2021 kl. 18:40 skrev David Benjamin <[e-mail]>:

> Is the spec's explanation of the implications here even sufficient? In
> addition to the request getting potentially rejected, might it also lead to an
> actual request smuggling attack if the server doesn't reject the request but,
> instead, interprets it differently?

Indeed. As far as I can tell, there's also a potential security and
privacy issue in having an intermediate cache reuse the response from
a prior query because it (rightly) does not consider the request body
to be significant when keying the cache entry. This can both lead to
unauthorized access to data as well as a possible cache poisoning
vector.

> Given the security risk, the current text doesn't seem strong enough to me.

Agreed. But I think it may be worth reflecting on why GET with a body
is an issue worth discussing both here on the mailing list and in the
HTTP spec itself. Enough implementations of this anti-pattern over the
years have made it evident (at least to me) that there is a need for a
safe HTTP method sporting a request body. The most common use case is
performing complex queries where the query string either reveals too
much information, causes length issues, or is just too messy. To
accommodate these use cases, an I-D for a safe method with body has
been initiated:

https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

With such a method in the implementer's toolbox, I'm pretty certain a
MUST NOT requirement would be easy to swallow. However, since the I-D
is still far from completion and there are no standardized
alternatives to GET with body, a more elaborate explanation of
potential security and privacy risks and stronger language with the
current SHOULD NOT requirement seems appropriate.

-- 
Asbjørn Ulsberg           -=|=-        [e-mail]
«He's a loathsome offensive brute, yet I can't look away»