dagobah

I think https://en.wikipedia.org/wiki/Cross-site_request_forgery#Coo... is flawed too because "Access-Control-Allow-Origin: *" doesn't let browsers send cookies with the request, so any of the CSRF prevention methods shouldn't be broken by it. I was just using "Access-Control-Allow-Origin: malware.com" as an example of a worst case scenario where I still don't think the cookie-to-header method is exploitable, unless I'm missing something. The articles don't give examples or link to sources, so I'm guessing both are slightly wrong. I could try to edit them, but wanted to make sure I wasn't wrong first.

Yea, but doing it that way requires same origin policy not to be weakened like from CORS being misconfigured. http://blog.portswigger.net/2016/10/exploiting-cors-misconfi... talks about exploits from this.

But what I am wondering is if using "Access-Control-Allow-Origin: evil-site.example.com or *" can be used to exploit the cookie-to-header technique with a token for every request (GETS included), no form GETS (so token doesn't appear in url query), https, and no browser bugs or XSS vulnerabilities. The wiki articles suggest it could be exploited, but I'm thinking they're just worded conservatively.