[e-lang] A promise based JSON command shell

Mike Samuel mikesamuel at gmail.com
Tue Apr 28 19:31:00 EDT 2009

2009/4/28 Tyler Close <tyler.close at gmail.com>:
> On Tue, Apr 28, 2009 at 3:34 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> 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.
> 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

More information about the e-lang mailing list