Re: Message delimiting security issues

Roy T. Fielding wrote:

[snip... +1 to your initial comments]

> On Jan 19, 2007, at 11:05 AM, Larry Masinter wrote:
> 
>> So, in my opinion, we should change the spec that
>> clients MUST NOT send LWS in headers before the :,
>> and that servers MUST reject any such message as
>> malformed.
>>
>> This may make a few servers that were previously
>> compliant non-compliant, but in general it will
>> improve interoperability and security.
> 
> No, I will not accept that.  MUST NOT send such LWS is fine,
> including when a message is forwarded, but forbidding a server from
> processing such a message is not going to happen because it would
> make all implementations non-compliant.
> 
> Servers should be configurable in regards to robust or restricted
> parsing behavior, and nothing we say can improve the "security"
> of broken software that was deployed years ago.  Software that
> correctly parses according to the RFC is not subject to those
> perceived security issues.

As long as a middle tier agent doesn't forward such broken headers
as-given, this isn't an issue?  The middle-tier server may accept or
reject "Foo :bar" as forgiving as it chooses to be, as long as this
middle-tier user agent always forwards the request as "Foo:(LWS*)bar"
instead.  'MUST NOT send' as you describe would accomplish this.

In the security section, an additional observation that header field
names SHOULD be validated would further encourage implementors to
reject the case where their "Foo :bar"'s header field name is treated
as "Foo ".

These two notes would codify the core of the observation from the
Watchfire report.

Received on Friday, 19 January 2007 20:52:40 UTC