CSRF (O.W.A.S.P)

9 min readNov 7, 2019

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request

CSRF attacks work by sending a rogue HTTP request from an authenticated user’s browser to the application, which then commits a transaction without authorization given by the target user. As long as the user is authenticated and a meaningful HTTP request is sent by the user’s browser to a target application, the application does not know if the origin of the request is a valid transaction or a link clicked by the user (that was, say, in an email) while the user is authenticated to the application. So, for example, using CSRF, an attacker makes the victim perform actions that they didn’t intend to, such as logout, purchase item, change account information, or any other function provided by the vulnerable website.

An Example below of a HTTP POST to a ticket vendor to purchase a number of tickets.

POST http://TicketMeister.com/Buy_ticket.htm HTTP/1.1
Host: ticketmeister
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;) Firefox/1.4.1
Cookie: JSPSESSIONID=34JHURHD894LOP04957HR49I3JE383940123K
ticketId=ATHX1138&to=PO BOX 1198 DUBLIN 2&amount=10&date=11042008

The response of the vendor is to acknowledge the purchase of the tickets:

HTTP/1.0 200 OK
Date: Fri, 02 May 2008 10:01:20 GMT
Server: IBM_HTTP_Server
Content-Type: text/xml;charset=ISO-8859-1
Content-Language: en-US
X-Cache: MISS from app-proxy-2.proxy.ie
Connection: close<?xml version="1.0" encoding="ISO-8859-1"?>
<pge_data> Ticket Purchased, Thank you for your custom.
</pge_data>

How to Locate the Potentially Vulnerable Code

This issue is simple to detect, but there may be compensating controls around the functionality of the application which may alert the user to a CSRF attempt. As long as the application accepts a well formed HTTP request and the request adheres to some business logic of the application CSRF shall work (From now on we assume the target user is logged into the system to be attacked).

By checking the page rendering we need to see if any unique identifiers are appended to the links rendered by the application in the user’s browser. If there is no unique identifier relating to each HTTP request to tie a HTTP request to the user, we are vulnerable. Session ID is not enough, as the session ID shall be sent anyway if a user clicks on a rogue link, as the user is authenticated already.

Transaction Drive Thru

An eye for an eye, A request for a request

When an HTTP request is received by the application, one should examine the business logic to assess when a transaction request is sent to the application that the application does not simply execute, but responds to the request with another request for the user’s password.

Line1 String actionType = Request.getParameter("Action");
2  if(actionType.equalsIgnoreCase("BuyStuff"){
4     Response.add("Please enter your password");
5     return Response;
6  }

In the above pseudo code, we would examine if an HTTP request to commit a transaction is received, and if the application responds to the user request for a confirmation (in this case re-enter a password).

The Flow below depicts the logic behind anti-CSRF transaction management:

Vulnerable Patterns for CSRF

Any application that accepts HTTP requests from an authenticated user without having some control to verify that the HTTP request is unique to the user’s session. (Nearly all web applications!!). Session ID is not in scope here as the rogue HTTP request shall also contain a valid session ID, as the user is authenticated already.

Good Patterns and procedures to prevent CSRF

Checking if the request has a valid session cookie is not enough, we need check if a unique identifier is sent with every HTTP request sent to the application. CSRF requests WON’T have this valid unique identifier. The reason CSRF requests won’t have this unique request identifier is the unique ID is rendered as a hidden field on the page and is appended to the HTTP request once a link/button press is selected. The attacker will have no knowledge of this unique ID, as it is random and rendered dynamically per link, per page.

A list is complied prior to delivering the page to the user. The list contains all valid unique IDs generated for all links on a given page. The unique ID could be derived from a secure random generator such as SecureRandom for J2EE. .
A unique ID is appended to each link/form on the requested page prior to being displayed to the user.
Maintaining a list of unique IDs in the user session, the application checks if the unique ID passed with the HTTP request is valid for a given request. if the unique ID passed with the HTTP request is valid for a given request.
If the unique ID is not present, terminate the user session and display an error to the user.

User Interaction

Upon committing to a transaction, such as fund transfer, display an additional decision to the user, such as a requirement for one’s password to be entered and verified prior to the transaction taking place. A CSRF attacker would not know the password of the user and therefore the transaction could not be committed via a stealth CSRF attack.

The GET request could be originated in several different ways:

by the user, who is using the actual web application;
by the user, who types the URL directly in the browser;
by the user, who follows a link (external to the application) pointing to the URL.

These invocations are indistinguishable by the application. In particular, the third may be quite dangerous. There are a number of techniques (and of vulnerabilities) which can disguise the real properties of a link. The link can be embedded in an email message, or appear in a malicious web site where the user is lured, i.e., the link appears in content hosted elsewhere (another web site, an HTML email message, etc.) and points to a resource of the application. If the user clicks on the link, since it was already authenticated by the web application on site, the browser will issue a GET request to the web application, accompanied by authentication information (the session id cookie). This results in a valid operation performed on the web application and probably not what the user expects to happen. Think of a malicious link causing a fund transfer on a web banking application to appreciate the implications.

By using a tag such as img, as specified in point 4 above, it is not even necessary that the user follows a particular link. Suppose the attacker sends the user an email inducing him to visit an URL referring to a page containing the following (oversimplified) HTML:

<html><body>...<img src=”https://www.company.example/action” width=”0” height=”0”>...</body></html>

What the browser will do when it displays this page is that it will try to display the specified zero-width (i.e., invisible) image as well. This results in a request being automatically sent to the web application hosted on site. It is not important that the image URL does not refer to a proper image, its presence will trigger the request specified in the src field anyway. This happens provided that image download is not disabled in the browsers, which is a typical configuration since disabling images would cripple most web applications beyond usability.

The problem here is a consequence of the following facts:

there are HTML tags whose appearance in a page result in automatic http request execution (img being one of those);
the browser has no way to tell that the resource referenced by img is not actually an image and is in fact not legitimate;
image loading happens regardless of the location of the alleged image, i.e., the form and the image itself need not be located in the same host, not even in the same domain. While this is a very handy feature, it makes difficult to compartmentalize applications.

It is the fact that HTML content unrelated to the web application may refer components in the application, and the fact that the browser automatically composes a valid request towards the application, that allows such kind of attacks. As no standards are defined right now, there is no way to prohibit this behavior unless it is made impossible for the attacker to specify valid application URLs. This means that valid URLs must contain information related to the user session, which is supposedly not known to the attacker and therefore make the identification of such URLs impossible.

The problem might be even worse, since in integrated mail/browser environments simply displaying an email message containing the image would result in the execution of the request to the web application with the associated browser cookie.

Things may be obfuscated further, by referencing seemingly valid image URLs such as

<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>

where [attacker] is a site controlled by the attacker, and by utilizing a redirect mechanism on

http://[attacker]/picture.gif to http://[thirdparty]/action.

Cookies are not the only example involved in this kind of vulnerability. Web applications whose session information is entirely supplied by the browser are vulnerable too. This includes applications relying on HTTP authentication mechanisms alone, since the authentication information is known by the browser and is sent automatically upon each request. This DOES NOT include form-based authentication, which occurs just once and generates some form of session-related information (of course, in this case, such information is expressed simply as a cookie and can we fall back to one of the previous cases).

Sample scenario.

Let’s suppose that the victim is logged on to a firewall web management application. To log in, a user has to authenticate himself and session information is stored in a cookie.

Let’s suppose the firewall web management application has a function that allows an authenticated user to delete a rule specified by its positional number, or all the rules of the configuration if the user enters ‘*’ (quite a dangerous feature, but it will make the example more interesting). The delete page is shown next. Let’s suppose that the form — for the sake of simplicity — issues a GET request, which will be of the form

https://[target]/fwmgt/delete?rule=1

(to delete rule number one)

https://[target]/fwmgt/delete?rule=*

(to delete all rules).

The example is purposely quite naive, but shows in a simple way the dangers of CSRF.

Therefore, if we enter the value ‘*’ and press the Delete button, the following GET request is submitted.

https://www.company.example/fwmgt/delete?rule=*

with the effect of deleting all firewall rules (and ending up in a possibly inconvenient situation).

Now, this is not the only possible scenario. The user might have accomplished the same results by manually submitting the URL

https://[target]/fwmgt/delete?rule=*

or by following a link pointing, directly or via a redirection, to the above URL. Or, again, by accessing an HTML page with an embedded img tag pointing to the same URL.

In all of these cases, if the user is currently logged in the firewall management application, the request will succeed and will modify the configuration of the firewall. One can imagine attacks targeting sensitive applications and making automatic auction bids, money transfers, orders, changing the configuration of critical software components, etc.

An interesting thing is that these vulnerabilities may be exercised behind a firewall; i.e., it is sufficient that the link being attacked be reachable by the victim (not directly by the attacker). In particular, it can be any Intranet web server; for example, the firewall management station mentioned before, which is unlikely to be exposed to the Internet. Imagine a CSRF attack targeting an application monitoring a nuclear power plant. Sounds far fetched? Probably, but it is a possibility.

Self-vulnerable applications, i.e., applications that are used both as attack vector and target (such as web mail applications), make things worse. If such an application is vulnerable, the user is obviously logged in when he reads a message containing a CSRF attack, that can target the web mail application and have it perform actions such as deleting messages, sending messages appearing as sent by the user, etc.