What Is CSRF ? How To Perform CSRF Attack, Real Life Example OWASP Top 10
In this blog we will explain what cross-site request forgery is, describe some examples of common CSRF vulnerabilities, explain how to prevent CSRF attacks and Real world example of CSRF.
What is Request Forgery ?
This category of attack is also known as session riding is closely related to session hijacking, in which an attacker captures a user’s session token and therefore can use the application “as” that user. With the request forgery however, the attacker need never actually know the victim’s session token. Rather, the attacker exploits the normal behavior of web browsers to hijack a user’s token, causing it to be used to make requests that the user does not intent to make.
Request Forgery vulnerability comes in two flavors On-site Request Forgery and Cross Site Request Forgery
What is CSRF?
Cross-site request forgery (also known as CSRF or XSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
How CSRF occurs ?
Consider the Web-application in which admin can create new user accounts using requests like the following:
POST/auth/390/NewUserStep2.ashx HTTP/1.1
Host:scriptkiddie.com
Cookie: SessionId=8299BE6B260193DA07683A2385B07B98
Content-Type: application/x-www-form-urlencoded
Content-Length: 83realname=daf&username=daf&userrole=admin&password=letmein&confirmpassword=letmein
The above request has three features that make this Web-application vulnerable to CSRF:
- The request performs a privileged action. As the request creates the new user with “Admin” privileges’.
- The application relies solely on HTTP cookies for tracking sessions. No session-related tokens are transmitted elsewhere within the request.
- The attacker can determine all the parameters required to perform the action. Aside from session token the cookie, no predictable values needs to be included.
As the application is not checking the Origin of the request whether it is from the same site or its originating with different site, with this attacker can create a simple html consisting above required field and submit the request to Web-Application.
Real World Example of CSRF
A real -world example of a CSRF flaw was found in the eBay application by Dave Armstrong in 2004. It was possible to craft a URL that caused the requesting user to make an arbitrary bid on an auction item. A third- party website could cause visitors to request this URL, so that any eBay user who visited the website would place a bid. Furthermore, with a little work, it was possible to exploit the vulnerability in a stored OSRF attack within the eBay application itself. The application allowed users to place <img> tags within auction descriptions. To defend against attacks, the application validated that the tag’s target returned an actual image file. However, it was possible to place a link to an off-site server that returned a legitimate image when the auction item was created and subsequently replace this image with an HTTP redirect to the crafted CSRF URL, Thus, anyone who viewed the auction item would unwittingly place a bid on it.
How to Prevent CSRF
Methods of CSRF mitigation
A number of effective methods exist for both prevention and mitigation of CSRF attacks. From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized actors access to applications.
Best practices include:
- Logging off web applications when not in use
- Securing usernames and passwords
- Not allowing browsers to remember passwords
- Avoiding simultaneously browsing while logged into an application
For web applications, multiple solutions exist to block malicious traffic and prevent attacks. Among the most common mitigation methods is to generate unique random tokens for every session request or ID. These are subsequently checked and verified by the server. Session requests having either duplicate tokens or missing values are blocked. Alternatively, a request that doesn’t match its session ID token is prevented from reaching an application.
Double submission of cookies is another well-known method to block CSRF. Similar to using unique tokens, random tokens are assigned to both a cookie and a request parameter. The server then verifies that the tokens match before granting access to the application.
While effective, tokens can be exposed at a number of points, including in browser history, HTTP log files, network appliances logging the first line of an HTTP request and referrer headers, if the protected site links to an external URL. These potential weak spots make tokens a less than full-proof solution.
See how Imperva Web Application Firewall can help you with CSRF attacks.
Using custom rules to prevent CSRF attacks
The highly individual nature of CSRF attacks hinders the development of a one-size-fits-all solution. However, custom security policies can be employed to secure against possible CSRF scenarios.
IncapRules, the Imperva cloud proprietary custom rules engine, lets customers create their own security policies. The policies are generated using an intuitive syntax and can be modified on the fly, augmenting our default web application firewall configuration.
Using IncapRules, you can create a policy that filters requests to sensitive pages and functions based on your HTTP referrer header content. Doing so allows requests to be executed from a short list of secure domains.
This method completely counters the social engineering aspect of CSRF attacks. It prevents execution of malicious requests outside of a security perimeter, regardless of content.
Keep Coming for more.
Happy Hacking!!!