Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)

[Mark S. Miller-2]

[+www-tag]

I have received several private responses to my post, but oddly, nothing public yet. In these responses, I have been asked most frequently about:

On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@...> wrote:

Why identify even same origin requests as cross-origin? Given that all
cross-origin requests are identified as such, then even without the normal
credentials, the mere absence of an origin header identifies the
requestor as being from the same origin. This is in fact a form of
credential. If the containing page does not consider the script in
question to speak for it, then it shouldn't be allowed to implicitly
claim (by the absence of an origin header) to be from the same origin.

 

Since malicious machines, or malicious applications running on trusted machines, can sent messages that aren't self-identified as cross origin, why do I suggest that lack of an origin header (in the absence of other credentials) might lead a server into granting more access than it would for messages self-identified as "Origin: null"?

For servers reachable from the open internet, such server behavior would indeed be nonsensical. However, many servers are behind corporate firewalls and not reachable from the open internet. The premise firewalls rely on, whether sensible or not, is that all software running behind that firewall that can send arbitrary network messages are not malicious. Under this assumptions, browsers behind the firewall are assumed not to be malicious themselves, but of course may be running malicious scripts associated only with origins outside the firewall. These can of course cause their browser to initiate network messages to severs within the firewall, but only messages identified with browser-imposed headers. For messages not identified as cross origin, a server can assume that either the initiating program is non-malicious (because it is associated with the server's behind-the-firewall origin) or that the initiating program will not receive the results of the request.

Under these admittedly fragile (but common) assumptions, a server may indeed "trust" a message that doesn't identify itself as cross origin more than it "trusts" one that does. Thus, a non malicious script that doesn't wish the sanitized scripts it loads to "speak for it" should force all the messages they initiate to be identified as "Origin: null".

--
   Cheers,
   --MarkM

[Adam Barth-5]

On Fri, Jun 5, 2009 at 9:42 PM, Mark S. Miller <erights@...> wrote:
> [+www-tag]
>
> I have received several private responses to my post, but oddly, nothing
> public yet. In these responses, I have been asked most frequently about:

Sorry for the lag in public comments.

> On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@...> wrote:
> Since malicious machines, or malicious applications running on trusted
> machines, can sent messages that aren't self-identified as cross origin, why
> do I suggest that lack of an origin header (in the absence of other
> credentials) might lead a server into granting more access than it would for
> messages self-identified as "Origin: null"?
>
> For servers reachable from the open internet, such server behavior would
> indeed be nonsensical. However, many servers are behind corporate firewalls
> and not reachable from the open internet. The premise firewalls rely on,
> whether sensible or not, is that all software running behind that firewall
> that can send arbitrary network messages are not malicious. Under this
> assumptions, browsers behind the firewall are assumed not to be malicious
> themselves, but of course may be running malicious scripts associated only
> with origins outside the firewall. These can of course cause their browser
> to initiate network messages to severs within the firewall, but only
> messages identified with browser-imposed headers. For messages not
> identified as cross origin, a server can assume that either the initiating
> program is non-malicious (because it is associated with the server's
> behind-the-firewall origin) or that the initiating program will not receive
> the results of the request.

This seems like a lot of speculation.  Do you have any evidence to
support this hypothesis?

> Under these admittedly fragile (but common) assumptions, a server may indeed
> "trust" a message that doesn't identify itself as cross origin more than it
> "trusts" one that does. Thus, a non malicious script that doesn't wish the
> sanitized scripts it loads to "speak for it" should force all the messages
> they initiate to be identified as "Origin: null".

If this were the case, we'd have this same problem with Referer,
postMessage, Origin-for-CORS, and numerous other web technologies.

Adam

[Mark S. Miller-2]

On Sun, Jun 7, 2009 at 12:17 PM, Adam Barth <w3c@...> wrote:

> On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@...> wrote:

> Since malicious machines, or malicious applications running on trusted
> machines, can sent messages that aren't self-identified as cross origin, why
> do I suggest that lack of an origin header (in the absence of other
> credentials) might lead a server into granting more access than it would for
> messages self-identified as "Origin: null"?
> [...speculation about firewall-based patterns...]

This seems like a lot of speculation.  Do you have any evidence to
support this hypothesis?

Only projecting from my experience of how bad security decisions are made by those who think unclearly about how their firewall does and does not protect them. I have no other evidence.
 

> Under these admittedly fragile (but common) assumptions, a server may indeed
> "trust" a message that doesn't identify itself as cross origin more than it
> "trusts" one that does. Thus, a non malicious script that doesn't wish the
> sanitized scripts it loads to "speak for it" should force all the messages
> they initiate to be identified as "Origin: null".

If this were the case, we'd have this same problem with Referer,
postMessage, Origin-for-CORS, and numerous other web technologies.

If the hypothesis I am raising is indeed not a problem, then it doesn't matter whether these same origin requests carry "Origin: null" or nothing. What matters is that JavaScript code have a standard way to request their browser to issue requests carrying no other credentials, even if back to the same origin. Then, we can successfully encourage servers to honor requests based only on authorizing information explicitly placed into the payload of these messages -- such as the current use of secret tokens for XSRF protection. If there's any reason for the non-uniformity you suggest, I agree that the remaining danger of encouraging unsafe server behavior would probably be small enough to live with. But what would this compromise accomplish?

--
   Cheers,
   --MarkM

[Adam Barth-5]

On Sun, Jun 7, 2009 at 3:21 PM, Mark S. Miller <erights@...> wrote:
> If the hypothesis I am raising is indeed not a problem, then it doesn't
> matter whether these same origin requests carry "Origin: null" or nothing.
> What matters is that JavaScript code have a standard way to request their
> browser to issue requests carrying no other credentials, even if back to the
> same origin.

Yeah, I can see that as being useful.  I encourage you to propose a
new API that does this.  The Origin-header-as-CSRF-defense already
provides for this possibility.  Is there something specific you'd like
me to change in the I-D to support this new API?

Adam

[Mark S. Miller-2]

I started this thread with a large recipient list so that others I expect to be interested would be aware of it. All further messages on this thread should occur only on <public-webapps@...>. I will direct all my further replies only there.

Sorry for any unnecessary or inappropriate noise.

--
   Cheers,
   --MarkM