An Introduction of Cross Site Request Forgery (CSRF/XSRF)

January 10, 2018 Author: rajesh
Print Friendly, PDF & Email

Now-a-days, Internet plays an important role for the business people and for the commercial use. Everyday life becomes easier for the internet users because of the progression in the technologies, but some vulnerability moves the web application to a risky environment. Even though many internet users get increased, the attackers too get increased in balance. So the security providence becomes must in the case of secure organization, defense personals and financial bank those interact with public. The web has become an indispensable part of our lives. Unfortunately, as our dependency on the web increases, so does the interest of attackers in exploiting web applications and web-based information systems.

Definition of Cross Site Request Forgery




Cross Site Request Forgery is considered as one of top vulnerability in today’s web, where an untrusted website can force the user browser to send the unauthorized valid request to the trusted site. Cross Site Request Forgery will let the integrity of the legitimate user.

Cross‐site request forgery (CSRF; also known as XSRF or hostile linking) is a class of attack that affects web based applications with a predictable structure for invocation. This class of attack has in some form been known about and exploited since before the turn of the millennium. Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in. A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft—including stolen session cookies.

A Cross-site Request Forgery, aka CSRF or one-click attack, is a diffused security issue where unauthorized commands are sent from the user’s browser to a web site or a web application. CSRF is different from Cross-Site Scripting in the sense that it does not need to inject code into trusted pages, but can work from untrusted ones thanks to the open architecture of the web. A CSRF or XSRF attack can be executed by stealing the identity of an existing user and then hacking into a Web server using that identity. An attacker may also trick a legitimate user into unknowingly sending Hypertext Transfer Protocol (HTTP) requests that return sensitive user data to the intruder.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one. Following are the figure depict scenario of CSRF attack.

CSRF Scenario

Figure 1: CSRF Scenario

Cross Site Request Forgery Significance




CSRF attacks do not appear in the Web Security Threat Classification and are rarely discussed in academic or technical literature.2 CSRF attacks are simple to diagnose, simple to exploit and simple to fix. They exist because web developers are uneducated about the cause and seriousness of CSRF attacks. Web developers also may be under the mistaken impression that defenses against the better known Cross-Site Scripting (XSS) problem also protect against CSRF attacks.  For a request to be vulnerable to CSRF, the following conditions must hold:

  • The request can be issued cross-domain, for example using an HTML form. If the request contains non-standard headers or body content, then it may only be issuable from a page that originated on the same domain.
  • The application relies solely on HTTP cookies or Basic Authentication to identify the user that issued the request. If the application places session-related tokens elsewhere within the request, then it may not be vulnerable.
  • The request performs some privileged action within the application, which modifies the application’s state based on the identity of the issuing user.
  • The attacker can determine all the parameters required to construct a request that performs the action. If the request contains any values that the attacker cannot determine or predict, then it is not vulnerable.

Cross Site Request Forgery Example




In the CSRF attack example below, the data to be changed is contained in a parameter called “EmailAddress”. If the user can be tricked into visiting a website under the attacker’s control, the following code can be used to change the email address stored as a login credential on that site.

<html><body>
<H1>Hello</H1>
<img src=”http://vulerablesite.com/MyAccount?EmailAddress=anaddress@asite.com” width=””1\”” height=”1″/>
</body></html>

The page can be presented as anything: it could be blank, or it could be a replica of the website that’s under attack. All it needs is the code above, which displays an image; this image does not need to exist, and it only covers a 1×1 pixel area, so it does not arouse suspicion. As soon as the user’s browser loads the page, the code will automatically submit the request to change the user’s email address. As long as the victim is logged into the website at the time, it will be processed exactly as if the victim had clicked the link.

Even if the website only allows updates via POST, it’s possible to change the email address in the same manner; it just requires some different code:

<html><body>
<H1>Hello</H1>
<form name=”CSRF” method=”post”action=””http://vulerablesite.com/MyAccount\”><inputtype= ‘hidden’ name = ‘EmailAddress’ ”
“value=\”anaddress@asite.com\”></form>”
<script>documents.CSRF.submit()</script>
</body></html>

In both cases, once this is submitted, the email address is automatically changed. Then it’s as simple as using the built-in password-reset facility that most websites have: If this sends the password directly to the registered email address, the password will then be mailed to the attacker and the user account is compromised.

The caveat to mention here is that the user must be logged in to the legitimate website at the time he or she is tricked into visiting the malicious website. However, many sites have a “keep me logged in” facility, which provides a much larger timeframe for the attack.

References

[1] Zeller, William, and Edward W. Felten. “Cross-site request forgeries: Exploitation and prevention.” Bericht, Princeton University (2008).

[2] Sentamilselvan K and Lakshmana Pandian S, “Cross Site Request Forgery: Preventive Measures”, International Journal of Computer Applications (IJCA), Volume 106 – No.11, November 2014.

[3] “Cross-site request forgery: Lessons from a CSRF attack example”, available online at: http://www.computerweekly.com/tip/Cross-site-request-forgery-Lessons-from-a-CSRF-attack-example

[4] “Cross Site Request Forgery (CSRF) Attack”, available online at: https://www.incapsula.com/web-application-security/csrf-cross-site-request-forgery.html

 

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Insert math as
Block
Inline
Additional settings
Formula color
Text color
#333333
Type math using LaTeX
Preview
\({}\)
Nothing to preview
Insert