Cross-Site Request Forgery (CSRF/XSRF), also known as Sea Surfing or Session Riding, is a web security vulnerability that tricks a browser into performing an unwanted action. Consequently, the attacker abuses the trust a web application has by partially circumventing the same-source policy that prevents different websites from interfering with each other.
What is the impact of CSRF attacks?
When a website sends a data request to another website on behalf of a user along with the user's session cookies, an attacker can launch a cross-request forgery attack.
In some cases, depending on the type of action, the attacker can gain full control over the user's account. If the compromised user has a privileged role within the application, the attacker may be able to take full control of all application functionality and data, which is devastating for both the company and the user. From data theft to unauthorized fund transfers, negatively impacting customer relationships changed passwords and more.
How does a CSRF attack work?
When a user tries to access a site, the browser often automatically includes the credentials in the request to make the login process faster. These credentials may include session cookies, authentication credentials, IP addresses, and Windows domain credentials.
The risk of this mechanism is that attackers can use the user's identity. Once a user passes the identity verification, the site cannot tell the difference between a fake request and a legitimate user request.
In a CSRF attack, an attacker assumes the victim's identity and uses it to perform actions on behalf of the user without the user's consent. The methods used can be:
- through social engineering techniques to convince the victim to click on a link via email, chat message or similar form of communication
- via attacking links, or a web page that the user visits and triggers a request to the targeted site
CSRF attacks typically attempt to change status on the server, but can also be used to gain access to sensitive data. If an attacker successfully conducts a CSRF attack against the victim's account, the attacker can transfer funds, purchase a product, change account information such as the shipping address, change the password, or any other action available when the user is logged in.
What is a CSRF token
A CSRF token is a unique, unpredictable secret value generated by an application on the server and sent to the client for inclusion in subsequent HTTP requests issued by the client. After issuing the token, when the client makes a request, the server checks whether the request contains the expected token and executes the commands only if it is validated.
CSRF tokens can prevent CSRF attacks because they prevent attackers from forming fully valid HTTP requests that they can pass to a victim. The attacker cannot determine or predict the value of the user's CSRF token, so any request they generate should not be accepted by the application.
Common CSRF Vulnerabilities
Some of the most common CSRF vulnerabilities are caused by errors in the CSRF token verification process. Ensure that your CSRF process does not have any of the following points:
Validation depends on the presence of the token
In some applications, the verification process is skipped if the token does not exist. This means that the attacker only needs to find the code containing the token information and remove it, and its validation is not performed by the application.
CSRF token not associated with user session
Some applications maintain a pool of tokens, and as long as a token from the pool is used, it is accepted. However, the app does not link specific tokens to specific users. An attacker only needs to obtain at least one token from the pool and can use it to impersonate any user.
Change token with HTTP method
In some applications, using the GET method instead of the POST method will cause CSRF validation to not work correctly. The attacker simply needs to switch from POST to GET and easily bypass the verification process.
The CSRF token is copied into the cookie
Some applications do not keep a record of already used tokens. Instead, they copy the request parameters associated with each token into the user's cookie. In this setup, the attacker can create a cookie containing a token using the application's expected format, place it in the user's browser, and then execute a CSRF attack. The request sent by the user's browser will be validated because it will match the malicious cookie provided by the attacker.
CSRF Prevention: Beyond CSRF Tokens
The basic way to prevent CSRF is to implement CSRF tokens while avoiding the weaknesses described in the previous section. Here are additional ways you can prevent CSRF attacks.
Use advanced CSRF validation techniques
An attacker can initiate a CSRF attack when all parameters used in the form are identified. Therefore, to prevent a CSRF attack, you can add an additional parameter with an additional value that the attacker is not aware of, but the server requires validation. For example, an encrypted article id can be entered, which can be validated on the server by decryption using the set key.
When a user makes an authenticated request by submitting a form, a random token should be included in that request. Then the website will check for the occurrence of this token before processing the sent request and if the token is missing or the value is incorrect, the request will be rejected and the attacker will not be able to launch a CSRF attack.
SameSite Attribute
The SameSite cookie attribute, defined in RFC 6265 bis , attempts to prevent CSRF attacks. The attribute tells the browser when it is okay to send cookies with requests between sites. The SameSite attribute comes with three possible values – Strict, Lax, or None. Most mobile browsers and all desktop browsers support this attribute.
The Strict value tells the browser not to send a cookie to the site during a cross-site browsing session. This includes a session that follows a regular link. For example, when a user logs in to GitHub and navigates to a private GitHub project hosted by a corporation, the browser does not send a session cookie to GitHub, limiting access to the project.
If you don't need to allow external sites to link to transactional pages, you can use the Strict value. However, if you need to strike a balance between usability and security, allowing users directed by external links to keep sessions connected - you should use the Lax default. In general, cross-site requests granted during Lax mode are considered secure HTTP methods.
CSRF defense based on user interaction
Often, defense mechanisms that require user intervention can have a negative impact on the user experience. However, in some cases, such as financial transactions, it is appropriate and necessary to implement this type of technique. For example, you can add a CAPTCHA, which helps validate that it's really a human user rather than a robot.
Maybe even two- or more-step security. A unique token/request can assure us that it is the user and not an attacker using a connected session. The token is usually sent to the user's email address or phone number, validating against the information previously provided by the user. Additionally, you can introduce re-authentication, which can help differentiate between a CSRF session and a real user.
Secure Authentication with CSRF
Many developers ignore CSRF vulnerabilities in an application's login form. This is because the user is not yet authenticated at this stage, so developers assume there is no CSRF risk. But attackers can perform login CSRF attacks, which can have different impacts depending on the application.
Login CSRF attacks can be mitigated by creating a pre-session (starting a session before the user authenticates) and requiring the token in the login form.
It is difficult to prevent login CSRF attacks if you do not trust subdomains (for example, if you allow users to define their own subdomains). In these cases, you can use a strict subdomain and path-level reference header checking to reduce CSRF risk on login forms.
Perform regular web application security testing
Even if web application vulnerabilities with CSRF attacks are successfully addressed, application updates and code changes may expose your application to CSRF in the future. Web application security testing helps you continuously scan and test for potential security weaknesses in your web applications, including CSRF vulnerabilities.
You can purchase your favorite domains at the most convenient prices using the quick domain registration solution and invest in a secure and optimal hosting plan - choosing any of the NSHOST web shared, VPS or Cloud and allocate the necessary time to a caching policy suitable for your business to ensure optimal load times for each web page.