Re: A promise based JSON command shell

On Tue, Apr 28, 2009 at 12:14 PM, Mike Samuel <[email protected]> wrote:
> 2009/4/28 Tyler Close <[email protected]>:
>> 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.

So the <form> has an onsubmit handler like:

function () {
    var target = lib.web.getLocation();
    lib.Q.post(target, 'foo', [ ... arguments taken from HTML form ]);
}

The window.location has the fragment from the <a> tag provided by the attacker.

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

Requirement 1 is a bad idea to start with, since the secret will also
leak via the HTTP Referer header.

Requirement 2 seems plausible.

Requirement 3 seems unlikely, since all legitimate requests have the
form data in the request entity. The server-side needs special code
dedicated to handling just the attack scenario.

Unless we can come up with some way to eliminate at least requirement
3, I don't think there's something here to be fixed. Agree?

--Tyler