If your company has a website, then you have an obligation to protect all of your visitors from becoming victims of cybercrime. Although many IT managed service providers specializing in Cybersecurity are aware of and take precautions to prevent the most widely talked about methods cybercriminals employ to hijack website including Denial-of-Service (DoS), Distributed Denial-of-Service (DDoS), and even Man-in-the-Middle (MitM); approaches which are rarely mentioned in the news may fall below your team’s radar. A Cross-Site Request Forgery (CSRF) is one of these types of attacks which are more likely to be ignored or not adequately addressed.
What is Cross-Site Request Forgery?
Cross-Site Request Forgery (CSRF which is pronounced as ‘sea-surf’) is also known as XSRF, one-click attacks, or session riding. CSRF attacks occur when a hacker is able to modify the code of a web application. When a website visitor uses this corrupted web application, the cybercriminals gain access to the users’ browser and is able to carry out various nefarious actions by fooling the application that the legitimate user made a request which he didn’t.
How Does Cross-Site Request Forgery Work?
Now, in order to understand how a CSRF attack works, you need to know about two ways programmers use to transfer information: POST and GET. POST requests are used to send data to a server to create or update data, while a GET request is used to request data from a remote source. However, since hackers can easily encode the information as part of the URL, it leaves clickable images or links vulnerable to corruption.
Therefore, all a cybercriminal needs to do is to get a user to click on one of these corrupted links, and the hacker will be able to perform unwanted actions. The scary part is that these URLs can appear even offsite, such as a forum or forged email.
So, how can you help to protect your visitors from CSRF attacks?
Protecting Your Visitors From CSRF Attacks
Some techies believe that by limiting requests to the POST variety, they can stop CSRF attacks. This isn’t true, and talented hackers can create workarounds with just a few lines of code. However, there are things your IT department can do which can help to curtail Cross-Site Request Forgery from occurring on your websites:
- Include a synchronizer token in your code. A synchronizer token is often referred to as an anti-CSRF token, and it works by generating a random token or string of character with each request. The web application code can then verify that the request is coming from a real user by checking the synchronizer token. Requests which either do not contain any synchronizer token or the wrong one are automated rejected. IT departments which choose to use this sort of defense against CSRF attacks should be diligent with selecting a quality anti-CSRF library, and ensure the library is maintained and updated as needed.
- Use code to check the origin of a request. There are two bits of information available with requests. These are the origin header and the referer header. Have your IT department implement automated checks each time your application receives a GET or POST request to guarantee that the request is coming from you, and not a third-party.
- Make use of the SameSite cookie attribute in your code. SameSite cookie attributes enforce first-party-only requests by limiting the requests to your server when the cookie is initialized. This basically kills any attempts to use CSRF attacks on your site. The only drawback is that not all browsers recognize SameSite cookie attributes yet. A simple workaround is checking which browser your visitor is using, and then suggesting that the person switches to a different browser which does use the attributes.
Cross-Site Request Forgery attacks may not be as newsworthy as other cybercrimes, but they are dangerous. Make sure that you provide your site’s applications with the proper protection from this type of exploitation.
