From CRLF to Account Takeover

Valeriy Shevchenko
7 min readJun 3, 2020

Many people don’t like client-side vulnerabilities. I’m not a fan of such vulnerabilities as well. And I try to spend less time searching for them. You can’t surprise anyone with endless alert-boxes on the pages. But sometimes these alerts boxes can be worth their weight in gold. Especially if the execution of javascript is necessary for the chain to exploit a serious problem. Under a serious problem today we are talking about stealing user account.

In a classic XSS attack scenario, there is always reading user data, getting a token from local storage or cookies, modifying user data, changing data to steal an account. Typically, the hijacking is carried out through a change of email or password. To protect against that classic attack scenario came CSRF tokens. But these methods of protection can sometimes be bypassed by passing an empty token value, or do not pass at all csrf token in the request, or pass token but from another user session. There is a lot of tricks to bypass that protection layer and perfectly explained from 0ang3el here and here. But the advent of a global browser policy is not far off and will kill classic XSS+CSRF attacks with SameSite by default. Now we still have time to use the CSRF features because the release of changes in browsers has been slightly shifted due to the situation in the world.

--

--

Valeriy Shevchenko

I am a guy passionate about testing and security researching 👨‍💻 → t.me/valyaroller