swf_json_csrf: simplify the SWF-based JSON CSRF exploitation
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).
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 the target site, but still can conduct CSRF attacks with an arbitrary Content-Type header, if CSRF protection relies only on the content-type (e.g. checking it for being a specific type). In this case usage of 307 redirects 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 redirects is not required.
git clone https://github.com/sp1d3r/swf_json_csrf.git
The .swf file takes 3 required and 2 optional parameters:
- jsonData – apparently, JSON Data:) Can be other types of data, if optional ct param 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)
- 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 in the same domain). Place it on your host if you also testing locally or across different domains.
Example cases (CSRF)
- Exploit JSON CSRF, POST-based, 307 redirects:
or, using HTML wrapper:
- 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 redirects:
Cross Browser Testing
This project is tested on following browsers as follows:
Notes: ✓ – Works, X – doesn’t work
Starting with Chrome 62, direct link to SWF file may not work. If this behavior happens, use HTML wrapper.
01.01.2018 – added HTML wrapper (
read.html, should be used with
test.swf) for the better experience with Chrome. Usage and parameters are same as in the case with test.swf. It supports also insecure crossdomain.xml exploitation (able to show the response from the target endpoint).
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://email@example.com/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.