What are CSRF attacks and how do we stop them?

Dreaded by companies and customers alike, Cross-Site Request Forgery (CSRF) attacks violate user privacy and generate distrust. Companies unaware of or unable to prevent CSRF attacks will not only fail to protect their clients but also receive damage to their reputations. A 2019 Pew Research survey found that about 3 in every 10 Americans have suffered some form of identity theft, with the most popular including suffering financial losses and violations of their social media or email accounts. Coupled with data found by the SAS which showed that over 38% of respondents were likely to cut back on their use of websites and apps due to these concerns, it becomes clear that companies must prioritize user safety, proactively protecting clients from attacks like CSRF attacks.

What is a CSRF?

CSRF stands for Cross-Site Request Forgery and is also known as XSRF, “Sea Surf,” Session Riding, Hostile LInking, and One-Click Attack. Regardless of its name, a CSRF attack is an attack against web-hosted apps, tricking users into submitting a malicious request unknowingly. If successful, a CSRF attack exploits the trust a host has in a user’s browser, hijacking the identity and privileges of the user and preventing a site’s built-in security measures from distinguishing between a legitimate request sent by a client and the forged request. The attacker can then make the user’s system perform malicious functions such as allowing malware through its security measures without the user’s knowledge. Put into the simplest terms, CSRF attacks are the digital equivalent to forging someone’s signature. Unlike when forging a signature though, CSRF attackers leave virtually no trace behind them because the attacker’s forged request originates from and has all the information of the user’s IP address. Therefore, the most frightening aspect of these attacks is that any application (your local bank’s website, for example) allowing clients to update or submit data of any kind is at risk of CSRF attacks.

For a CSRF attack to be successful, users have to be fully logged into the target site. Users are especially vulnerable after selecting the “stay logged in” option many sites offer because this action gives attackers more time to make forged requests.

Why are they important?

Although there are varying motives behind CSRF attacks, the most common factor is theft. Most attackers are well versed in data theft, identity theft, or financial theft. For example, users with administrative privileges are particularly susceptible to such attacks. If the CSRF attack is successful, attackers could potentially gain access to critical components of the website, allowing them to delete or add information as they see fit. Additionally, attackers often lock users out of their accounts, producing fake password reset requests. On websites where users order products, attackers commonly add items to a user’s basket or alter delivery addresses. However, the most malicious of all these attacks are those targeted towards financial theft. A specific example of such an attack involves a user logging into their banking website. While actively logged in, the user will receive an email with a link. If the user clicks the link, the attacker’s script will execute, which transfers funds out of the user’s account. The worst aspect of all this? Users often struggle to report such attacks because of how difficult it is to trace them. Oftentimes, a long and detailed investigation is necessary before users are allowed a credit reversal. Clearly, from a customer’s point of view, such a situation is akin to a nightmare. Attackers not only steal clients’ personal information, but they also make it undoubtedly difficult for clients to report these attacks. Even if investigations are successful, companies also suffer as they need to deploy staff to track the attacks all while likely losing the trust of a former loyal customer. So how then can we stop CSRF attacks?

How do we stop CSRF attacks??

A few methods are available to stop CSRF attacks. First, developers should avoid setting up browsers that send third-party cookies to their web application. They can do so with the Same-Site Cookie attribute. The Same-Site Cookie attribute instructs the browser to disable specific cookies from being used by third parties, requesting that the browser only send cookies in a first-party context. Since browsers can only send cookies in the first-party context once enabling the attribute, this request must be set by the server and come from the same location. Ultimately, enabling the Same-Site Cookie attribute eliminates the risk of CSRF attacks since third-party sites by definition cannot include Same-Site Cookies. The only difficulty with this method is that the older browser may not support it.

Alternatively, anti-CSRF tokens or synchronizer tokens can be used. By themselves, synchronizer tokens are usually random numbers stored in cookies or on servers. Synchronizer tokens act as a layer of security to verify if requests sent by users are legitimate. When a client submits a request, the server then compares the token to that request to the value stored in that specific cookie, accepting the request if and only if the two values are identical. Most frameworks, such as .NET,  have built-in synchronizer token defenses. For instance, .NET has such built-in protection. Additionally, external components such as AngularS’s Cross-Site Request Forgery (XSRF) protection. can be added to specific applications and are also an excellent option for an extra layer of security. These components differ based on what language and frameworks are used. Finally, once synchronizer tokens are implemented, ensure that the library holding all known tokens is regularly updated. This is usually a relatively simple task because most of these libraries are open source and thus made widely accessible.

While implementing one of the two previous methods can help mitigate the risk of CSRF, a third technique can also be used for an additional layer of protection. Developers should require users to submit a challenge-response along with every form. Challenge responses may take the form of personal information or password re-authentication (security questions and such), CAPTCHA validation, and one-time tokens. The only downside of implementing challenge responses is that they will minimally impact user experience on a site. However, the benefit of additional security clearly outweighs this consequence.

Another simple solution that would take the place of challenge responses is to implement an SSO such as humanID. Our technology allows for maximum consumer security by only permitting each user to have a single, anonymous digital identity. What’s more, as a non-profit and open-source platform, all of our policies and code are made available for public use. Here at humanID, we aim to offer our clients the best and easiest way to protect users. Given the dangers of CSRF attacks, how will you protect your clients?