Re: A promise based JSON command shell

2009/4/28 Tyler Close <[email protected]>:
> 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?

I doubt it.

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

I think that makes sense then.  I was assuming this was a way to
interact with an arbitrary backend, but it looks like the different
encodings used effectively sequesters the entity from parameters
injectable by crafted links.


> 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
>
_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang