What is CSRF and how to prevent it?
Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious actor tricks the victims into unknowingly executing malicious requests. In most cases, these malicious requests come from the attacker’s web server. CSRF attacks aim to exploit the trust between the victim and their web-services and can cause harm by stealing information, manipulating account data, or modifying existing information.
To understand how CSRF attacks work, we must first look at how data is sent from the client to the server. When a user emits a request to a server, the client browser (like Chrome, Firefox, or Safari) sends the request with information about the user, such as their browser name, IP address, and session information. This combination of data provides a way for the server to identify the user, and this combination is typically referred to as a ‘session cookie’. The session cookie is used to authenticate the request and grant the user access to their data.
When an attacker sends a malicious request, they also send an accompanying session cookie that was obtained from the victims. If the server is not equipped to reject the illegitimate session cookie, it will be granted access to the victims data. To prevent CSRF attacks, web applications must include specific checks to verify the legitimacy of incoming requests.
Developers must understand the nuances of defending applications from CSRF attacks, and must take measures to ensure their applications are secure. To protect against CSRF attacks, it is imperative that web applications employ different methods of session protection.
Different Types of Session Protection
When it comes to session protection, there are three main techniques: synchronizer tokens, origin verification, and CAPTCHAs.
Synchronizer Tokens
A Synchronizer Tokens (also known as a CSRF token) is a unique, randomly-generated string that is sent along the request header. This random string serves as an additional layer of security that is evaluated by the server before executing the request. This token is checked against the one stored on the server. If the tokens match, then the request is sent to the application and processed, otherwise the request is rejected. The token is generated randomly every time a new request is sent from the client. This extra precaution helps prevent malicious requests from getting through.
Origin Verification
The Origin Verification approach requires that all requests from the client include the origin information that identifies the source of the request. The origin information is obtained from the request header and used to verify that the request is coming from an authenticated source. If the origin information does not match the expected origin, the request is then rejected by the server. Origin Verification is a great way to stop CSRF attacks, but it can also be used to prevent various types of data theft attacks as well.
CAPTCHAs
Captchas serve as a test to provide an additional layer of security that helps prevent automated malicious requests. This test is designed to be seen only by the computers and bots, and not by the person using the application. CAPTCHAs are usually displayed in the form of a challenge-response test, a Turing test, or image recognition test. These short tests help prevent malicious requests from getting through and help protect against CSRF attacks.
How to prevent CSRF Attacks?
When it comes to preventing CSRF attacks, developers should take the necessary precautions to ensure their applications are secure. Here are some steps that can help keep your application safe from CSRF:
-
Implement Synchronizer Token Pattern: This is one of the best defenses against CSRF attacks, and it is considered to be one of the best solutions for protecting existing applications. In this approach, the application uses a unique random string called a 'CSRF token' that is created every time a new request is sent from the user, and it is sent along with the request header. This token is then matched with the one saved on the server, and if the tokens do not match, then the request is blocked.
-
Use Double Submitting Cookies: When this approach is implemented, the application creates two identical cookies with the same name. One of the cookies is sent with the request body, while the other cookie is sent with the request header. The application then compares the values of these two cookies, and if the values are the same, then the request is granted access to the system. Otherwise, the request is blocked.
-
Enable HTTP-only Cookies: This feature is available in most modern web browsers and it allows the application to set a cookie as HTTP-only, which means that the cookie cannot be accessed via client-side scripts. This extra layer of security helps prevent malicious scripts from accessing the cookie and using it to send illegitimate requests.
-
HTTP Referrer Headers: With this approach, the server validates the HTTP referrer header that is sent along with the request. This header contains the URL of the page from which the request was sent. If the URL does not match the expected value, then the request is blocked.
-
Implement Logging and Monitoring: It is important to implement adequate logging and monitoring mechanisms to detect suspicious requests in real time and prevent CSRF attacks.
By following best practices and adopting the right measures, application developers can help prevent CSRF attacks and keep their applications secure and protected.
