In my last post, I mentioned that if a site hosts an insecure crossdomain.xml file, you can exploit that flaw to bypass same origin policy and among other things, you can read anti-CSRF tokens. Because your Flash object can read the anti-CSRF token, it can extract the token from the response and use it in future requests. In fact, this is almost identical to how you can bypass CSRF tokens with XSS.
I recently came across a popular website that met these criteria, and I created a POC to send to the security team. The site protected itself against CSRF using anti-CSRF tokens, but they had a wide open crossdomain.xml file. I'll post the details later, but I wanted to drop the template here, in the event anyone wants to give it a try:
When the victim loads the the compiled Flash object, Flash object does 3 things:
1) The SWF sends a request from the victim's browser to a page that returns the CSRF token
2) The SWF grabs the CSRF token from the returned page
3) The SWF sends a second request, using the stolen CSRF token, that changes the email address on the account to the attackers email address
At that point the attacker just needs to fill out the forget password feature using their own email address, and they will be able to hijack the account.