The “Login/logout CSRF: Time to reconsider?” blog post by Mathias Karlsson (@avlidienbrunn) is a great resource that shows why sometimes CSRF in logout/login can be considered as an impactful security issue and how it can be abused.

In Mathias’ blog post, unauthenticated XSS can also be exploited similar to the self-XSS issue but it is less complicated. This is when a  XSS is not accessible to authenticated users. In that case, the attacker logs the user out to deliver the XSS payload which waits for the user to authenticate in another tab in order to perform the ultimate attack.

Recently, I found another similar but rare example to perform CSRF attacks in a “secure” website that required logging victims out and waiting for them to log back in later. Although this case is not as common as the examples described by Matthias, it is still a valid case to consider during an assessment.

The websites I was testing had an anti-CSRF token in every POST requests that changed per-session, per-request, and per-page. However, as the logout page used a GET request it was vulnerable to CSRF attacks. The web application kept the anti-CSRF token value in the user’s session on the server-side, and GET and POST requests were not interchangeable.

All was good until I realised that some of the previously captured POST requests can be replayed with a new authenticated session cookie if I remove the anti-CSRF token’s parameter from the body of the POST request. I could however only send one token-less POST request to each page as I received a security error afterwards. This showed that the website was creating an anti-CSRF token for a page upon accessing the page for the first time (there was also a page that could generate an anti-CSRF token for a given page using AJAX but that is not important here).

As a result, I could not exploit this issue if the victim had already browsed a page that I wanted to target. However, as the logout page was vulnerable to CSRF attacks, I could exploit this issue by tricking the victim to visit a malicious website that would:

• Send a malicious POST request to the website without an anti-CSRF token’s parameter just in case I was very lucky and the victim had not browsed that particular page (very unlikely as it had a few pages)
• Log the victim out of the target website
• Keep sending the malicious POST request without the anti-CSRF token’s parameter to perform an action in the background until the user logs back in the target website in another browser tab