Re: A promise based JSON command shell

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

Good point.

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

The third argument to Q.post() is a JSON value to be encoded as JSON
text and sent as the request entity in an HTTP POST request.

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

Is modPHP JSON savvy, such that it somehow turns the POST request
entity into application/x-www-form-urlencoded?

Remember that I'm only trying for a browser shell for JSON resources,
not arbitrary web resources.

In response to this conversation, I've added a Security Considerations
section to the documentation. See:

http://waterken.sourceforge.net/web_send/#securityConsiderations

I also put in an acknowledgments section. Let me know if you do/don't
want your name in there.

http://waterken.sourceforge.net/web_send/#acknowledgments

--Tyler