[e-lang] A promise based JSON command shell

[Tyler Close]

More inline below...

On Tue, Apr 28, 2009 at 11:50 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
> 2009/4/28 Tyler Close <tyler.close at gmail.com>:
>> 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.

So, the scenario is:

The browser's window.location is:
<https://example.com/foo?secret=asdfasdf>

And the attacker can put a link on that page:
<a href="#iagree=yes">click me</a>

Thus causing a GET request to:
<https://example.com/foo?secret=asdfasdf&iagree=yes>

Are there additional scenarios you're thinking of, or is that the only one?

>> 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.

I'd be willing to do something like:

<script type="text/javascript" src="/site/json_sans_eval.js"></script>
<script type="text/javascript" src="/site/json2.js"></script>

Your json_sans_eval.js should then create JSON.parse only if it does
not already exist. I think json2.js will then fill in JSON.stringify,
leaving your JSON.parse implementation in place.

--Tyler