Remaining committed to protecting the security and privacy of your visitors (and users) is as important as it always has been in our eyes.Â
Studies back in 2003 (yes, thatâs around 20 years ago) found that there was an attack every 39 seconds on average.
And some statistics now suggest up to 30,000 websites are victims of attacks every single day.Â
In other words: that would equate to ~ 30 sites since you began reading this article.
But some attack vectors are harder to battle and protect your sites from than others, including cross-site request forgery (CSRF) attacks and vulnerabilities.
So, in this article, weâll cover what cross-site requests are and how they can be used for either good or bad. Weâll answer the question, âwhat is a cross-site request forgery (CSRF) attack?â, and explain how they work. Weâll also take a look at some real-world examples of CSRF attacks.
Letâs get started!
What are Cross Site Requests?
Cross-site requests are HTTP requests sent from one website or domain to a different website or domain. They can be used for various purposes, such as accessing or sharing resources, triggering actions, or integrating features between different websites or services.
If you want to allow users to perform actions on your website from a different domain or website, then using cross-site requests is one way to do so. Letâs see a few examples where this can be used.
- Cross-domain authentication: You often encounter websites where you can log in to account using credentials from another website or service, such as Google, Facebook, or Twitter. This can make the login process easier and faster for users, as they donât need to create a separate account or password for each website.
- Social sharing: Many websites allow users to post content to a different platform or networks, such as Instagram, Pinterest, or LinkedIn. Having the sharing functionality can increase the visibility and reach of your content, as well as the engagement and feedback from users.
- Webhooks: These are mainly used for automated tasks that allow users to trigger actions on your website based on events that happen on another website or service, such as Stripe, Mailchimp, or Zapier. Having webhooks on your website can automate and streamline your workflows, as well as integrate your website with other tools and features.
It is clear that this is a useful feature for users who want to enhance their web experience and functionality by integrating it with different websites or services. However, cross-site requests can also pose some security risks, such as cross-site request forgery (CSRF) attacks. Letâs discuss why it is a security risk if implemented improperly.
What is a CSRF Attack?
CSRF stands for Cross-Site Request Forgery, which is a type of web attack that takes over an existing session running on a website by using the session cookies stored in your browser.
Letâs break down each word in the acronym:
- Cross-Site: This means that the attack requires two or more websites. Usually, attackers create a malicious website to send a request to a legitimate website on behalf of a user who is already logged in to the legitimate website.
- Request: When browsing a website, you need to make HTTP requests to view content. This happens automatically as it is handled by your browser in the background. For example, a HTTP request is created when you change your password, transfer money, or delete an account on a website.
- Forgery: The internet has no memory, when we visit a website, it stores information (cookies) in your browser to identify you. Attackers exploit this functionality by creating a HTTP request that uses this cookie without the userâs knowledge or consent. For example, an attacker can use a hidden form, an image, or a script to forge a request that looks as though it came from the user, but actually carries out the attackerâs malicious intention.
CSRF Attacks in the Real World
We now know that a CSRF attack can make a user perform unwanted actions on a website without their knowledge or consent by using another website or domain to send forged requests. But why should you be concerned?
Anyone who uses the web should be concerned about CSRF attacks, because:
- It affects a very significant number of websites and users across the web.
- They are hard to detect as they rely on the userâs browser and cookies to send forged requests.
- They are easy to execute and exploit, as they only require a user to visit a malicious website or click on a link, or on an image.
Here is an example of a CSRF attack that you might encounter in the real world.
Letâs assume you receive an email, a QR code, or an instant message from a friend that invites you to take a fun quiz on a website. The quiz claims to tell you what celebrity you look like the most based on your photo. You are curious and click on the link or scan the code, which takes you to a malicious website. You see a form that asks you to upload your photo and enter your name and email address. You fill out the form and submit it, hoping to see your celebrity match.
However, what you donât know is that the malicious website also sends another request to your social media account in the background, using your browserâs cookies or session data. If you are already logged into your account this request can perform various actions on your behalf, such as:
- Posting a message on your
- Sending a direct message to your friends that asks them to lend you some money urgently, pretending that you are in trouble.
- Changing your password, email, or security settings, locking you out of your account.
- Deleting your posts, photos, or friends, damaging your reputation or relationships.
- Vote on, comment on, or rate a website on your behalf, influencing the results or opinions of others.
These actions can have serious consequences for you and your friends, such as compromising your privacy, security, or finances. You may not even notice that these actions have taken place until it is too late.
We have written more about CSRF in the past â read our in-depth report on how hackers exploited the UpdraftPlus Plugin, or listen to our Patchstack Weekly security update that dives deep in CSRF vulnerabilities.
How to Prevent CSRF Attacks
CSRF prevention is based on the idea of verifying both the origin and the intention of a request before executing it. Letâs look at the various ways to achieve this.
Validating the Request Headers
The origin and the referer headers are parts of an HTTP request that tells a website where the request came from. A website can use these headers to check if the request was made either by the same website, or by a different website. If the request was made by a different website, it could be a CSRF attack and should therefore not be executed.
Your browser sends a referer header when initiating a request. You can check this easily by opening the network section of your browser devtools. In the above example, the value of the referrer header is https://patchstack.com/wordpress-security/.
Using Anti-CSRF Tokens (Nonce)
Nonce is short for n umbers used once , but they are not actually used once. These are random and unique values that are generated and attached to each request. Each token typically lasts for 12 to 24 hours.
By using anti-CSRF tokens, a website can ensure that a request was authorized by the user and not forged by another website. You can create and use nonces in WordPress using two functions:
- The wp_create_nonce() function creates a nonce value based on a string that you pass as an argument. This string is the name of the nonce, and it should be unique for each action or endpoint that you want to protect. It returns a string that is the value of the nonce.
- The wp_verify_nonce() function verifies a nonce value that you receive from the browser or another source. You need to pass two arguments to this function: the nonce value and the name of the nonce that you used to create it. It returns âtrueâ if the nonce is valid and âfalseâ if it is not.
You can use nonces to protect your site from CSRF attacks by adding them to any of your forms or requests that perform high-privileged actions. Then, you can check them in your endpoints or functions that process those actions. By doing this, you can ensure that only authorized and legitimate requests are executed.
How to Use a Nonce to Prevent CSRF
There are different methods to implement anti-CSRF tokens, such as:
- Hidden form fields: This method involves adding a hidden input element to each form that contains the anti-CSRF token value. The token value is generated on the server side, and then sent to the browser along with the form. When the user submits the form, the token value is sent back to the server, where it is verified before executing the request.
- Cookies: This method involves storing the anti-CSRF token value in a cookie on the browser. The cookie is set by the server when the user visits the website or logs in. When the user makes a request, the cookie is sent along with the request, where it is verified by the server before executing the request.
- HTTP Headers: This method involves sending the anti-CSRF token value in a custom HTTP header. The header is set by a script on the browser when the user makes a request. The script can get the token value from a hidden field, a cookie, or a meta tag. When the server receives the request, it checks the header for the token value and verifies it before executing the request.
These are some of the different techniques that can be used to implement anti-CSRF tokens. Many popular libraries and web frameworks have developed their own solutions to prevent CSRF. We recommend you read âHow to Use Djangoâs CSRF Protection Functionalityâ, and âHow the Laravel Framework Handles CSRF Protectionâ.
By Using SameSite Cookies
This is an attribute that you can add to your cookies to control how they are sent with cross-site requests. SameSite cookies can help prevent CSRF attacks by limiting the scenarios where cookies are sent with requests.
For example, you can use SameSite cookies to only send cookies with requests that originate from your own website or domain, and not send cookies with requests that originate from other websites or domains.
Using Third-Party Solutions
CSRF attacks should be protected at application level, and itâs difficult to do this from a coarse-grained solution such as an external WAF. But there are some rules, strategies and policies that can help to mitigate this kind of exploitation, reducing the list of attempts to be controlled in the application.
In addition to cross-site forgery, a WAF has the capability to protect your web application from many other common web attacks, such as cross-site-scripting, file inclusion, and SQL injection. If you wish to go down this route, you can use the WAF solution by Cloudflare or Sucuri to get started.
Final Thoughts
CybĐ”rsĐ”curity, Đ”spĐ”cially when dĐ”aling with CSRF attacks, isnât just a concĐ”rn â itâs a nĐ”cĐ”ssity. CSRF attacks, snĐ”akily making a usĐ”r pĐ”rform unwantĐ”d actions, arĐ” clĐ”vĐ”r, damaging, and surprisingly common.
The spotlight in this article has bДДn on their workings and potential prevention methods, such as using anti-CSRF tokens and validating request headers, which create a robust line of dДfДnsД for online entities.
But, letâs not stop our cybersecurity journey hĐ”rĐ”. Exploring furthĐ”r into othĐ”r cybĐ”r thrĐ”ats such as XSS and SQL InjĐ”ction is crucial in todayâs digital agĐ”. ThĐ” kĐ”y takeaway: staying Đ”ducatĐ”d and alĐ”rt is our bĐ”st bĐ”t in safĐ”guarding our digital rĐ”alms.
This is also why we built Patchstack.Â
Automated web application protection for site owners, developers and agencies.Â
Most people working with WordPress either:Â
- Passively worry about their site (and whether theyâre taking precautions)
- Donât worry and take little precautions (and are the most at risk)
- Spend more time than they should manually securing their sites (often enterprise companies that do code reviews all manually)
Fortunately â thanks to Patchstack, you donât have to be with:Â
- Notifications for new security vulnerabilitiesÂ
- Automated protection with virtual patches and security hardening
- Remotely managed software and updates with automations
And much, much more.Â
For more on WordPress security, read our complete guide to WordPress security here.
We hope youâve found this tutorial helpful â if you have absolutely any questions for us, feel free to reach out to us on our social media platforms. Weâre here to help. đ€
Source: patchstack.com