Re: [cors] security issue with XMLHttpRequest API compatibility

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

Checking anything seems much less common than one would like.
Especially when the browser is providing protection that makes the
check unnecessary.

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

Sure, AtomPub is based on users exchanging URLs and issuing requests
with their own credentials.

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

--Tyler

Received on Tuesday, 7 April 2009 00:37:34 UTC