W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] security issue with XMLHttpRequest API compatibility

From: Tyler Close <tyler.close@gmail.com>
Date: Tue, 7 Apr 2009 10:38:30 -0700
Message-ID: <5691356f0904071038p586410ecteb6a72dc3778caa4@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps@w3.org
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.

>>> 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.
>> Seems simple enough to solve this problem by not substituting the
>> cross-site API for the non-cross-site API. Just using different
>> constructors and keeping the interface API the same would be
>> sufficient.
> While this is simple to do on the implementation side, it results in
> bloat on the usage side. I.e. we're adding more API to the web
> development platform.

I'm a little amused by the idea of the HTML5 group being concerned
about API bloat; especially when the proposal is only to use different
constructors to construct things with different security models. Were
talking about one new constructor name, or even just a new parameter
to the existing constructor, to signal that the client-code knows that
cross-origin requests may be made.

> 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"?

> I do have a very hard time judging what the right thing to do here is.


> I do agree there is a risk that what you are describing can happen.
> However I judge the risk to be very small, but non-zero. And the risk
> will decrease with time as people become aware of this new API.
> And the only solution is IMHO bad since it increases the complexity of
> the platform, which we'll have to live with for the foreseeable
> future.

For the archives, I'll just note that I think the WG is making a poor
choice here.

Received on Tuesday, 7 April 2009 17:39:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC