- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Sun, 17 Oct 2010 23:31:51 -0600
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Maciej Stachowiak <mjs@apple.com>, Adam Barth <w3c@adambarth.com>, "William Chan (ιζΊζ)" <willchan@chromium.org>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
OK, that's definitely a browser vulnerability if the first C-L is used. But how is this *still* a vulnerability under the current wording? In the presence of multiple C-L headers, if length is determined by reading until connection close, then no splitting occurs. -Eric Mark Nottingham wrote: > > http://www.securiteam.com/securityreviews/5CP0L0AHPC.html > > Technique #2. > > > On 18/10/2010, at 4:00 PM, Eric J. Bowman wrote: > > > Mark Nottingham wrote: > >> > >>> We can't simply break formerly-conforming implementations. > >> > >> We can if it's a security issue. > >> > > > > The security issue in question is "HTTP request smuggling" which is > > an attack vector which always takes the form of a malicious request > > from a user-agent. All it is the other way around, is a broken > > server putting itself at risk. There's no justification for a MUST > > even if there is consensus for it. > > > > I thought the consensus the WG was after, was whether or not to > > discard all but the first C-L or the last C-L. The current > > proposed language says read to connection close, instead. This > > makes loads of sense to me, instead of MUST fail hard based on what > > concern, exactly? > > > > -Eric > > -- > Mark Nottingham http://www.mnot.net/ > > > >
Received on Monday, 18 October 2010 05:32:28 UTC