[cap-talk] Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
Mark S. Miller
erights at google.com
Sun Jun 7 18:21:40 EDT 2009
On Sun, Jun 7, 2009 at 12:17 PM, Adam Barth <w3c at adambarth.com> wrote:
> > On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights at google.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090607/072e1fe3/attachment.html
More information about the cap-talk
mailing list