Same-origin policy bypass via Flash on &



2 years ago
a year ago


(Reporter: arneswinnen, Assigned: tflanagan, NeedInfo)


(Blocks: 1 bug, {sec-low, wsec-crossdomain})

sec-low, wsec-crossdomain
Bug Flags:
sec-bounty -


(Whiteboard: [reporter-external] [web-bounty-form] [verif?], URL)


(1 attachment)



2 years ago
Created attachment 8793760 [details]

The crossdomain.xml file in the root of the two affected domains contains a wildcard, effectively bypassing the normal same-origin policy implemented in browsers via Flash, as they have their own implementation based on the crossdomain.xml file instead. This is a serious issue, since these two domains contain authenticated zones. The files are equal for both affected domains and designate wildcard "*" as origin domains who can access their (authenticated) content (see also screenshots):

<allow-access-from domain="*" to-ports="80,443,8100,8080"/>
<allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/>

The attack scenario is as follows: A victim logs in to one of these two domains, and then visits a website of the attacker in another browser tab. At that moment, the attacker can stealthily load an SWF file which will make hidden requests to the affected domains, and the browser will happily add session cookies to these requests. Now, the difference with a normal SOP implementation in the browser is that the attacker will actually be able to read the response of the requests made via the SWF file via a Flash-JavaScript bridge, which normally is prevented by the same-origin policy implemented in all modern browsers (including yours :-). The attacker can use this ability to read all authenticated content of the affected domains, and hence to both steal sensitive PII data from the authenticated victim, as well as to steal CSRF tokens from within the HTML pages. Thus, this issue also implies a global CSRF bypass for these websites through this vulnerability by design. Here's a step-by-step to reproduce the issue:

1. Browse to and login
2. Open a second browser tab and browse to (great PoC made by Matthew Bryant (mandatory), not me!)
3. Enter as Target URL and hit the execute button. This should result in a "securityErrorHandler:" response, indicating that is not vulnerable to the issue.
4. Enter any page on as Target URL, e.g., and hit the execute button. Now, the response window on the right should show the HTML of the landing page. If interested, one could also put an intercepting proxy between the browser and the server to see that the SWF on actually makes a request to, and that session cookies are transparently added by the browser. 

Of course, in a real attack, the attacker would not fetch the landing page, but pages containing sensitive data on /, such as profile pages. However, I couldn't find a quick way to make myself a test partners account, so that's why I chose for this PoC instead. Additionally, the PoC SWF used here still requires to enter Target URIs, but there are more stealthier SWFs from the same person who allow to perform this stealthily via JavaScript:

Recommendation: Remove the wildcard from the crossdomain.xml file in the root of the two affected subdomains, either completely or by a strict whitelist.


Flags: sec-bounty?
Verified the contents of crossdomain.xml's...

<cross-domain-policy><allow-access-from domain="*" to-ports="80,443,8100,8080"/><allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/></cross-domain-policy>

<cross-domain-policy><allow-access-from domain="*" to-ports="80,443,8100,8080"/><allow-http-request-headers-from domain="*" headers="SOAPAction,Authorization"/></cross-domain-policy>
Ever confirmed: true
Keywords: sec-low, wsec-crossdomain

Comment 3

2 years ago

I noticed you designated this as sec-low, which surprised me a bit. However, I don't really know the affected domains and their userbase, but just to make sure that we're on the same page here: Would an XSS/CSRF vulnerability on the authenticated zone of these domains also been designated as sec-low? The impact from this vulnerability is very similar: Confidentiality (sensitive data theft, e.g. via XSS) and Integrity (CSRF bypass, e.g. via CSRF token theft) are both compromised completely.



PS: Here's another good reference on the crossdomain.xml subject, of the author of the SWF POC tool himself:
I'm looking into what is exactly on these sites, if it turns out to be more critical than at first glance I'll up the rating.
See Also: → bug 1247876
Spoke to liz via IRC, she said Ty is the new admin for these.
Ty: can you have a peek at this issue? I don't have credentials on this site, so it's hard to understand impact for context.
Flags: needinfo?(tflanagan)
Caught up with Ty on IRC to understand the context better...
- Site is externally hosted with a vendor NetX, used for images/artwork delivery for partners
- We believe the site is mostly inactive at this time
- Ty is double checking to make sure before we request the DNS be pulled
- Auth is local auth only (so we don't expect any pivoting risk here if a cred was snagged)
- Site is externally hosted with a vendor NetX, used for images/artwork delivery
- It's possible it's inactive, but that is less clear than partners
- Ty is double checking to see if we can just decom it
- Auth is anonymous by default

Now knowing the above, I think the severity level of sec-low is still appropriate.

Comment 8

2 years ago
Fully agreed - I didn't have any context, was hoping for a real juicy partner portal, full of PII and financial data of course :-). Thanks for investigating, much appreciated.

Arne: thanks for all the submission, anytime we can identify a site that exists that is no longer being used, it's a big win (one less thing to secure).  Appreciated!
Ty is having some auth issues right now, but asked me to make note that he's reached out to the vendor and asked them to remove the crossdomain.xml references.
Assignee: nobody → tflanagan

Comment 11

2 years ago
I'm marking this as sec-bounty-, due to a combination of its low impact, being a 3rd party site and not on our bug bounty list.

Nevertheless, thank you for reporting this to us, as always.  We really appreciate it, Arne!
Flags: sec-bounty? → sec-bounty-
It appears that, at least at some point after this was filed, they removed these files.
Last Resolved: a year ago
Resolution: --- → FIXED


a year ago
Group: websites-security
You need to log in before you can comment on or make changes to this bug.