This repository was created to simplify the SWF-based JSON CSRF exploitation. It should work also with XML (and any other) data using optional parameters. Also it can be used for easy exploitation of crossdomain.xml misconfiguration (no need to compile .swf for each case).
Still working in:
This technique was mitigated in known popular browsers (Chrome, Firefox, Opera, Safari, Edge, IE) and can be considered obsolete at the date of April-May 2020. If you find that this behavior is still reproducible somewhere, feel free to open an issue.
Starting with Chrome 62, direct link to SWF file may not work. If this behavior happens, use HTML wrapper. Also it will require from the victim to click on the flash container first time to enable it, lowering impact due to the user interaction factor.
01.01.2018 - added HTML wrapper (
read.html, should be used with
test.swf) for better experience with Chrome. Usage and parameters are same as in case with test.swf. It supports also insecure crossdomain.xml exploitation (able to show the response from the target endpoint).
25.03.2018 - added UI wrapper for better experience (
ui.html + assets folder)
July 2018 - Fixed in the Firefox: https://www.mozilla.org/en-US/security/advisories/mfsa2018-15/#CVE-2018-12364
July 2019 - Fix bypass (via 308 redirect) fixed in the Firefox: https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11712
August 2019 - Flash was disabled by default in latest Chrome 76 builds.
Apr-May 2020 - Fixed in Chrome 81. The last tested Chrome browser where this technique was usable - 79.0.3945.88. Chrome 80 was not tested so it's unclear about status of this technique in that version.
Variations of target configuration
- Target site has no crossdomain.xml, or secure crossdomain.xml, not allowing domains you can control. In this case you can't get the response from target site, but still can conduct CSRF attacks with arbitrary Content-Type header, if CSRF protection relies only on the content-type (e.g. checking it for being specific type). In this case usage of 307 redirect is required, to bypass crossdomain.xml (it will be requested only after the csrf will take place).
- Target site has misconfigured crossdomain.xml, allowing domains you can control. In this case you can conduct both CSRF and response reading attacks. Usage of 307 redirect is not required.
The .swf file take 3 required and 2 optional parameters:
- jsonData - apparently, JSON Data:) Can be other type of data, if optional
ctparam specified. Can be empty
- php_url - URL of the 307 redirector php file. Can be empty (in this case SWF will request endpoint without 307 redirect - and likely will fail, if crossdomain.xml is secure, or not exist). You can implement your own redirector (not PHP), for example, if you are using different environment.
- endpoint - target endpoint, which is vulnerable to CSRF, or, if you're exploiting insecure crossdomain.xml, URL which response you want to read.
- ct (optional) - specify your own Content-Type. Without this parameter it will be
- reqmethod (optional) - specify your own request method. Without this parameter it will be
Place test.swf and test.php on your host, then simply call the SWF file with the correct parameters.
(As mentioned by @ziyaxanalbeniz) - we actually don't need crossdomain.xml from this repo, if test.php and test.swf are on same domain). Place it on your host if you also testing locally or across different domains.
Example call (outdated way, direct request to the SWF):
Note, if your request is very complex (consist with many params, special characters, etc), you may need to figure correct url-encoding for jsonData and endpoint parameters (Action Script code used in SWF doesn't implement URL encoding/decoding, this task is moved to the researcher's side). I recommend to use HTML wrappers in this case.
Preferred way - less bugs, less encoding problems, better compability with browsers
Using HTML wrapper - ui.html (handy UI, can be used for debugging) or read.html with test.swf, parameters are same:
You can modify HTML/JS code in the wrappers for your needs (add encoding, etc) same as 307 redirect script.
In case your target has crossdomain.xml misconfigured, or allowing your domain, you will also get the response using this wrapper. In this case you can use wrapper without 307 redirect (no need of
This is useful for Chrome >=62, where you can't access SWF directly, or if you want to exploit insecure crossdomain.xml. Note: if you are exploiting insecure crossdomain.xml, if the target site uses
https, your origin should also use https for successful response reading.
If you have the questions regarding this repository - ping me in the Twitter: @h1_sp1d3r
Example cases (CSRF)
- Exploit JSON CSRF, POST-based, 307 redirect:
- Exploit XML CSRF, POST-based, 307 redirect:
Example cases (read responses using insecure crossdomain.xml)
- Exploit insecure crossdomain.xml (read data from target), GET-based, no 307 redirect:
- Exploit insecure crossdomain.xml (read data from target), POST-based, any content-type supported, no 307 redirect:
Cross Browser Testing
This project is tested on following browsers as follows:
Notes: ✓ - Works, X - doesn't work
Special thanks to the @emgeekboy, who inspired me to make this repository and most functionality, and @hivarekarpranav, who did the cross-browser and request methods research. Related blog posts about this:
- https://firstname.lastname@example.org/bypassing-crossdomain-policy-and-hit-hundreds-of-top-alexa-sites-af1944f6bbf5 - thanks to the @knowledge_2014, who inspired me to implement the response reading component
This repository is made for educational and ethical testing purposes only. Usage for attacking targets without prior mutual consent is illegal. By using this testing tool you accept the fact that any damage (dataleak, system compromise, etc.) caused by the use of this tool is your responsibility.
- Can we read response from server?
Answer: no. Because of SOP. Still, if crossdomain.xml on the target host exist, and misconfigured - in this case yes.
- Does it work with requests other than GET/POST?
- Does it possible to craft custom headers like X-Requested-With, Origin or Referrer?
Answer: no (it was possible in the past, but not now).