XSS also Known as Cross-Site Scripting is a vulnerability that allows attackers to execute arbitrary javascript code on a victim’s browser.

When a web application accepts the untrusted user data without sanitizing, an attacker could inject malicious data that could lead to executing arbitrary client-side code at victims browser and control the behavior of the browser, It can be used for phishing, exfiltrating data, account takeovers, and more.

One of the most famous examples of an XSS vulnerability was the Myspace Samy Worm created by Samy Kamkar. Samy found an XSS vulnerability on Myspace and exploited it which allowed him to store a JavaScript payload on his profile. and when a logged-in user visited Samy’s profile, the payload will then execute, making the viewer Samy’s friend on Myspace, and updating the viewer’s profile to display the text, “but most of all, samy is my hero”. Then, the code would copy itself to the viewer’s profile and continue infecting other Myspace user pages.

Although Samy’s worm is an extreme example, his exploit shows the broad impact an XSS vulnerability could have on a website. XSS vulnerabilities occur when websites render certain characters unsanitized, which causes browsers to execute unintended JavaScript. These characters include double quotes (“), single quotes (‘), and angle brackets (< >). They are special because they are used in HTML and JavaScript to define a web page’s structure. For example, if a site didn’t sanitize angle brackets, you could insert them.

1
2
3

<script>alert(document.domain)</script>

When this payload is submitted to a website and rendered unsanitized, script tag instructs the browser to execute the JavaScript between them.

In this case, the payload would execute the alert function, which creates a popup dialog that displays the information passed to the alert. The reference to document inside the parentheses is the DOM and, in this case, will return the domain name of the site. If the payload is executed on https://www.sahilsinghrawat.in, the popup box would display www.sahilsinghrawat.in Click on the button below to get that popup

button

However, If the web application was properly sanitizing these characters, they would be rendered as HTML entities. Viewing the page source for a webpage with them would show: “ as " or ", ‘ as ' or &39;, < as < or < and > as > or >.

How Does it Works?

The Vulnerability is within any input field where the user can enter the text and that data is accepted by the application without sanitizing it, Now the attacker can enter a malicious script in the text box, Then whenever the web page will render that input it will get executed because the data was a javascript code and browser will execute any JS code wrapped within script tag

The Flow of XSS attacks is as follows

• Attacker Founds an XSS vulnerability in the web application
• Attacker inserts a malicious script(payload) Into Victims Browser
• When the Victim’s browser encounters the script it executes in the victim’s browser
• A malicious payload can perform any action that the victim can perform
• If the victim has special privileges it could be a serious vulnerability

Again Finding an XSS will not always be as simple we might need try to fuzz the input to get our code executed.

Impact

The Impact of XSS varies on various factors whether we require user privileges, depending on the data stored on the website, type of cookies on the website, etc. With an XSS vulnerability attacker could.

• Read/Modify/Delete Content of any page
• Steal a user’s cookies or sessions and gain access to their account
• serve malicious content like phishing

The impact of a reflected XSS is around medium and the impact of a stored XSS could go up to high

Types Of XSS 🔎

The most common type of XSS attack are Reflected and Stored XSS attack.

Reflected XSS

In case of a reflected XSS, the payload is injected from the victim’s request, i.e to execute a code victim needs to make a specific request which contains the payload to be executed, for this the victim must click a link, or navigate to an attacker-controlled property. The payload could be within the address of the link,

It occurs when the XSS payload is delivered and executed via a single HTTP request and is not stored anywhere on the site. Since it’s not stored, it’s not possible to execute the payload without sending another HTTP request with the payload. However, browsers (Chrome, Internet Explorer, Edge, and Safari) have attempted to prevent this type of vulnerability by introducing XSS Auditors. This is built-in functionality browsers have which attempt to protect users from malicious links which execute JavaScript. When this occurs, the browser will typically show a broken page with a message stating the page has been blocked to protect users.

Despite the best efforts of browser developers, XSS Auditors are frequently bypassed because of the complex ways in which JavaScript can be executed on a site.

1

Ex: http://example.com/?search=<script>alert("PAYLOAD")</script>

Here the injection is via the search parameter thus, the victim needs to click this link to execute this payload,

We can check for XSS by following:

Here the Last request is an example of HTML injection where we could inject HTML tags and they will then be rendered on the web app it suggests that there might be a chance of XSS vulnerability, But it is not necessary that if there is an HTML injection so there will be XSS attack.

Stored XSS

In this case, the payload is stored at the server-side, any time a user visits a particular page or opens a comment, the payload gets executed, This type of payload gets triggered with no interaction outside the application.

Ex → Payload in a username or address of a user, or comment on any post, or Payload was inserted at dropbox as the filename and later imported on shared via Facebook, etc.

It is also known as persistent XSS, It stores the payload into the database, The payload is then reflected when visiting a particular page. Suppose a Username field on a website is vulnerable to XSS, and then the attacker injects a malicious payload, now any time a user will open a page on a web application where the attacker Username needs to be rendered for example attacker’s user profile or any post or comment made by the attacker, then the payload would be executed.

When looking for stored XSS, it’s important to note that sites may render the same inputted payload in various locations. and it might happen that the payload may not execute immediately after submitting it but might execute when another page is accessed. For example, if you created a profile on a website with an XSS payload as your name, the XSS may not execute when you view your profile but might when someone searched for your name or someone sent you a message.

This type of XSS is more impactful just because, we don’t need any kind of user interaction, like in the case of reflected, Here simply inject a payload and wait for any victim to open the web application.

XSS can be further broken down into three subtypes DOM, Self and Blind XSS,

DOM Based

DOM Based XSS is in the client-side code versus the server-side code, however, the payload is injected via the user’s request This is usually when javascript reflects data from attacker-controlled resource and passes it to a function later. It is a result of manipulating a website’s existing JavaScript code to execute malicious JavaScript and can be either Stored or Reflected.

For example, if a website uses the following method to render contents of its website with a value from the URL without sanitizing it, it might be possible to execute XSS:

1
2
3
4
5
6
7
8
9

<html>
   <body>
      <h1>Hello, <span id="name"></span> !</h1> 
      <script>
         document.getElementById('name').innerHTML=location.hash.split('#')[1]
      </script> 
    </body>
</html>

Here, the script tag is simply taking the value after the “#” in the URL and replacing it inside the span tag in HTML. If a user visits this page by going to www.example.com/#sahil would result in the page’s HTML dynamically being updated to <h1>Hi Sahil. However, since this page doesn’t sanitize the # value in the URL before updating the span element if a malicious user visits the link:

www.example.com/#<img src=x onerror=alert(document.domain)>,

an alert would pop up with www.example.com, as the resulting HTML will become.

1
2
3
4
5
6
7
8

<html>
   <body>
      <h1>Hello, <span id="name"><img src=x onerror=alert(document.domain)></span> !</h1> 
      <script>
         document.getElementById('name').innerHTML=location.hash.split('#')[1]
      </script> 
    </body>
</html>

Self XSS

As the name suggests self XSS usually only impacts the user entering the payload, for example, It may occur when there is a vulnerability when a POST request with payload is made, however, due to the CSRF token only the attacker himself can submit the request. Here as an attacker could only attack themselves, this type of XSS is usually considered lower severity.

Blind XSS

Blind XSS is a type of a stored XSS but the XSS payload is rendered at a location that a user/attacker can’t access on that website.

For example, suppose a first name, username, or email field is vulnerable to stored XSS on a website and the attacker adds an XSS payload at that field, now this may happen that when a regular user views that profile then the field is properly escaped, however when an admin view that from an admin panel, the XSS might get executed.

There is a very famous tool called XSSHunter which is very great in detecting these vulnerabilities. what it does is it loads a remote js file that reads the DOM, Browser info, and cookies, and then this data is sent back to the attacker’s XSSHunter account, thus as we get the request with the data it could act as a poc for blind XSS.

Tips

→ One tip is to put up an HTML tag first in the input, then try to look where the text ends up

→ Look for every single occurrence of the input and then try to exploit one of those places

→ One Important thing with XSS is to understand the context, Where our input is getting reflected within an HTML tag, or js variable, etc.

→ Then try to escape out of those contexts like if in HTML tag try to input a closing HTML tag, or if in a variable try to escape out by entering a single or double quote.

→ Using XSS we can steal cookies, change email id, change passwords, steal CSRF tokens, for stealing cookies and session we need to copy-paste the same cookie or session id in your browser to overtake the session, this will not work every time because of other security measures in place, but there is always a possibility of it

Thanks for Reading, Stay tuned for more ❤︎

If you enjoyed reading the article do follow me on:

Twitter

LinkedIn

Website

GitHub