Something Awesome Project - Cross-Site Request Forgery
Cross-Site Request Forgery
According to OWASP, a 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". To understand this, we need to know what's in an HTTP request and how can one forge it.
The Hypertext Transfer Protocol or HTTP for short is a protocol used in data communication for the web. Often when we browse the web, we make HTTP requests to the web server to let them know what to send back to us to display in our browser.Â
The HTTP request format has:
A start-line describing the requests or the status of the last request. Request methods are often included here when we make a request to the server.Â
The four common methods are GET, POST, DELETE, PUT. When we enter a URL to the browser and press enter, we first make a GET request to the web server that the URL points to.
Header fields describing the properties of the request. The request header field is part of the header fields where it allows users to pass information about the request and the user themselves.Â
Some of the important fields are Authorization, Connection, From, Host, Referer, User-Agent.
An empty line indicating the end of the header fields.
The message body (optional). This contains data associated with the request such as content for form submission or HTML data.Â
Every time you go to www.google.com, you will have to make a GET request to get the homepage of the search engine. An example of an HTTP GET request that your browser makes to www.google.com:
GET HTTP/1.1 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Host: www.google.com Connection: Keep-Alive
As you can see, Google can see the information that the browser automatically put in the request like User-Agent. This information tells Google that you are using Firefox 47.0 on a Windows x64 machine. Of course, much more information is sent in a typical HTTP request by your browser but here I am showing you how much data is given away to the web server that you don't know.
When a website makes a request to another web server on behalf of the user, there won't be any security concerns as long as no authentication is needed. However, when the user's session cookie is sent with the request, an attacker can do a CSRF attack.Â
There is a common theme in CRSF and XSS attacks, that is the process of attacking comprises of building a malicious URL then tricking the victim into executing it using social engineering or phishing.Â
The difference between CRSF and XSS attacks is CSRF happens when the server trusts the user/browser, while XSS doesn't need an authenticated session and can be exploited when the vulnerable website doesn't do the basics of validating or escaping input.
Example of a CSRF GET attack
A bank called TrustedBank has a website to allow clients to check on their account and make transactions. One of the valid transactions is to transfer money to another account, given that the client is logged in.Â
The URL is a GET request with parameters for the amount of money and the account to transfer to is:
http://trustedbank.com/transfer?amount=100000&account=Bob
The request must include a session cookie to verify that the client is logged in before going through the transferring process. Because of having a session cookie, the request doesn't need to have a source as all the information about the client is stored in the cookie. A hacker Elliot knows this vulnerability and tricked Bob into clicking on this URL:
http://trustedbank.com/transfer?amount=1337&account=Elliot
Of course, the hacker can try to mask the URL with HTML by including it in a <img> tag:
<img data-fr-src="http://trustedbank.com/transfer?amount=1337&account=Elliot" />
If the victim is already logged in and clicked on the malicious image, he will make a request to the bank to transfer money to Elliot's account without him knowing.
Example of a CSRF POST attack
Often than not, the URL for making transactions only accepts POST requests, as we do have to submit the information provided in the web form, with the parameters provided in the message body.
A POST request to transfer the money might look like this:
POST http://trustedbank.com/transfer HTTP/1.1 amount=1337&account=Elliot
The request cannot be spoofed into a <img> tag like before, but rather a form like this:
<form action="http://trustedbank.com/transfer" method="POST"> <input type="hidden" name="account" value="Elliot"/> <input type="hidden" name="amount" value="1337"/> <input type="submit" value="View my pictures"/> </form>
Example of origin spoofing
Some sites might require the referer field in the HTTP header to know where the request is coming from and prevent CSRF attacks. But the attackers can counter this by giving the same site URL in the referer to spoof the origin of the request as if it came from the same site.
POST http://trustedbank.com/transfer HTTP/1.1
Referer: www.trustedbank.com amount=1337&account=Elliot
Many attempts have been made to counter this kind of attack. These are the prevention measures that do NOT work: using a secret cookie, only accepting POST requests, HTTPS, URL Rewriting, Multi-Step Transactions.
Since Cross-site attacks happen on the client side, it is hard to have a full-proof prevention method. Security experts propose many CSRF prevention methods such as using a referer header, using HttpOnly flag, etc. but not all of them are effective in every case.Â
Two practical approaches to handle CSRF are:
Anti-CSRF tokens: When a user submits a form or makes some other authenticated request that requires a Cookie, the Anti-CSRF token should be included in the request. The web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.
Same-site Cookies: The same-site attribute is set by the server when setting the Cookie and requests the browser to only send the cookie in a first-party context, therefore, the request has to originate from the same origin â requests made by third-party sites will not include the same-site Cookie.
Although prevention measures are available, victims may be vulnerable to well-crafted social engineering or phishing attacks, which the web server or browser does not have control over. A high amount of damage can be dealt if administrative users fall victim to the attack. It is best that companies train their employees to handle social engineering attacks as well as being cautious when logged in to their systems.