[e-lang] A promise based JSON command shell

[Tyler Close]

On Tue, Apr 28, 2009 at 2:12 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> Tyler Close wrote:
>> On Tue, Apr 28, 2009 at 12:14 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>>> 2009/4/28 Tyler Close <tyler.close at gmail.com>:
>>>> 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.  [...]
>>
>> For this attack to work, all of the following must be true:
>> 1. There's an authorization secret somewhere in the base URL
>> 2. The attacker can put an <a> tag on the page and get the user to click it.
>> 3. The server treats query string arguments as overrides of the
>> arguments in the JSON request entity. (the lib.Q methods don't provide
>> a way to put form data in the Request-URI, other than the 'q'
>> parameter, so the form data must be in the JSON request entity).
>
> If the fragment is #q=foo, can that override the 'q' parameter?

It shouldn't, but a correct server is assumed. For example,:

target URLref: <https://example.com/app#q=foo>
command: lib.Q.post(target, 'bar', [ ])
Request-URI: <https://example.com/app?q=bar&q=foo>

So the server has to be smart enough to use the first 'q' and not the
second. Either that, or ensure that requirements 1 or 2 don't hold.

--Tyler