What Is a CSRF Attack and How to Prevent It? – Devstringx
What Is CSRF Attack?
Cross-site Request Forgery (CSRF/XSRF), also known as sea surf or session riding, refers to an attack against authenticated web applications using cookies. The hacker is able to trick the victim into making a request that the victim did not intend to make. Therefore, the hacker abuses the trust that a web application has in the victim’s browser. While Cross-site Request Forgery (CSRF) attacks do not provide anything to an attacker with the response returned from the server, a clever attacker could cause a fair amount of damage, especially when paired with well-crafted social engineering attacks on administrative users.
XSRF is a type of unwanted confused attack, which validates the authentication and authorization of the victim when a fake request is being sent to the web server. Therefore, a Cross-Site Request Forgery vulnerability that affects highly privileged users, such as administrators, could result in a full application compromise. During a successful XSRF (Cross-site Request Forgery attack) the victim’s web browser tricks a malicious website into unwanted action – it sends HTTP requests to the web application as intended by the attacker. Generally, such a request would involve submitting forms present on the web application to alter some data.
Upon sending an HTTP request the victim’s web browser will include the cookie header. Cookies typically use to store a user’s session identifier so that the user does not have to enter their login credentials for each request. Which would obviously be impractical. If the users authenticated session stores in a browser session cookie that is still valid (a browser window/tab does not necessarily need to be open), and if the application is vulnerable to Cross-site Request Forgery (CSRF), then the attacker can validate CSRF to launch any desired malicious requests against the website and the server-side code is unable to distinguish whether these are legitimate requests.
CSRF attacks may, for example, use to compromise online banking by forcing the victim to make an operation involving their bank account. CSRF can also evaluate as Cross-site Scripting (XSS). Therefore, CSRF should treat as a serious web application security issue, even if it is not currently included in the OWASP Top 10.
Cross-site Request Forgery in GET Requests
Below simple example of how Cross-site Request Forgery (CSRF) can abuse in GET requests through the use of the <img>tag.
<img src="http://example.com/changePassword.php/?newPassword=attackerPassword">
The above URL is a CSRF attack using an HTTP GET request. If the attacker visits a web page controlled by the hacker with the following payload. The browser will send a request containing the web cookie to the attacker-crafted URL.
Cross-site Request Forgery in POST Requests
GET requests, however, it is not the only HTTP method an attacker can abuse.POST requests are generally equally susceptible to Cross-site Request Forgery (CSRF), however, an attacker will need to make use of a small bit of JavaScript to submit the POST request.
The following is a simple example of how CSRF can abuse using POST requests through the use of a <iframe>tag. This code would load in an iframe which is made not visible to the victim.
Iframe Definition
<iframe src="http://attacker.com/csrfAttack" style="width:0;height:0;border:0;border:none;"></iframe>
iframe HTML contents
<body onload="document.getElementById('csrf').submit()">
<form id="csrf" action="http://example.com/changePassword.php" method="POST">
<input name="newPassword" value="attackerPassword" />
</form>
</body>
CSRF Protection
Generally, there are two primary approaches to protect Cross-site Request Forgery (CSRF) –
- Synchronize the cookie with an anti-CSRF token that has already been provided to the browser.
- Preventing the browser from sending cookies to the web application in the first place.
Good to Read- Clickjacking Attack & Mitigation
Anti-CSRF Tokens
The recommended and the most used prevention technique for Cross-site Request Forgery (CSRF) attacks is known as an anti-CSRF token, sometimes referred to as a synchronizer token or just simply a CSRF token. When any type of user submits a form or makes some other authenticated request that requires a cookie, then any random token should include in the request. The web application will then validate the existence and correctness of this token before processing the request. If the token is missing or invalid the request can reject.
It is highly recommended that you are using an existing, well-tested, and reliable anti-CSRF library. Depending on your own language and framework of choice, there are several high-quality open-source libraries that are ready to use. The characteristics of a well-developed anti-CSRF system involve the following attributes:
- The anti-CSRF token should be always unique for each user session
- The session should automatically expire after a fixed amount of time
- The anti-CSRF token should be a cryptographically random value of sufficient length.
- The anti-CSRF token should be cryptographically secure, that is, generated by a strong pseudo-random number generator algorithm
- The anti-CSRF token can add as a hidden field for forms or within request URLs.
- The server should reject the request action if the anti-CSRF token fails validation.
SameSite Cookies
The SameSite cookie attribute is a new attribute that can be set on browser cookies. To instruct the browser to disable third-party usage for unique cookies. It is set by the web server when setting the cookie and requests the browser to only send the cookie in a first-party context. Therefore, the request has to initiate from the same origin – requests made by third-party sites will not include the SameSite cookie. This effectively deletes Cross-site Request Forgery attacks without the use of synchronizer tokens. Unfortunately, this method of CSRF protection is not yet more effective in all web browsers but many more browsers start to use it.
How to Protect Cross-site Request Forgery (CSRF)? – Generic Tips
Cross-site Request Forgery (CSRF) vulnerabilities are very harmful partly because preventing them is not that easy. There are different methods that you can use to avoid them but not all are effective in all scenarios. In addition to two different methods that consider the most effective. There fix general strategic principles that you should follow to keep your web application safe.
If you are interested in even more software testing-related articles and information from us here at Devstringx, then we have a lot to choose from for you.
