Most people who have heard about security measures on the web will have heard about CSRF. Cross-Site Request Forgery, or CSRF for short, is a security loophole found within web applications that aims to perform actions on behalf of the user without his or her knowledge or consent. In other words, CSRF is used to perform malicious actions without the consent of a user – clicking a link is usually sufficient to change his or her password or even transfer money to the bank account of a nefarious party.
Cross-Site Request Forgery: A Wild, But Silent Beast
If you’re a reader of most news sources centered about threats in the cyberspace or information security, you would quickly notice that the vulnerability that’s the granted the most “fame” is SQL injection, and that’s not without a good reason – SQL injection, or SQLi, is the vulnerability that’s used to own databases left, right, and center. SQL injection also has a “brother in arms” if you will – Cross-Site Scripting, or XSS for short, is used to exploit the ability to inject code into a website. There are, of course, multiple other vulnerabilities that are worth protecting against (simply glancing into the recent top 10 edition of OWASP will provide us with a broader list), but some vulnerabilities are still roaming undercover. One of those vulnerabilities is Cross-Site Request Forgery – it doesn’t make headlines, but it certainly makes life more difficult for its victims – at least in the cyberspace.
A couple of steps are all it takes for an attacker to employ all of the possibilities that CSRF brings to the table:
- An attacker finds a vulnerable website (such websites can be easily identified with enough practice.)
- An attacker makes a copy of a page that requires user interaction and usually grabs a domain similar to that of the target website.
- A page is made live on the clone of the website, then a link to the clone is usually forwarded to an unsuspecting victim.
- The victim clicks on the link – and – depending on what the functionality of the page is – his money is gone or his password is changed to that of the attacker’s desire.
Sounds pretty dangerous, huh?
There’s a catch, though – in order for CSRF attacks to be as effective as possible, a user usually needs to be logged in to the website that is a target. That’s the case because CSRF attacks usually only target small parts of the website instead of targeting or taking it down as a whole. Think of a website as a piece of cake – a part of the cake is identified as vulnerable, then targeted.
As such, CSRF attacks, as you might’ve guessed, can be pretty dangerous – it’s just that they’re not usually reported because they’re not the primary cause of a data breach. A Cross-Site Request Forgery attack is always sad news for a victim – someone might get their password changed, money transferred, an inappropriate message sent to a specific user, etc. (CSRF attacks target anything that requires user interaction), however, they can easily be protected against.
Protecting Against CSRF
In order to effectively protect against CSRF, we must understand a couple of things:
- CSRF attacks, as previously noted, target the parts of the website that require user interaction (think login forms, password change prompts, message-sending boxes on a community forum, etc.)
- A CSRF attack is only effective if an attacker can figure out the parameters that will be used to conduct the attack (they need to be forged to that of an attacker’s desire.)
- A CSRF attack must be “executed” – that is, it needs input from the victim. The word “input”, in this case, isn’t as powerful – it might be as simple as clicking on a link.
Understanding these steps is absolutely crucial in order to defend ourselves and our web applications against the harm of CSRF – limiting access to forms that require user interaction (logging users out after a specified period of time) or educating people not to click on links sent by people they don’t absolutely know will help. However, what helps the most is the practice of generating random tokens that can’t be guessed – any parameter that’s not predictable will help our form not to become a victim of CSRF.
“Generating random tokens” might sound like a very complex phrase, however, it’s really not – all we have to do to build a proper token that wouldn’t be guessed by an attacker is to generate random bytes and hash those bytes with MD5 or any other hashing mechanism. Bear in mind that hashing random bytes isn’t a necessity – it’s usually done for aesthetics.
Once we have built a function that generates random tokens, we must store them in a session, then store them in a form we’re protecting (think hidden fields, a GET parameter dedicated to the token, etc.) and make sure the token stored in a session and in the form is an exact match, otherwise, we must block the request. That’s it – we have successfully protected against CSRF – our job is complete!
Once your web applications are safe from CSRF, pat yourself on the back, but don’t get overly excited yet – protecting yourself and your team is a long way to go. Thankfully, employing the API built by BreachDirectory will solve all of your issues in the identity theft space as well – familiarize yourself with the API, make sure your team runs a search through the list of known data breaches that have occurred in the past, and finally, implement the API into your infrastructure to secure your team, customers, or both at the same time.
We hope that you’ve enjoyed reading this article and that you’re eager to protect your web applications against CSRF. Once you do that, make sure to familiarize yourself with the capabilities provided by the API, and until next time!