A decade ago, there was a shift in the way the computer applications were used, illuminating an epoch of web application development. Now the computers have reached a point where people can write better programs & perform the most complex operation with the application. These circumstances arose the demand of portability and finally, the web-based applications become popular. However, with the emergence of the web-based application, came several kinds of attacks including SQL injection attacks and cross-site scripting. It is essential to understand the threat, its nature and influences in order to prevent it from influencing into our creations.
We have already discussed the SQL injection attack with some corresponding examples in our earlier blog, “Understanding The SQL Injection Attacks”, here we are going to explore deep about the cross-site scripting attack.
Cross-site scripting vulnerability is the most common weakness present in the WordPress Plugin. The following figure illustrates the result of their analysis:
Among the 1599 WordPress plugin vulnerabilities they found after 14 months, the following are the notable distribution
Image Source: wordfence.com
An Overview Of Cross-Site Scripting
Cross Site Scripting attack, is possible if the attacker is able to trick client system, like browser, to execute some code or script. The client system will execute same by considering that it is the part of the application and runs same in that context. Cross Site Scripting attack primarily targets browser, not Server.
Unlike the SQL injection outbreak, where the hacker is victimizing a vulnerable website to achieve access to its data, the cross-site scripting attack can directly target the user of the website. Though both kinds of attack, inject the malicious code into the website, in cross-site scripting, it is not the website, which is attacked. The malicious codes are usually injected in the comments as well as scripts from where they run automatically. Cross Site Scripting attack, is possible if the attacker is able to trick client system, like browser, to execute some code or script. The client system will execute same by considering that it is the part of the application and runs same in that context. In addition, these attacks affect the reputation of a website by placing the user’s information at the danger of being misused or stolen.
The success of the cross-site scripting attack needs the victim to run a malicious URL that may be created in such a way to appear to be valid or authentic at first look. The clicking on such an URL allows the attacker to execute something malevolent in the browser of the victim.
So, Cross Site Scripting is a low hanging fruit that anyone can trigger without many privileges. This flaw can easily be detected by both white and black box analysis of the application. This flaw doesn’t impact server directly, but it may result in sensitive data leakage resulting in more severe attacks like a hijacking.
Types Of Cross-Site Scripting
There are three different kinds of the cross-site scripting. They are
In this type, user provided input script is not stored, but merely included in the response from the server, either in results of a search or as an Error message. This type is commonly known as non-persistent or Type-II.
Here the attacker inserts the malicious executable code within an HTTP response. Since it is a non-persistent attack, the inserted attack is not archived within the target application. In addition, it only influences the users who clicked the malicious link.
In stored XSS, user provided input script is stored on the Target Server like a database, visitor log, message forum, comment field, etc. So, every time user visit page, it gets executed. This is also known as persistent or Type-I.
DOM Based XSS
Here, the payload is executed in victim’s browser as a result of DOM environment modifications on the Client side. This type is also known as Type-0.
Let us explore the cross-site scripting vulnerability with an example:
Consider the following scenario:
Here user clicks a URL with attack payload. If the server is not filtering data properly, it will send it back as a part of the response. The client system will consider it as a part of code coming from Server and will execute it. This case is known as Reflected type, as the script is reflected back from the Server.
As shown above, in case, Server stores this attack script as part of user input, it is called as stored type. In stored type, whenever, the user retrieves the page containing this script, it will be executed.
To demonstrate what aggressors can do by exploiting cross-site scripting vulnerabilities, we have used a simple DNS lookup page.
For example, if the attacker entered the following script as an input:
The result will pop-up an alert window with the input given:
Attacker as a part of the script, may call any client function and can extract data accordingly. For example, if they place document.cookie as script value:
It will result in session id under alert window:
This attack is called as reflected type cross site scripting. Let us analyse a case, where a blog entry field is present.
Here a user can insert a blog content, and will be stored at server side. This entry will be disclosed to all users on retrieving the same. If instead of blog, we place a simple java script like last scenario.
we can see it is stored as an entry at server side, and will be executed every time page is loaded.
This scenario is not only valid for current user, but also for any user, who can access the concerned page. Let us login as a valid user, and access same page:
we can see script is triggered accordingly, showcasing session id of concerned user.
In this case, where script is stored permanently at server side, is known as persistent or stored cross site scripting.
Cross Site Scripting Prevention Method
Though the recent browsers comprise an inbuilt XSS filter, they shouldn’t be sound as a substitute to sanitization. They can’t detect entire types of cross-site scripting attacks & aren’t strict to avoid false positives that would prevent web pages from loading. The XSS filter in the web browser should consider as the second line of defense.
As a part of prevention steps, we need to ensure the following actions:
Strictly whitelist, filter, and analyze user input at both clients, and server side.
Usage of Security headers like Content Security Policy is also recommended, to avoid loading of the script from untrusted sources.
It is essential to implement a context-dependent output encoding
It is also essential to avoid straining of risky characters and functions since the XSS filters in the browsers cannot recognize the risky payloads
If you capable to determine and avoid cross-site scripting vulnerabilities and protect your application output, then you’ll avoid half of whole vulnerabilities, which might be introduced into the application.