On Wed, Sep 19, 2018, 4:07 PM J Decker <[email protected]> wrote:
> (trimmed)
>
> On Wed, Sep 19, 2018 at 12:08 PM Mike Samuel <[email protected]> wrote:
>
>>
>>
>> On Wed, Sep 19, 2018 at 12:01 PM J Decker <[email protected]> wrote:
>>
>>>
>>> I know of no exploits; all resulting strings should be shorter than the
>>> input (because of escapes \\ ). The C version allocates a output buffer
>>> that is the same size as the input, and moves decoded strings into it.
>>> Structure characters [ { } ] , " ' ` don't transfer either.
>>>
>>
>> Not a vulnerability in your JSOX implementation per se, but have you
>> looked into whether there's exploitable ambiguity between JSOX and runs of
>> ES BlockStatements and ExpressionStatements?
>>
>> JSON used to be vulnerable
>> <https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/>
>> to cross-site snooping.
>>
>> <script>// In attacker page
>> Array = function () { alert('Got ' + arguments[0]) };
>> </script>
>> <script src="
>> http://other-origin/some-web-service-that-responds-with-a-json-array
>> "></script>
>>
>
> Interesting; that applies to JSOX for Number, BigInt, Date, ....
>
> Parenthesis (in the C version) fault while collecting an identifier as
> being a non-identifier character as defined by Unicode Standards.... (as
> per rules of an identifier in ES6)
> That lookup was omitted in the JS implementation. (per character search
> through several thousand values.)
>
> Parenthesis is reserved for code, expressions, parameter specifications,
> and is (should be) forbidden except in strings.
>
My apologies. I thought there were parentheses in the docs on npmjs but
seeing what I pasted from there on my phone it's obvious that it's all
curly brackets.
As long as your syntax doesn't include parentheses, dots, or backticks
you're probably fine.
>
>>
>> This allowed piggybacking on HTTP credentials if an attacker could get a
>> victim to visit their page.
>>
>> The problem was that the meaning of [...] and {...} were specified in
>> terms of global.Array and global.Object
>> which could be replaced
>>
>> That's been fixed, but JSOX should probably be careful about any
>> ambiguity with BlockStatement.
>> IIUC,
>> { keyword: [] }
>> is valid as a statement so there is some ambiguity there.
>>
>> Then I see examples like
>>
>> //-- the following...
>> a { firstField, secondField }
>> [ a { 1, 2 }, a{5,6}, a{"val1","val2"} ]
>>
>> Ya, it's tempting to type parenthesis after an identifer (fixed above)
>
> [ {firstField:1, secondField:2 }, {firstField:5,secondField:6},
> {firstField:"val1",secondField:"val2"} ]
>
> But that doesn't really generate any more data; (similar strings get
> collapsed?)... and on parsing, there's only one reference to 'firstField'
> and 'secondField'... I was trying to ponder scenarios where the data grows
> unbounded... but even in a case where there's a reference like
>
> [ {a:1, b:2 }, [ref[0],ref[0]], [ref[1],ref[1]], [ref[2],ref[2]] ]
>
> [ {a:1,b:2}, [ {a:1, b:2}, {a:1,b:2} ], [ [{a:1, b:2}, {a:1,b:2}],[{a:1,
> b:2}, {a:1,b:2}] ], [ [ [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ], [
> [{a:1, b:2}, {a:1,b:2}],[{a:1, b:2}, {a:1,b:2}] ] ] ]
>
> But it's not really replicated data, in the meta data between parsing and
> object assembly, it's an array of strings/numbers; and resolves to pointers
> to existing data.
>
>
> I haven't worked through your grammar, but I wonder whether a naive JSOX
>> encoder might produce output like
>> { looksLikeAStatementLabel: a{"val1", "val2"} }
>>
>
> (yes, but not parentheses. Because parens are not control characters, the
> end up being gatherable into identifiers)
>
> or
>> a
>> { onlyField }
>>
>
> The current parsing will drop 'onlyField' and result with {}.
> It only 'pushes' the value into the container if there is a value.
>
> It was previously is a parsing error, no value for field... 'expected ':'
> and a value' sort of thing; But I ran into '{}' which is a similar parsing
> state...
>
>
>
>> [ a(5), a("val1") ]
>> allowing an attacker to do
>> <script>
>> let onlyField = null;
>> function a(...data) {
>> alert(`Got ${ data }`);
>> }
>> </script>
>> <script src="http://other-origin/jsox-web-service";></script>
>>
>> There's a lot of "ifs" in this scenario,
>> AND CORS solves a lot of these problems for origins that use it
>> AND browsers are less trusting of script srcs with
>> Content-types:text/x-jsox than they were in 2008
>> BUT
>> // attacker setup
>> let onlyField = null;
>> function a(...data) {
>> alert(`Got ${ data }`);
>> }
>> // victim responds
>> a
>> { onlyField }
>> [ a(5), a("val1") ]
>> does alert twice in Chrome and JSON hijacking was exploited in the wild,
>> serializers have been known to
>> line wrap in attacker-controllable ways, and there may still be many JSON
>> webservices that respect ambient
>> credentials on cross-origin requests.
>>
>
> In the first case a(5) turns out to be a valid identifier, which is also
> sort of a string, and the second one would fault finding a " in the middle
> of a identifier... string-string is never allowed... "a""b"; but I see...
> it does depend on how parsing is implemented; grabbing the values with a
> regexp could do that.
>
>
>>
>>
>>
>>> This does stick to JSON's spirit of only transporting data. The parser
>>> is very similar to a JSON parser, except many places that would previously
>>> throw are accepted....
>>> And references can only link to other objects/arrays within the current
>>> outermost object/array.
>>>
>>
>>
>>
>>>
>>>> This already happens with plain JSON
>>>> <https://medium.com/@mikesamuel/protecting-against-object-forgery-2d0fd930a7a9>,
>>>> so anything that allows external inputs to specify which internal types to
>>>> construct would have to include a "Security Considerations" section that
>>>> explains how this could be safely used by code that assumes that `if (x
>>>> instanceof InternalType)` then x came from internal code that made a
>>>> good-faith effort to only pass appropriate inputs to `new
>>>> InternalType(...)`.
>>>>
>>>> On Tue, Sep 18, 2018 at 5:22 PM J Decker <[email protected]> wrote:
>>>>
>>>>> (Thank you Rod Sterling)
>>>>>
>>>>> But seriously, I'd like to submit, for serious consideration, JSOX -
>>>>> JavaScript Object eXchange format. It inherits all JSON syntax such that
>>>>> it is able to process any existing JSON.
>>>>>
>>>>> I'm, at this point, open to changing anything (or even omitting
>>>>> things), including the name.
>>>>>
>>>>> JSON is great. JSON has some limits, and criticisms... JS/ES Grew ,
>>>>> but JSON has to stay the same, similarly with whatever comes next I'd
>>>>> imagine.
>>>>>
>>>>> So a primary goal is to encode and decode ES6 objects for transport
>>>>> with a simple API such as JSOX.parse( object ), and JSOX.stringify(
>>>>> jsoxString ). But also keep with the simplicity of JSON,
>>>>> so it can be used in human readable circumstances.
>>>>>
>>>>> Types that are now (or soon) native to ES such as TypedArrays (binary
>>>>> data), BigInt types, and even the existing Date type, do not transport
>>>>> with
>>>>> JSON very well. They become a non-identifable string, that requires extra
>>>>> code involving knowledge of the structure of the data being transferred to
>>>>> be able to restore the values to Date(), BigInt(), et al.
>>>>>
>>>>> So a few weeks ago I started considering what else, beyond these
>>>>> simple modifications might also be useful, or address criticisms of JSON.
>>>>> Handling the above types is really a trivial modification to most JSON
>>>>> parsers. Each of the following modifications is really only a very slight
>>>>> change to behavior; although implementing typed-objects does initially
>>>>> involve changing error handling into identifer-fallback handling.
>>>>>
>>>>> I initially argued, that defining a object prototype
>>>>> 'card(name,address,zipcode,created)' which removes the redundant data for
>>>>> every following reference, (and is good, just for data reduction, which
>>>>> was
>>>>> argued 'gzip'). A JSON representation might be
>>>>> `{"name":"bob","address":"123
>>>>> street","zipcode":"55555","created":1537304820} where if have a large
>>>>> number of the same record the same 'name':,'address':, etc is repeated in
>>>>> every record. Where a typed-object's value in JSOX could be
>>>>> `card{:"bob","123 street","55555",2018-09-18T21:07:00Z}`. All objects
>>>>> that
>>>>> are revived as typed-objects share the same prototype, and before parsing,
>>>>> the prototypes to be used may be specified. The amount of data to process
>>>>> is reduced, perhaps to a significant degree.
>>>>>
>>>>> So <Identifer> '{' is about typed-objects. This construct is not
>>>>> allowed in JSON. But that then leads to <Identifier> '[' - typed arrays,
>>>>> arrays don't really have redundant data potential like objects, but there
>>>>> are TypedArrays in ES. There is no way to define a type of an array, but
>>>>> hardcoded types like 'ab', 'u8', 'ref' are used to revive binary data.
>>>>> The
>>>>> bytes of the backing ArrayBuffer are encoded to base64, and included
>>>>> within
>>>>> '[' and ']' without quotes; using the brackets as quotes.
>>>>>
>>>>> A JSOX typed array is the 'ref' type. A reference to another location
>>>>> in the current object can be specified, which allows encoding cyclic
>>>>> structures.
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/d3x0r/jsox
>>>>> https://npmjs.com/package/jsox
>>>>>
>>>>> (Initial public reaction was not very helpful, but probably that's the
>>>>> fault of how it was introduced?)
>>>>>
>>>>> https://www.reddit.com/r/javascript/comments/9f8wml/jsox_javascript_object_exchange_format_preview/
>>>>>
>>>>> There was plenty of 'why not [YAML/BSON/protobufs/(I don't think
>>>>> anyone said XML)/...]' and the answer is simply, because none of those
>>>>> read JSON, or have as simple of an API. (amongst other reasons that JSON
>>>>> is
>>>>> already a solution for compared to those mentioned)
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [email protected]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
