[e-lang] A promise based JSON command shell

[Mike Samuel]

2009/4/28 Tyler Close <tyler.close at gmail.com>:
> 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?

Yes, that's the one that occurs to me.  The link can change the URL
that will then be triggered by an actionless form that uses any of the
lib.Q methods to deliver the form data.

Perhaps encoding = in fragments from untrusted sources as %3d would
address the problem.

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