[e-lang] A promise based JSON command shell

[Mike Samuel]

2009/4/28 Tyler Close <tyler.close at gmail.com>:
> Hi Mike,
>
> Thanks for the feedback. Responses inline below...
>
> On Tue, Apr 28, 2009 at 11:03 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> From http://waterken.sourceforge.net/web_send/
>>
>>    fragment arguments
>>
>>    Sometimes, it is useful to include information in a URL that won't
>>    show up in the HTTP protocol's Referer header, but can be made
>>    available to the server that issued the URL. To support this, the
>>    web_send library can move information in the URL fragment to
>>    the query component of the Request-URI. For example, for the call:
>>
>>    lib.Q.get(drum, 'hits');
>>
>>    target URLref       Request-URI
>>    /myApp#s=obj456     /myApp?q=hits&s=obj456
>>
>> This scheme seems to take fragment parts and merge them into the
>> namespace of form parameters.  So if someone can control a link on the
>> page and get the user to click it, then they can potentially add query
>> parameters, allowing them to spoof an enabled checkbox, or radio
>> button.
>
> If the attacker can control the link, can't they also put these
> parameters directly into the URL's query string?

They could, but they could not cause secrets they don't have to be
included as other query parameters.  The combination of secrets from
javascript combined with added/masked cgi parameters from a link
clicked earlier might allow for a different class of attacks.


>> Could query parameters derived from the fragment portion be moved into
>> a namespace less likely to conflict with form data?
>
> The issuer of the URLref can use whatever query parameter naming
> convention they like. The web_send library will just copy the data
> over.
>
>> Shameless plug follows.
>>
>>    The key components are:
>>
>>    json2.js
>>        JSON encoding and decoding
>>
>> If you want to avoid using json2's JSON.parse which delegates to eval,
>> http://code.google.com/p/json-sans-eval/source/browse/trunk/src/json_sans_eval.js
>> is a fast JSON parser that doesn't use eval under the hood.
>
> That sounds good, but I'd like something that is API compatible with
> the JSON object. Crock's json2.js first checks to see if there's
> already a JSON object defined and only provides one if it doesn't
> already exist. I believe this implementation allows the browser to
> substitute it's own native JSON parser, which I believe many browsers
> are planning to do. If you changed the boilerplate around your
> implementation to follow the same convention, I'd be tempted to
> switch.

Yeah.  It's meant to be a drop-in replacement for JSON.parse, but does
not implement JSON.stringify.  I'll see what I can do.

> --Tyler