Re: [cors] security issue with XMLHttpRequest API compatibility

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.

>> 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. Additionally the API we're adding has a very
subtle difference, and one that is different only in the security
model.

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.

/ Jonas

Received on Tuesday, 7 April 2009 01:32:09 UTC