Re: Restricting the HTTP method definition

On 21/08/2013 12:41 p.m., Roberto Peon wrote:
> I admit that I haven't thought hard about how this might potentially 
> be abused with others' frameworks/servers, but I imagine the pattern 
> is nearly always the same:
>
> Servers/Clients which care about security/memory utilization will 
> ensure that this won't be abused.
> Servers/Clients that trade reliability for simplicity will 
> occasionally suffer decreased reliability when they receive strange input.
>
> In the end, I don't think there is anything we can do for the 
> servers/clients in the latter case. If we constrain the input so much 
> that it is always safe, it is likely we have created something which 
> is not generally useful.

For middleware proxies which are validating the request-line it is one 
of the outstanding problems that we cannot determine explicitly that a 
extremely long string of ASCII alphanumerics is an invalid request. 
Often times we run out of available buffer space and have to reject the 
request even if it was valid for the application layer doing funky 
REST-ful "extensions", meanwhile the client delivered it in small chunks 
and held up a lot of network resources (slow-loris etc).

I've not seen this in practice in legitimate use outside of software 
fingerprinting tests.

At the very least the proposal allows a much faster rejection of the 
nastiness.
+1 for limiting the method length.

Amos


>
> -=R
>
>
> On Tue, Aug 20, 2013 at 5:37 PM, Roberto Peon <grmocg@gmail.com 
> <mailto:grmocg@gmail.com>> wrote:
>
>     I don't really care about this-- it solves none of my problems.
>
>     I typically scan for the EOL, checking length while doing this 8
>     or more characters at a time, then, once the EOL is discovered,
>     attempt to parse the tokens within the first line.
>     I care about the total length of the first line, but even then
>     only because I care about the total size of the headers since I
>     don't want to exceed available memory and die.
>     I don't care if it is spent in the method, uri, headers, p3p,
>     cookie, or whatever. It is all the same crud to me-- it just has
>     to fit in the available space.
>     If the particular server cares about accepting a limited set of
>     methods (which is always true-- if you don't know what a verb is,
>     you don't know what to do with it...), then the request is rejected.
>
>     What problem does limiting the verb sizes solve? Are people doing
>     weird things with them? Are people abusing them in ways that would
>     cause problems that they cannot otherwise do (e.g. with a very
>     long path)?
>     -=R
>
>
>
>     On Tue, Aug 20, 2013 at 5:18 PM, James M Snell <jasnell@gmail.com
>     <mailto:jasnell@gmail.com>> wrote:
>
>         Ok. Same note. Same mailing list. Same proposal.
>         s/HTTP\/2/HTTP\/1/g.
>
>         Regardless of exactly which doc to do it in, it ought to be done.
>
>         On Tue, Aug 20, 2013 at 5:14 PM, Mark Nottingham
>         <mnot@mnot.net <mailto:mnot@mnot.net>> wrote:
>         > James,
>         >
>         > The place to do that is HTTP/1, not HTTP/2.
>         >
>         > Cheers,
>         >
>         >
>         > On 21/08/2013, at 9:22 AM, James M Snell <jasnell@gmail.com
>         <mailto:jasnell@gmail.com>> wrote:
>         >
>         >> HTTPbis currently defines the request method as a "token"
>         of unbounded-length.
>         >>
>         >> Specifically:
>         >>
>         >>   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" /
>         "-" / "." /
>         >>    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
>         >>   token = 1*tchar
>         >>   method = token
>         >>
>         >> This definition is overly broad and does not reflect real
>         world use
>         >>
>         [http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-12].
>         >>
>         >> I propose that in HTTP/2 we tighten this definition up
>         significantly
>         >> and place an upper bound on the length a request method
>         ought to be:
>         >>
>         >>  UPPER = %x41-5A
>         >>  method = UPPER *20( UPPER / "_" / "-" )
>         >>
>         >> This is obviously a strictly limited subset of what's
>         allowed by the
>         >> current definition. It limits the length of method names to
>         no more
>         >> than 20 characters, requires that methods be all uppercase,
>         requires
>         >> that methods always start with a letter and limits non-letter
>         >> characters to the dash and underscore. The rule would be
>         that all
>         >> *newly registered* HTTP methods MUST conform to the new
>         rule but
>         >> implementations MAY choose to support the old definition if
>         necessary
>         >> for backwards compatibility.
>         >>
>         >> It's a fairly minor issue, yes, but tightening this up
>         ought to make
>         >> it easier for developers to create parsers that are both
>         efficient
>         >> *and* compliant [http://www.chmod777self.com/2013/08/sigh.html]
>         >>
>         >> - James
>         >>
>         >
>         > --
>         > Mark Nottingham http://www.mnot.net/
>         >
>         >
>         >
>
>
>

Received on Wednesday, 21 August 2013 10:20:27 UTC