Re: Precision of numbers using JSON Header Field Values

Hi,

On Fri, Jul 15, 2016 at 02:01:41PM +0900, Kazuho Oku wrote:
> Hi,
> 
> 2016-07-15 13:37 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> > Hi Kazuho,
> >
> > On Fri, Jul 15, 2016 at 01:13:31PM +0900, Kazuho Oku wrote:
> > (...)
> >> 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100e400
> >> is evaluated as 100. OTOH, using ruby 2.0.0, the same expression is
> >> interpreted as zero.
> >
> > Nice!
> >
> >> (please refer to
> >> https://gist.github.com/kazuho/7e72372111fa0655692d9e44be70c7ea for
> >> the full output)
> >>
> >> IMO such disagreement is a mine of vulnerabilities.  For example in
> >> case of HTTP/1.1, it could lead to HTTP response splitting.
> >>
> >> So personally, I think we should forbid the use of exponential
> >> notation at least in some cases, but I wonder if adding such
> >> restriction is intended or aligns with the motive to use an existing
> >> notation for HTTP headers.
> >
> > Do we have a method to suggest to decoders to reject this ?
> 
> Some decoders might have such option, but my understanding is that
> such option is not available at least in JavaScript (i.e. ECMAScript
> 5th edition).
> 
> >  I mean,
> > we can say it's forbidden, but if recipients systematically pass the
> > whole string through a non-configurable decoder, the vulnerability
> > continues to be deployed. That's especially true for all "MUST NOT"
> > which tend to be considered as granted by senders with no need to
> > check on the recipient unfortunately :-/
> >
> > Also are we sure senders will never emit exponents without being
> > explicitly instructed to do so ? I'm asking because I wouldn't
> > like to see for example, "Content-length: 1000000500" being
> > encoded as "Content-length: 1e09" and then decoded as
> > "Content-length: 1000000512" (for example) because it's parsed
> > as a float by one implementation which can only use single
> > precision numbers.
> 
> It might be fair to expect that encoders would be possible to emit
> integers up to 2**53-1 precisely (as discussed in section 6 of RFC
> 7159).

OK but if transmitted with a decimal point like in your example above,
are we sure a decoder will still consider that it is an int ? For
example, if I craft "Content-length: 1000000500.99999994" and parse it
using atof(), I'm seeing that printf("%f") emits "1000000501.000000"
while converted to an int it becomes "1000000500". This typically means
that an implementation could use a different value from what it is
passing if it re-encodes it. Or maybe we should explicitly state that
certain header fields are integers and it's the recipient's responsibility
to ensure there's no fractional part. Content-length definitely is one
such sensitive field.

Willy

Received on Saturday, 16 July 2016 09:05:28 UTC