CSRF and the Confused Deputy

Imagine that a smooth operator convinces Barney Fife — the famous sheriff’s deputy on TV — to unlock a Mayberry jail cell. Barney has the keys. He has the authority. He wants to do the right thing, but he’s easily confused and manipulated.  Your web browser has authority too.  It can do a lot of things. It can execute code and it doesn’t complain. In fact, your browser is pretty indifferent about the scripts it will run. Just authorize it, and off it goes. Now, suppose someone (a hacker) tricks your browser into running malicious code. Your browser is no smarter than Deputy Fife, really. This gives you some idea as to why they call the cross-site request forgery hack a confused deputy attack.

Abuse of Authority

Cross-site request forgery (CSRF) is also known as XSRF, sea surf, or session riding. What is cross-site request forgery? It’s a misuse of authority. YouTube poster LiveOverflow says that with CSRF, the attacker tricks the browser into executing a privileged action. “And the weird thing is,” says the narrator, “neither executing JavaScript nor handling authenticated sessions is a security vulnerability. This is not a bug of the browser.  This is how the browser is supposed to behave.”

With CSRF the attacker tricks the browser into executing a privileged action.

So if the browser is doing what it’s supposed to do, what exactly is the problem? When a hacker injects script, it abuses the special authority of the browser. The attacker is taking advantage of the legitimate functions of a web application to perform actions that were unintended by the developers. And the consequences can be devastating.

It’s all a matter of trust. When a user seeks authentication to the website through login or some other method, the website issues a cookie to the user’s browser. This means that the web application trusts the web user’s browser. The writers of You’ve Been Hacked website say that there are three things a victim is doing before becoming vulnerable to a CSRF attack:

• Posting to a well-known URL.
• Sending a cookie,
• Posting some data.

While such a session is active, that’s when a bad guy can hit. If you are still logged into your bank’s website while “promiscuously” surfing the web, you’re now in dangerous territory.

GET, POST and FORM Actions

The Open Web Application Security Project (OWASP) lists CSRF as in its Top 10 security vulnerabilities for 2013. (The 2017 list is still under review at the time of this writing.) In its documentation on CSRF, OWASP says that the attack “inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf”. The website explains how the bad guys can use both GET and POST methods to do their CSRF mischief.

Before we give examples, let’s get some background on these terms. The World Wide Web Consortium (W3C), directed by none other than the inventor of the WWW Sir Tim Berners-Lee himself, explains GET and POST in a tutorial. The site calls them the “two commonly used methods for a request-response between a client and server”:

• GET – Requests data from a specified resource
• POST – Submits data to be processed to a specified resource

Now let’s borrow a simple GET scenario from OWASP. It starts with a single request. Alice wants to transfer $100 to Bob, and her web browser does the work:

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

But Maria is ready to take advantage of the active session Alice has with her bank. Through an unsolicited email or an exploited website that Alice would likely visit, Maria manages to slip another request through Alice’s browser:

http://bank.com/transfer.do?acct=MARIA&amount=100000

As you can see, Maria just convinced Alice’s browser to send $100,000 to her account. The dirty deed is done!

The whole idea of CSRF is to take advantage of a user’s trusted session to take actions unknown to the user. The way this is done is by tricking the user’s web browser to run hidden commands. The GET method could hit the user totally unnoticed in a web link:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

Another way a hacker injects GET where it is not wanted is to make an object very, very small. Pixel density is measured in pixels per inch (PPI) or pixels per centimeter (PPCM). A typical computer screen may be 85 PPI, but could be more than 200 PPI. Now imagine that a hacker has managed to put an actionable object on your screen that is only one pixel by one  pixel (1×1).  The hacker could even use a 0x0 image. Not even the best eyes would be able to see that.

Now let’s look at a POST scenario, again from OWASP.  The bank’s code may use POST to transfer the $100 to Bob as requested by Alice. But the devilish Maria has an answer for that too. She uses a FORM that’s hidden in an image or URL tag:

<form action="http://bank.com/transfer.do" method="POST">

<input type="hidden" name="acct" value="MARIA"/>

<input type="hidden" name="amount" value="100000"/>

<input type="submit" value="View my pictures"/>

</form>


You see that the hacker can use different HTTP methods for the CSRF exploit. There are other ways to do it, but the effect is the same. Maria cleans out Alice’s bank account with very little effort.

CSRF Exploits

So what can a hacker gain from using cross-site request forgery? We’ve already discussed the exploitation of banking sessions to steal money. That’s not the only thing they can do.

ComputerWeekly offers a brief list of potential uses for CSRF. We’ll include them here:

• Transfer money from one bank account to another.
• Use a content management system to add/delete content from a website.
• Change a user’s password.
• Add items to a user’s shopping basket.
• Change the delivery address of an order.

They say that CSRF has been used in real-world attacks against Facebook, Gmail and the social networking site Digg. Researcher Jaya Gupta offers this list of sites that have been known to have CSRF vulnerabilities:

• ING Direct (ingdirect.com)
• YouTube (youtube.com)
• MetaFilter (metafilter.com)
• The New York Times (nytimes.com)
• Gmail (gmail.com)
• Netflix

Of course, as with all hacks, CSRF can have as many possible uses as an evil hacker can imagine. And who knows how many sites have suffered the exploit unknowingly.

Mitigating CSRF

To understand how to prevent CSRF, we are once again indebted to OWASP. In their “Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet”, they expound on two defenses against the exploit:

• Check standard headers to verify the request is same origin
• AND Check CSRF token

We have seen that the hacker takes advantage of an existing session. The reason the user’s browser can communicate with the web application is that it sends along an authenticating cookie. But for the web app to prevent unwanted activity, it should check the standard headers. The details will require further examination, but OWASP recommends using header checks to verify the validity of the request.

Next, OWASP says that there are “specific” defenses that can mitigate against CSRF, including those related to tokens. They list these in order of strength of defense:

• Synchronizer (i.e. CSRF) Tokens
• Double Cookie Defense
• Encrypted Token Pattern
• Custom Header – e.g., X-Requested-With: XMLHttpRequest

Just a word on cross-site scripting (XSS), which we covered in another blog article:  XSS and CSRF are not the same, even though they may sound similar. But there is some overlap. The two hacks can be used in tandem. And as OWASP suggests, creating defenses for one should include addressing vulnerabilities for the other.  The writer of an article called “Friends Don’t Let Friends Mix XSS and CSRF”, explains the relationship between the two. As he explains, “One is used to run untrusted code while the other is used to hijack authentication.”

The key to CSRF prevention is to require additional authentication data in the requests.

The key to CSRF prevention is to require additional authentication data in the requests. In this way, you can keep out those who don’t meet those requirements. As one website points out, CSRF protection should be used “for any request that could be processed by a browser by normal users”. You wouldn’t need it for transactions that don’t involve browsers.

According to Checkmarx.com, “detecting cross-site request forgery flaws are easily prevented – once you know what you’re looking for”.  They talk about the use of CSRF tokens, which make each request unique for the user.  The focus must be on eliminating vulnerabilities in existing code — or writing it better in the first place.

Conclusion

“Web browsers are very trusting things,” says Computerphile Tom Scott. “If you give them some code to run… they will just run it.” We like to think of computers as being intelligent — perhaps because we want to make something in our own image. We admire their speed of calculation and machine-like precision. We call our phones smart. But perhaps we have forgotten a phrase that was commonly used a few decades ago to refer to computing:  “Garbage in, garbage out.”

Your computer is not capable of making a moral judgement about the code that is passing through it. So long as it follows whatever rules have been set for it, a web browser will process malicious code as quickly as it would legitimate programming. It’s even more stupid than Deputy Fife (if that’s possible), and will let anybody have access to anything its programming permits and won’t think twice about it. The answer is better programming and smarter programmers. You should also consider something like Total Uptime’s Web Application and API Protection (WAAP) suite to protect against CSRF and more!