HackerOne: CSRF possible when SOP Bypass/UXSS is available

Description
If an attacker could extract content from https://hackerone.com, they could perform CSRF attacks due to the fact that:

1. Some pages prints the token in the HTML response (edit user form at https://hackerone.com/settings/profile/edit)
2. Tokens aren’t bound per action
3. PATCH/DELETE can be sent via _method

Attacker being allowed to read content but not execute JS could happen if:

1. SOP Bypass in plugin (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3115)
2. SOP Bypass in application design (https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/)
3. UXSS (https://blog.innerht.ml/ie-uxss/)

Currently, some mitigations are in place. _method isn’t allowed in GET and the Origin header is checked. This isn’t enough since FireFox and IE doesn’t send Origin header when submitting forms.

Attack scenario
The most recent (to my knowledge) SOP bypass was the re-implementation of the IE UXSS bug (https://blog.innerht.ml/ie-uxss/). This was working November 28th 2015. However, the bug required framing at least one resource, and HackerOne sends X-Frame-Options on all resources. Sadly, HackerOne uses CloudFlare so the URL https://hackerone.com/cdn-cgi/trace could be used (doesn’t send X-Frame-Options).

So to sum up:

1. Logged in user visits attackers page in IE (vulnerable to UXSS)
2. UXSS runs script on framed “https://hackerone.com/cdn-cgi/trace” to extract CSRF token on https://hackerone.com/settings/profile/edit (via AJAX)
3. User is attacked with the extracted CSRF token

Fix
This could be mitigated by storing the token in JavaScript and adding the token to the form after the page is loaded.