Re: TAG requests addition to section 3.2.1 of Part 3 [#155]

On 22/03/2010, at 7:02 AM, Henry S. Thompson wrote:
> 
> Suggested addition to the end of section 3.2.1 of Part 3 of HTTP bis [1]:
> 
>  If the Content-Type header field _is_ present, a receipient which
>  interprets the underlying data in a way inconsistent with the
>  specified media type risks drawing incorrect conclusions.
> 
>  In practice, however, currently-deployed servers sometime provide a
>  Content-Type header which does not correctly identify the content
>  sent, with the result that some classes of recipients have adopted a
>  policy of examining the content and overriding the specified type.
> 
>  Such 'sniffing' SHOULD NOT be done unless there is evidence that the
>  specified media type is in error (for example, because it is
>  'text/plain' but there are bytes in the data which are not legal for
>  the specified or defaulted charset).  In any case recipients SHOULD
>  NOT override the specified type if the change would significantly
>  increase the security exposure ('privilege escalation').

My reaction to reading that is that these requirements are so watered down as to be meaningless; they require implementers to make very subjective judgement calls based on evidence of errors and security exposure, with almost no guidelines. 

Would the TAG be satisfied if this were rewritten in advisory language (i.e., without RFC2119 keywords)?

E.g., keep the first two paragraphs, but change the third to

"""
There are two risks of such 'sniffing.' First, the sniffed type may not be
that of the actual document, preventing the server from having their 
intent honoured. For example, a simplistic HTML sniffing algorithm might
be fooled by a text/plain document containing the word 'HTML' near its top.

Secondly, sniffing exposes implementations to security escalations. For 
example, if a server sets a content-type of an uploaded file to text/plain,
but a client sniffs it as text/html, an attacker might take advantage of 
this to mount a cross-site scripting attack.
"""


>  Deploying any heuristic for detecting mistaken Content-Types risks
>  overriding user intentions and misrepresenting data---accordingly
>  recipients SHOULD provide for users to disable sniffing in general
>  and/or in particular cases.

This will make almost all current implementations non-conformant, and I don't have much confidence that they'll become conformant to this requirement any time soon (implementers, I'd love to be proven wrong here).

Also, any thoughts about putting this in Security Considerations instead?


Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 19 May 2010 12:06:29 UTC