XSS and CSRF vulnerabilities are some of the most dangerous and the most popular vulnerabilities on the web. Fortunately, the CSRF vulnerability is getting rarer as modern programming technologies put security controls for it by default. However, I guess one of the most common questions I have ever received from my clients and my students is what is the difference between the XSS vulnerability and the CSRF?
The main difference between the XSS vulnerability and the CSRF vulnerability is related to the attack concept. The XSS vulnerability relies on the injection of malicious javascript code into a legitimate web application, contrary to the CSRF vulnerability where only the structure of the request is needed to launch the attack.
In terms of exploitation and impact, these two vulnerabilities look very similar which creates a sort of confusion. However, in this blog post, I am going to explain and clarify the key differences between these two vulnerabilities.
In addition, I am going to give some vulnerable code snippets so that it becomes easier for you to find those vulnerabilities in your source code and fix them. So if you want to learn more about this subject then just keep reading.
The XSS vulnerability happens when the application fails to filter the user inputs before injecting them into a legitimate page. In most cases, the attacker tries to inject malicious Javascript code into the legitimate web application.
This vulnerability has three types:
In the XSS stored type, the malicious code is stored in the database of the application and is called whenever the vulnerable page is called. This concept, makes this type of XSS vulnerability the most dangerous between the three, as it only needs one exploitation to impact all the users.
Contrarily to the XSS stored type, the XSS reflected and the DOM-based types require direct interaction with the victim and can only be executed after clicking on a link or visiting a malicious website. In these two types of vulnerabilities, the attacker needs to have good social engineering skills to trick the users to click on or visit a website.
The obvious impact of this vulnerability is the stealing of the user login information. Unfortunately, the impact of this vulnerability can be more critical than this. Advanced exploitation of this vulnerability could give the attacker the possibility to penetrate the client’s machines and execute malicious codes.
The Cross-site request forgery vulnerability happens when the application forms or requests, in general, are guessable from attackers. The attacker then forges a request that performs a certain action on the app and then tricks the legitimate users to click or execute those requests.
To be honest, I’ve tried many techniques to explain this vulnerability to my students, and the only one that has found effective was to illustrate this vulnerability with an example.
Therefore, let’s suppose we have an application functionality that gives the admin users the ability to validate a subscription or deny it. When the admin user clicks on the validate button in the subscribers.php page for a certain new subscriber, that user is then validated and can log in.
Here is then the generated GET request sent to the web application to execute that action:
https://example.com/subscribers.php?action=validate&userID=aed32c28
Of course, before executing the action, the application verifies that the user who initiated that request is logged in and is an admin.
Looking at the request, we can easily see that the application is vulnerable to a CSRF vulnerability. Actually, after changing the userID variable, by the attacker’s userID, this one can trick the application admin to submit this request from his own navigator with his own cookies and validate his account. This can be easily performed with an html code in an email.
Here is an image that explains illustrate this scenario:
The impact of this vulnerability strongly depends on the functionalities offered by the app. For example, if this vulnerability was discovered in WordPress, especially in the theme editor form. If this form was vulnerable to CSRF, then an attacker can force the admin to write malicious code into this form and submit it. The attacker would then take over the whole server.
Until now, all we have discussed is about the vulnerabilities attacks concepts and we have seen how they can be exploited by hackers. Now the most important aspect for me as a security expert is how to fix the issue. Therefore, in this part of this blog post, we will see the main differences in terms of security mechanisms put to fix each issue.
Fixing the XSS vulnerability can be performed in two manners depending on the complexity of the app and the number of display interfaces. However, the main idea is still the same for both techniques, which is filtering the user data and eliminating any javascript or HTML tags.
The security controls that filter the user’s data can be put in two points:
The most recommended technique is to put the filtering functions at the displaying phase to avoid any alteration of the user’s inputs. This technique should be performed at the very beginning of the application development.
However, in some situations where displaying the user data is very common in the web interfaces. Filtering the data at the displaying moment will increase the page load time by adding more functions call. Therefore, filtering the user’s data at the submission time becomes necessary.
I have written a more detailed blog post about how you can fix the XSS vulnerability in PHP and in its most popular frameworks if you are interested to get more in defense techniques. However, here is an example of what functions and parameters are used in a PHP source code to fix this issue:
<?php echo htmlspecialchars($_GET[‘name’],ENT_QUOTES,’UTF-8’);?>
The displaying phase means when you try to display some user data in your web application interface.
For the CSRF vulnerability, the fixing process takes more time than the XSS especially if the source code is not well organized and more complex. The idea here is to make all the forms and requests that execute a functionality in the app unguessable.
Therefore, to do that all you need to do is to add a hidden input in case of a form or add a specific variable in case of GET request that contains a random unguessable 32 chars. This random string should be connected to the session of the legitimate user and change once he login next time. Once the legitimate user sends a form and before executing the requested functionality, this token is verified to see if it is the one created at the login step.
Most modern programming technologies force developers to implement this protection by default in each and every form or request they create. This default functionality in modern technologies has lead to massively reduce the number of CSRF vulnerabilities discovered on the web.
Adding this mechanism at the beginning of the development process is very easy and basically does not take too much time. However, implementing it for an already established app will require a significant amount of work.
I would like to finish this blog post with some of the most common questions I get from my students or my clients about each vulnerability. The first one I am going to start with is the XSS.
The SSL certification or protocol does not protect your app from an XSS vulnerability. An SSL protocol is designed to secure the communication between the web application server and the end-user. This vulnerability is related to the core code of the app and not the way it communicates.
Actually, this protocol should always be implemented and used to protect the application traffic from any Man in the middle attack.
APIs could also be vulnerable to XSS. APIs are just another type of web application and they get developed with the same technologies as a simple web application. Therefore, not filtering the user data saved in the backend of the API using any type of client (web interface, mobile…) and displaying it in another application will make your API vulnerable to XSS.
In most cases when the API force the type of content it sends to its clients, the XSS vulnerability becomes difficult to be directly exploited. However, even by forcing the response content type, the application that will consume the API service will still be vulnerable to XSS if it doesn’t filter it.
X-XSS-Protection does not effectively protect your application from the XSS vulnerability. The X-XSS-Protection is an HTTP header that was implemented to stop the page from loading when it detects a reflected XSS vulnerability.
More common questions I have noticed for CSRF, as the attack concept is more difficult than the XSS vulnerability. Here is a list of some of the common questions I get:
CSRF vulnerability work with all possible HTTP Verbs including the GET, POST, PUT. In fact, this vulnerability is related to the functionalities that the application offers regardless of the used HTTP Verb.
The Cross-Origin Resource Sharing (CORS) mechanism protects the web application from requests that comes from a whole different domain. In typical exploitation of the CSRF vulnerability, the attacker will create a malicious email or web page that has a javascript code that will make a request to your website.
Therefore, the CORS mechanism might seem to be a good solution to stop this issue. Even if this mechanism protects the application against this exploitation technique, this vulnerability can always be exploited by others.
The simplest way to bypass the CORS mechanism is to create a comment for a website blog post or product that has the CSRF exploit. Once this URL is clicked by the admin, the malicious request will bypass the CORS mechanism. The CSRF token is needed even if the CORS mechanism is in place.
APIs could also be vulnerable to CSRF, the API is just another type of web application that doesn’t have an interface. Therefore, basically, all the vulnerabilities that exist in the simple web application apply to them too. Unfortunately, APIs are the most common places for CSRF vulnerabilities, and this is due to the fact that no form is displayed directly from the API which tricks the developers.
The CSRF token should always be present and it is the only recommended way to fix this issue for good.
As I said for XSS, https cannot prevent CSRF vulnerability. The https protocol is used to secure the HTTP communications between the web application server and the client browser.
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).
As an old developer and a penetration tester, between all the vulnerabilities I have seen in my whole experience in both fields file upload was the most difficult one to ...
Post comments (0)