Cross Site Scripting

What is Cross-Site Scripting (XSS)?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user’s data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application’s functionality and data.

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 Cross-site Scripting

Reflected XSS is the simplest variety to 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+<p>Status: All is well.</p>

Stored Cross-site scripting

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. Here is an simple example of a stored XSS vulnerability. A message bored application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

DOM-Based Cross-site Scripting

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 in an unsafe way, usually by writing the data back to the DOM.

In the following example, 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… */’>

Impact of XSS Vulnerabilities

The actual impact of an XSS attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For Example:

In a brochureware application, Where all users are anonymous and all information is public, the impact will often be minimal.
In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

For a basic understanding for XSS (Cross-site scripting), I turned to PortSwigger Labs. Their hands-on exercises provided practical insights into the fundamentals of XSS, helping me grasp the essentials and learn about potential risks.

Login to your Academy account and check out the lab at https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded . You can find it in the “all labs” view or on the XSS page.

Challenge Information

Click “Access the Lab” and you’ll be directed to a temporary websites with a format like

https://<random string>.web-security-academy.net/

After accessing the temporary website, open it, and simultaneously launch Burp Suite, ensuring it’s turned on.

Here website

Capture the data in Burp Suite by Poxy

Once you’ve identified a request send it to bur repeater for further testing in this case we have a request that uses the search.

Send the request and note the location of the reflected input and the context in which the input is reflected as this affects the potential XSS vectors you can use to construct an attack.