Re: Message delimiting security issues

ons 2007-01-17 klockan 08:42 -0800 skrev Travis Snoozy:

> token          = 1*<any CHAR except CTLs or separators>
> message-header = field-name ":" [ field-value ]
> field-name     = token
> separator      = [...] | SP | HT
> 
> What we have there is malformed; separators (SP) are not allowed in tokens.

well... no. The 2616 BNF grammar is also augmented with the "implied
*LWS" rule in section 2.1.. which allows insertion of LWS between any
token and any separator unless forbidden.

> The same way it MUST react whenever it gets any header that isn't allowed
> multiples -- reject the message as blatantly malformed:

Specs does not say recipients MUST reject any malformed message. It
doesn't even require recipients to detect malformed messages and the
robustness principle underlining most use of IETF protocols generally
discourages it. And everything else in software development speaks
against such rejections unless they happen "as a by product" of the
development.

And the result is as expected. Implementations swallow even the most
blatantly malformed messages, with widely varying results.

> If I may insert my two cents here: the spec is so fuzzy, poor, and inconsistent
> in OTHER places that it affects the overall quality and ability to implement.

Very few of the other issues has security implications for other users
visiting other URLs..

> In my experience, it got _very_ tempting to just start ignoring the spec and do
> a pigeon HTTP/1.1 implementation.

It's what most people do, and then they maybe read the specs and try to
comply, and as result there is chaos.

Regards
Henrik