Re: [cors] security issue with XMLHttpRequest API compatibility

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.

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

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.

--Tyler

Received on Monday, 6 April 2009 23:37:47 UTC