Last Updated on 7 June 2023 by admin
Table of Contents
Cross-Site Scripting (XSS) is one of the most common types of cybersecurity vulnerabilities on the internet. XSS is widely used by attackers typically targeting web applications and has been included on the OWASP Top 10 since its inception. In our three-part in-depth series, we are going to cover Cross-Site Scripting, how it can be abused from an attacker’s perspective, and more importantly how to defend against it.
What is Cross-Site Scripting (XSS)?
Cross-Site Scripting is a type of injection attack whereby malicious JavaScript is injected into an input, typically on a website. Once the malicious JavaScript has been embedded, an attacker will wait for the script to be executed or send it to an unsuspecting end user. Each class of Cross-Site Scripting executes differently and can have a slightly different delivery mechanism from one another.
Same Origin Policy (SOP)
Before we go any further it’s important to understand some fundamentals. The Same Origin Policy (SOP) is a security control built into all browsers which either permit or denies how a document or script is loaded. It does this on the basis of the origin of the script or document. The origin consists of a protocol, port, and host.
An example of this would be http://test.com/test and http://test.com/test2 – scripts and documents would be permitted as they are part of the same origin. However, https://abcdtest.com/ and http://test.com have a different origin, as they consist of a different protocol (https v http) and host (abcdtest.com v test.com). This is important to know as XSS allows the SOP to be bypassed.
Why does Cross-Site Scripting exist?
Cross-Site Scripting exists in websites when inputs are handled in an unsafe manner. An example of this could be a variable within a URL, such as http://test.com/xss?xssparam=. The value xss?param could be used to generate dynamic content for the site and is returned within the output from the site. If no validation or encoding is done on the value of the parameter, an attacker could manipulate the parameter to contain their own JavaScript.
What are the different types of Cross-Site Scripting?
There are 3 main types of Cross-Site Scripting. These are identified by how the JavaScript is injected into the application and how the application returns the JavaScript to the user. Below gives a brief overview of each XSS type:
Stored XSS: Where the malicious script is sent to the application and stored. This is arguably the most severe as its executed every time the page is visited, without any further requests from the attacker.
Reflected XSS : Where the malicious payload is from the current request to the application. The application then reflects this back in its response to the user.
DOM-based XSS: This is where the payload is executed within the DOM (document object model). The response from the server does not change, but the code stored on the client side executes the payload.
Examples of Stored XSS
Stored Cross-Site Scripting, as previously mentioned, is when the input (a malicious Javascript payload in this case) is saved by the application and later executed. Stored Cross-Site Scripting is the most severe of the 3 types as the payload could be executed an unlimited number of times to unsuspecting users of the site.
Let us take the personal information section of a profile. Inputs typically exist for first name, last name and email address. The parameters to update this could look like:
Firstname:John,
Lastname:Doe,
emailaddress:john.doe@Example.com
However, if no input validation is performed and the site reflects the value of the parameters back within the site this could be abused.
Lets now add the common alert box which is used as a proof of concept to the first name parameter:
Firstname:<script>alert(“XSSâ€)</script>,
lastname:Doe,
emailaddress:john.doe@Example.com,save=yes
Now the application has saved this payload, any time the application needs to generate content with the ‘firstname parameter in the response our payload will be executed. Below shows an example of what this payload would look like to the user when it is executed:
Examples of Reflected XSS
With Reflected XSS, the input is immediately reflected in the response from the web application. A typical example of this is the one mentioned earlier, with a parameter being contained within a URL. This type of attack is typically combined with phishing as its delivery mechanism in order to get the user to click on the link, and execute the JavaScript contained within.
A search box is a place that Reflected XSS could be found. Let’s imagine after submitting something to search, the following item is appended to the URL:
?item=test
And this item is reflected back to the user after the search, shown below:
Now, if we were to append a payload to the URL such as:
?item=<script>alert(“ReflectedXSS”)</script>
The payload would then be reflected back to the user after submission, as shown below:
This means the link http://example.com/test/?item=<script>alert(“ReflectedXSS”)</script> could be emailed to users and the above JavaScript would be executed!
Examples of DOM-based XSS
DOM-based XSS is slightly different when compared to previous classes of XSS. With DOM based, the JavaScript is reflected back to the user within their own DOM (document object model). The DOM is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style, and content dynamically, without sending requests to the server. The DOM represents the document as nodes and objects.
With DOM-based XSS, the response from the application will be the same and the payload will not be visible. However, the payload can be seen within the DOM of the page and can only really be seen on runtime of the payload. Typically, inputs such as URL query string parameters are used to deliver this type of XSS in a similar fashion to Reflected XSS.
Summary
Now we have covered the basics of cross-site scripting XSS attacks we can start to take a deeper dive into the more severe payloads that can be used, and more importantly how to prevent them from occurring in the first place. The next article will build upon what we have covered so far and demonstrate just how severe XSS is.
