In this section, we’ll explain what cross-site scripting is, describe the different varieties of cross-site scripting vulnerabilities.
What is cross-site scripting (XSS)?
XSS is a web security vulnerability that allows the attacker to access victim’s data by injecting malicious javascript onto the page. Javascript has access to all your data for a site, so all the private information of the victim user can be leaked. In general, the same origin policy is applied, which prevents javscript from page A from running on page B. But since in XSS javascript runs on page A itself, it effectively bypasses same origin policy. You can read about this in detail here.
How does XSS work?
Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application.
What are the types of XSS attacks?
There are three main types of XSS attacks. These are:
- Reflected XSS, where the malicious script comes from the current HTTP request.
- Stored XSS, where the malicious script comes from the website’s database.
- DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
Reflected XSS
Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.
Here is a simple example of a reflected XSS vulnerability:
https://insecure-website.com/status?message=All+is+well
<p>Status: All is well</p>
The application doesn’t perform any other processing of the data, so an attacker can easily construct an attack like this:
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>
If the user visits the URL constructed by the attacker, then the attacker’s script executes in the user’s browser, in the context of that user’s session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.
Stored XSS
This type of vulnerability arises when a site takes input from untusted sources and includes it later in all of the HTTP responses. An example of such a scenario is a comment section on a blog post.
So for example the input is directly displayed to other users as <p>Hello, this is my message!</p> on writing Hello, this is my message! into the input box. In this case, the attacker can make a comment that is rendered as <p><script>/* Bad stuff here... */</script></p>. Now when other users come to this website, the script runs in their session and steals sensitive data.
DOM Based XSS
DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.
It is different from stored or reflected XSS because the vulnerability is not in the HTTP Response itself, but occurs during the runtime.
In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;
If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:
You searched for: <img src=1 onerror='/* Bad stuff here... */'>
In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.
Impact of XSS vulnerabilities
The impact of XSS generally depends on the nature of the application. If the application contains only anonymous user data and all information is public, the impact would be minimal. However, in a case where the data is sensitive like user emails and passwords, the impact can be pretty serious.
How to prevent XSS attacks
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
- Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
- Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
- Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
- Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
The material has been taken from here. So if you wish to read about some topic in more detail, or wish to perform these attacks in simulated labs, do check it out!