Timeline for CSRF protection with custom headers (and without validating token)
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 9, 2024 at 9:07 | history | suggested | kbolino | CC BY-SA 4.0 | fix link rot |
| Jan 8, 2024 at 21:45 | review | Suggested edits | |||
| S Jan 9, 2024 at 9:07 | |||||
| S Oct 13, 2019 at 10:49 | history | suggested | jub0bs | CC BY-SA 4.0 | fix typos etc. |
| Oct 12, 2019 at 8:11 | review | Suggested edits | |||
| S Oct 13, 2019 at 10:49 | |||||
| Jul 25, 2016 at 20:31 | comment | added | rook | @JMM that wiki page has changed a lot, but yeah it looks good. Having a random token and an origin check can only be bypassed using XSS or another SOP bypass similar to XSS. | |
| Jul 25, 2016 at 20:14 | comment | added | JMM | The OWASP CSRF Prevention Cheat Sheet linked from this answer currently (last revision 2016-05-22) endorses the technique raised by the OP for "REST Services". (It mentions X-Requested-With header.) They do mention Flash vulnerabilities that undermine it, but say they believe that using it in conjunction with checking Origin header makes it secure. | |
| May 13, 2013 at 16:34 | history | edited | rook | CC BY-SA 3.0 | added 371 characters in body |
| May 13, 2013 at 16:32 | comment | added | rook | @Simon Lieschke So a few months ago, navigateToURL() didn't require a crossdomain.xml policy, it looks like this vulnerability has been patched and my exploit has been fixed. Oah well. It also looks like the CORS rules have changed to have a "preflight" options request for requests with special headers with JS. This type of attack is more difficult to carry out. You might want to post a question about this to all of security.se | |
| May 13, 2013 at 16:05 | comment | added | rook | @Simon Lieschke something might have changed with the latest version of flash... let me check it out. | |
| May 13, 2013 at 2:24 | comment | added | Simon Lieschke | I'm unable to reproduce your example and can't get the CSRF-Request-Builder to perform a cross domain request with the X-Requested-By header. It always requests crossdomain.xml first and it only sends the POST request if the crossdomain.xml allows it with a line like <allow-http-request-headers-from domain="*" headers="X-Requested-By"/>. I tried with CSRF-Request-Builder hosted on the filesystem and loaded from another web server. I tested this with Flash 11.7.700.179 with Chrome 26.0.1410.64, Firefox 20.0.1 and Internet Explorer 9.0.8112.16421. | |
| May 10, 2013 at 7:19 | comment | added | rook | @Simon Lieschke No this does not come into play, because a cross-domain policy is not loaded by this ActionScript client. This ability to control headers is not an ability granted by the "cross-domain policy", it is just native behavior. | |
| May 10, 2013 at 1:34 | comment | added | Simon Lieschke | Wouldn't whether the custom header gets sent be subject to the cross-domain policy for the remote site as per helpx.adobe.com/flash-player/kb/…? | |
| Oct 30, 2012 at 15:57 | history | edited | rook | CC BY-SA 3.0 | added 56 characters in body |
| Oct 30, 2012 at 15:47 | history | answered | rook | CC BY-SA 3.0 |