Re: [cors] security issue with XMLHttpRequest API compatibility

On Tue, Apr 7, 2009 at 10:38 AM, Tyler Close <tyler.close@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 6:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Mon, Apr 6, 2009 at 5:36 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>> On Mon, Apr 6, 2009 at 5:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> Additionally, if the attacker can make a GET request happen to
>>>> any URI but with a sensitive password added, it is quite likely that
>>>> this could be directed to some URI on the site that will for example
>>>> insert a comment into a forum, or otherwise publish the data to
>>>> somewhere where it can be read.
>>>
>>> If the site abuses GET in this way, then it is vulnerable to damage
>>> via a simple <img> tag constructed by the attacker (assuming the
>>> password rides along in a cookie, as is common).
>>
>> I don't mean that the harm is in that you can use CSRF attacks against
>> the site to insert forum posts.
>>
>> The attack against the site would go something like this:
>>
>> 1. Trick the site to issue a GET request to a URL that adds a post to
>> a public forum.
>> 2. Go to said public forum
>> 3. Read the newly posted item
>>
>> The URL in 1 will include the password since that was added to the
>> URL. It's possible that this will result in the password being part of
>> the posted forum item.
>>
>> In step 3 then you can read the secret password.
>>
>> This works in todays browsers that don't have cross site XMLHttpRequest.
>
> But the client-side code that adds the password to the URL is the
> site's own code, and so it knows it uses that parameter name to carry
> the password. Why would the site's own server-side code then read the
> password out of that query string parameter and put it in the forum
> post. This seems silly.

So we're talking about code running on 'targetsite.com' that looks
something like this:

function doSomeAction(uri) {
  var client = new XMLHttpRequest();
  fullURI = uri + "?passwd=" + s3cretToken;
  client.open("GET", fullURI);
  client.onload = updateUI;
  client.onerror = updateUI;
  client.onabort = updateUI;
  client.send();
}

Where the attacker has control over 'uri'. Right?

So in this case the attacker could set 'uri' to something like

http://targetsite.com/userSupportForum/addPost.cgi?name=evil+attacker&email=evil%40attacker.com&body=secret+token+to+follow

This will result is that the secret token is posted to a publicly
readable place.

My point is that the design you are describing is extremely risky.
Allowing yourself to send a secret token to an arbitrary uri on your
website is an exploit waiting to happen.

As I have said before. It is fully possible that this happens. It's
even possible that someone does this intentionally and that they have
vetted all CGIs running on the website to ensure that it is safe. And
that they continue to do this vetting any time more CGIs are added to
the website.

But it does, to me, seem very unlikely.

>> Additionally the API we're adding has a very
>> subtle difference, and one that is different only in the security
>> model.
>
> "only"? Since when is that an "only"?

My point is that having two APIs that are identical and intended to be
used for basically the same thing, except for that they use different
security models, is a security bug waiting to happen.

/ Jonas

Received on Tuesday, 7 April 2009 22:58:04 UTC