An interesting discussion, led me to realize this is one of the commonly discussed topic and I thought a blog post for it might be helpful for someone.
Cross-site request forgery and Cross-site scripting are both client side attacks which performs action on behalf of users.
Just some context here -
- Cross-site scripting (or XSS) allows an attacker to execute arbitrary JavaScript within the browser of a victim user. The attack happen because of the acceptance of the malicious code by the sites.
- Cross-site request forgery (or CSRF) allows an attacker to induce a victim user to perform actions that they do not intend to. This attack can be performed by the code hosted on any third party attacker controlled site.
Before diving into the differences, let’s see what conditions needs to be met in order for both the attacks to be successful.
XSS | CSRF |
---|---|
Web application accepts data from an untrusted source and does not put any validation on top of it. | There need to be a relevant action that is to be performed. |
The data is embedded in dynamic content that is delivered to a web user without being checked for malicious content. | The sessions are handled using the cookies and there are no unpredictable request parameter & additional headers. |
If all these things are met, and the attack can be called successful when the attacker is able to perform some tasks on behalf of the user. Where is the difference? (Other than their abbreviation)
Talking Differences
Both the attacks can be performed on the authenticated user or unauthenticated user, but
- The real impact for CSRF attack is shown when a user is authenticated and the attacker is able to perform action as the victim authenticated user.
- For XSS, it can be performed on authenticated or unauthenticated web application and can cause substantial damage in both.
If the application is vulnerable to CSRF, the attacker can perform actions that the victim can perform but it’s just that. XSS enlarges the scope of damage by the actions the attacker can perform, as it allows execution of malicious script on the web application which means regardless of the functionality in which the vulnerability arises, a user could execute any action that the user is capable of.
It is quite possible in some scenarios for XSS to be executed without user interaction but CSRF needs interaction from user, like clicking a malicious link or visiting a attacker controlled website.
If we go a bit more technical - CSRF only works one way - even if an attacker can persuade the victim to send an HTTP request, they cannot retrieve the response. But in case of XSS, it’s a two way vulnerability - the script that the attacker injected has the ability to make arbitrary requests, read the responses, and exfiltrate data to a chosen external domain.
To sum all of it up - In XSS, the hacker takes advantage of the trust that a user has for a certain website. On the other hand, in CSRF the hacker takes advantage of a website’s trust for a certain user’s browser.
Relativeness of the vulnerabilities
When a site is vulnerable to XSS, it is also vulnerable to CSRF attacks, whereas a site that is completely protected from XSS attacks is most likely vulnerable to CSRF attacks. Because XSS occurred as a result of the sites' acceptance of the malicious code, and CSRF can be performed by code hosted on any third-party attacker-controlled site.
So, yeah here you have the answer!
Last Bytes
The references that I used are number of blogs found with a google search - “XSS vs CSRF”, this article gives a collective overview of things and the things that made sense to me, some of them are -
- http://www.differencebetween.info/difference-between-xss-and-csrf
-
https://portswigger.net/web-security/csrf/xss-vs-csrf
Here are some related and nice articles/blogs to keep exploring -
-
Interesting Use-case - Using XSS to bypass CSRF protection
- CSRF Prevention Cheat Sheet by OWASP
- XSS Prevention Cheat Sheet by OWASP
That’s it folks! Until next time ✌️