If we found that the application we are testing uses an anti-CSRF protection and is well-implemented, it is not the end. Maybe it is possible to defeat the anti-CSRF protection if we can use an XSS technique.

Let's do a little research about XSS attacks. The XSS attack sends a URL or POST request with the malicious payload to the user. So, if an application is vulnerable to CSRF but it has an anti-CSRF protection, when the application receives the XSS attacks, it will have the token or hash included as protection. So, the purpose is not injecting the code, but getting the token to use it in other requests.

This is the basic idea, but XSS could be exploited to bypass other types of protections. Here's a summary of how you can do it:

• A stored XSS could read all the tokens in an application. Why? Because a stored XSS is launched by the application, and any response launched by it will have the token – even an XSS launched.
• In applications that have more than one step to perform an action, it is possible that the anti-CSRF protection had been just included in the critical step. If you can perform an XSS attack in one of the unprotected sections, it is possible that you will get the token or hash used for the critical step. It is the first step, by logic, and is used to transfer the user to the second step, so the XSS attack is just following the application's natural flow.
• When the anti-CSRF protection is related with a username not in their session, the only way is to get the credentials in order to exploit the CSRF, not just the token is needed. To do that, one of the last opportunities is an XSS attack to steal the login information, and at the same time retrieve the token by the logic application itself.