Subject: Re: [httpwg/http-extensions] JFV + ECMA-262 (#225)

From: HTTP issue updates <[email-masked]>
Date: Wed, 10 Aug 2016 20:43:16 -0700

Right. The pushback against doing something like this that I've heard is that no matter what we say in the spec, people are going to just point the JSON parser they have at hand at the header field value, and trust what it gives them. 

As such, using JSON is a bit of an attractive nuisance.

It may be that we can specify a profile of JSON that is safe to use, **and** create a set of easy-to-use libraries and get them into the relevant server-side platforms, but that's a substantial amount of effort (any volunteers?), and the natural lag of many distros/platforms means that they might not be available for some time (leading people to use plain JSON parsers).

The most serious issue is undoubtedly the number format. Perhaps cautioning against minting headers that use non-integer numbers would be a workable stopgap (although the temptation might be quite strong in some use cases).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-239065536

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 10 Aug 2016 21:55:00 -0700

Strongly warning seems reasonable. I'm not aware of any existing efforts that are planning to use non-integer values + JFV, but making that a requirement doesn't feel right either.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-239073939

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 11 Aug 2016 11:32:35 -0700

A JSON profile, strict modes, wrapper API suggestions, and/or strong warnings simply document attack vectors without solving the underlying problem. If JSON is the answer, then it comes with a "fuzzy numbers" problem that does not have reliable solutions. You can sugar-coat it or hope that it will go away in 20 years, but you cannot solve it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-239249809

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 11 Aug 2016 17:37:20 -0700

@igrigorik @mnot 
If we are to going to use a modified variant of JSON, I strongly support disallowing non-integer numbers.

Using ECMA262's definition of number would not help us, neither in terms of the definition or the ease of implementation.

Regarding the definition, my understanding is that ECMA262 merely specifies how the numbers should look like as strings, but does _not_ specify _how_ the strings should be converted to IEEE754 numbers. Lack of a formal definition of such procedure is what leads us to disagreements between the implementation (that in turn becomes a cradle of vulnerabilities).

Regarding the ease of implementation, ECMA262 is a _superset_ of JSON in terms of how numbers can be represented (i.e. binary, octal and hexadecimal representations), which seems unnecessary complex to me.

@mnot 
> It may be that we can specify a profile of JSON that is safe to use, and create a set of easy-to-use libraries and get them into the relevant server-side platforms, but that's a substantial amount of effort (any volunteers?)

It _might_ be possible to filter out JSON containing floating point representations _before_ applying a JSON parser, and in that regard, using [json2.js](https://github.com/douglascrockford/JSON-js) (that uses `eval` to parse JSON after filtering out dangerous strings) as a basis might be worth considering. I anticipate that just modifying the number representation in [this regexp](https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L163) would be sufficient for the matter.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-239333849

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 15 Aug 2016 17:26:03 -0700

Parallel thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/thread.html#msg436

@rousskov I appreciate where you're coming from, but (personally, at least) I think that paints an overly black and white prognosis. I think we _could_ make reasonable progress here with a restricted set + browsers enforcement.

@kazuho @mnot I can't shake the feeling that restricting to integer values will come back to bite us, but if you think otherwise.. *shrug*, we can give it a shot.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-239969028

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 16 Aug 2016 11:06:28 -0700

@igrigorik I agree -- _reasonable progress_ is very possible, for some definition of reasonable, especially if your primary focus is "browsers". That reasonable progress will not solve the problem -- fuzzy JSON numbers will cause CVEs. If reasonable progress [with browsers] is good enough, and a few design-triggered CVEs are not important enough, then this JSON problem is not a big deal at all.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/225#issuecomment-240187136