[e-lang] A promise based JSON command shell

[Mike Samuel]

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

This is not a requirement.
The requirement is
    1. There's an authorization secret in the base URL or among the
form inputs that are submitted.
Obviously if the form submission uses method GET, then it would whack
the query string and fragment, but having lib.Q turn the fragment into
GET parameters only makes sense for the POST operations in lib.Q if
you assume that some servers are going to look at GET parameters when
POSTing.



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

Ok.  Maybe I misunderstand how the lib.Q methods transfer the data.  I
assumed you were turning those into a mime-encoded string and POSTing
it, but now that I think about it, that wouldn't work.

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

It didn't seem unlikely to me.   modPHP in some common configurations
flattens POST and GET parameters into the same namespace.
If I misunderstood how the request entity is encoded then maybe you
don't have to worry about legacy badness.


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