Subscribe
Since I found Angel’s “Plain English” series of blog posts so helpful when I was first learning about different kinds of vulnerabilities on the web, I wanted to continue that series. I hope to expand into some of the nuances of more commonly known vulnerabilities, and touch on some of the less well known ones. Let’s get started with one special case that I often find questions about: CSRF on a login form.
To start, if you’re not familiar with the Cross Site Request Forgery (CSRF) attack, you should definitely give Angel’s blog post from a few years ago a read. In the typical way of thinking about a CSRF, an attacker is able to submit a form on behalf of a victim with data the attacker controls. In the classic example, you can imagine an online service that allows users to transfer money between each other, perhaps by first adding their credit card. In the absence of any protective measures against CSRF, the attacker can trick their victim into clicking a link that submits a form on their account, and transfers money into the attacker’s account. However, what if our humble service is aware of this risk, and includes some form of CSRF protection on all of their authenticated forms? Our attacker will have to get a bit more clever, and though the aforementioned example might often be the most dangerous case, it is not necessarily the only one.
Strictly speaking, a CSRF attack is one where an attacker is able to submit any request on behalf of the victim. So, the attacker begins looking for other ways to trick our poor victim, and finds that the login form is totally unprotected. Hatching a devious plan, our attacker crafts an attack that would submit the login form in the victim’s own browser, thus logging them into the attacker’s account. So our victim — now perhaps only slightly confused as to why their credit card info is missing — adds all of their personal information necessary to send money to their friend, and logs out, thinking nothing more of it. Now our attacker, having full control over their own account, logs back in to find that they have everything they need to siphon funds from our poor victim.
As you may have noticed, the impact of an exploit like this varies from site to site, depending a lot on how likely or possible it is for a victim to leave behind personal information. It also relies on tricking the users into completing at least one extra step, instead of just clicking a dubious link. However, the world of security frequently involves accounting for even very unlikely cases, because an attacker will often have hundreds or sometimes thousands of opportunities, and doesn’t need to succeed every time. It’s also worth mentioning that even seemingly harmless vulnerabilities can be leveraged to enable more potent attacks. You might already be able to imagine how one could use an attack like this to direct a user to a page with an injected XSS, but perhaps I’ll save that concept for a later blog post.
For these reasons, I like to err on the side of caution, and avoid giving an attacker the opportunity to exercise any functionality on another user’s behalf. For more information on how we suggest you implement your CSRF protection, you can refer to the article linked above.
I hope you found this short post helpful in understanding some of the nuance of one of the most threatening types of vulnerabilities on the web. If you have any thoughts, feel free to contact us.
Continue Reading
Accelerate application code fixes with AI-powered Polaris Assist
