Re: [cors] security issue with XMLHttpRequest API compatibility

On Mon, Apr 6, 2009 at 4:37 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 4:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Ah, ok, I'm following you now.
>>
>> This seems like a very risky situation already for the site since it
>> would allow for an attacker to issue a DELETE request to any URI on
>> the site. A request that would include the users credentials such as
>> auth tokens and session-id bearing cookies. So the site has
>> essentially CSRFed itself in a pretty bad way.
>
> Then consider a similar scenario, where it's a GET request (or another
> HTTP safe method) and the function adds the password as a query
> parameter to a URL plucked from the page content. When issuing the
> request via XMLHttpRequest, that may be a safe design for viewing
> content specified by other users. Again with the blogging example, the
> site is an access-controlled message store and users exchange URLs
> that identify messages.

The two common safe HTTP methods, GET and HEAD would mean that the
password is transferred as part of the URI, something that is also a
very bad security design since URIs tend to be logged in numerous
places. 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.

The other remaining safe HTTP method that I know about is OPTIONS, but
the likelihood that someone is using that in the way you describe
seems extremely unlikely.


>> But I do agree that it adds I do agree that this is a theoretical
>> risk. I'm not sure if this risk is big enough that it's something that
>> we need to adjust the specs to.
>
> I don't have any numbers, but I believe using a plaintext password in
> the request body or URL is a fairly common design in web applications.
> I certainly see it in a lot of protocol documentation. Before CORS,
> there was no threat of this password being sent to the wrong site,
> since the client code could only message with the one site. Now the
> attacker can instruct the browser to message with additional sites.

I agree that transferring the password in the body of a request is
likely to be common. But doing so while using an externally provided
URI without doing any checking of that URI seems much less likely.

Have you ever heard of such a thing being part of a common design for
a protocol? Or even seen it appear on a site?

For every single feature we add, security related or otherwise, there
is a theoretical risk that a security problem can appear on a site. We
have to weigh that risk against the benefits that the feature
provides, otherwise we are never going to build anything new.

In this case it does seem like the design you are describing above
carries some pretty significant risks for the deployer already. Even
though it's possible that they are currently not exploitable. It seems
unlikely to me that someone made an intentional decision to rely on
the XMLHttpRequest security model for this, and more likely that they
had a bug in the code, but happened to be saved by it.

> Looking over the current CORS spec, all the security language seems
> concerned with protecting existing server resources. Protecting
> existing browser-side application code seems like a blind spot.
> Perhaps there are other issues lurking in this blind spot.

Indeed. Any help here would be great.

/ Jonas

Received on Tuesday, 7 April 2009 00:23:33 UTC