Cross-Site Scripting (XSS) is one of the most common types of security vulnerabilities on the internet. XSS is widely used by attackers typically targeting web applications and has been included on the OWASP Top 10 since it’s 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)?
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 permits or denies how a document or script is loaded. It does this off 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?
What are the different types of Cross-Site Scripting?
Stored XSS: Where the malicious script is sent to the application and stored. This is arguably the most severe as it’s 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
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:
However, if no input validation is performed and the site reflects the value of the parameters back within the site this could be abused.
Let’s now add the common alert box which is used as a proof of concept to the first name parameter:
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
A search box is a place which Reflected XSS could be found. Let’s imagine after submitting something to search, the following item is appended to the URL:
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:
The payload would then be reflected back to the user after submission, as shown below:
Examples of DOM-based XSS
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.
Now we have covered the basics of Cross-Site Scripting 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.
Brandyn Murtagh, Security Consultant
Brandyn is a Security Consultant at Informer who recently attained his OSCP accreditation.