INTRODUCTION

Malicious scripts are injected into otherwise trustworthy and innocent websites in Cross-Site Scripting (XSS) attacks. XSS attacks take place when an attacker sends malicious code, typically in the form of a browser side script, to a separate end user using an online application. These attacks can be successfully conducted everywhere a web application incorporates user input without verifying or encoding it into the output it produces.

A malicious script can be sent to an unwary user by an attacker using XSS. The end user's browser will run the script regardless of the fact that it shouldn't be trusted. The malicious script is able to access any cookies, session tokens, or other sensitive data stored by the browser and used with that site since it believes the script is from a reliable source. These scripts have the ability to completely change HTML page content.

Description

Attacks using cross-site scripting (XSS) happen when:

1. An untrusted source, usually a web request, is how data enters a Web application.
2. The information is given to a web user as dynamic content that hasn't been checked for as a malicious JavaScript.

Types of XSS

Stored XSS

Attacks known as "stored" occur when the injected script is kept on the target servers indefinitely, such as in a database, message board, visitor log, comment field, etc. When the victim makes a request for the stored data, the server then returns the malicious script to the victim. Persistent or Type-I XSS is another name for stored XSS.

Reflected XSS

A response that includes some or all of the data that was supplied to the server as part of the request—such as an error message, a search result, or any other response—is said to have been injected script. Reflected attacks are sent to targets through a different channel, like an email message or another website. A vulnerable website receives the injected code when a user is duped into clicking on a malicious link, completing a specially constructed form, or even merely navigating to a rogue site. The vulnerable website then reflects the attack back to the user's browser. As a result of the code coming from a "trusted" server, the browser then runs it. Non-Persistent or Type-II XSS is another name for reflected XSS.

DOM XSS

The term "DOM Based XSS" (also known as "type-0 XSS" in some texts) refers to an XSS attack in which the attack payload is executed after the victim's browser's DOM "environment," which was previously used by the original client-side script, has been altered to cause the client-side code to behave in an "unexpected" way. As a result of the malicious modifications that have been made to the DOM environment, the client-side code contained in the page executes differently even though the page itself (the HTTP response) remains the same.

PRACTICAL EXAMPLE FOR DOM XSS

STEP 1:

You must first launch the OWASP juice shop application, which is created as a safe environment to carry out XSS attacks. We use the search input field which is displayed in the browser as a parameter as shown in the next step.

STEP2:

Once the search request is executed, we can see the request of the user displayed in the search field of the web browser as displayed. We also notice that the search result is embedded in the web page which is highlighted in the above image.

STEP 3:

The concept of a DOM based XSS relies on the sink and source elements of a request. To check this we use a tool called DOM Invader in the burp suite chromium browser. The following are some of the main sinks that can lead to DOM-XSS vulnerabilities:

document.write()
document.writeln()
document.domain
element.innerHTML
element.outerHTML
element.insertAdjacentHTML
element.onevent

As we can observe the element.innerHTML sink element is what makes the page vulnerable to a DOM based XSS.

STEP 4:

Now let us try searching for <iframe src="javascript:alert(`XSS`)"> which is a particular javascript payload used for alerting. Alerts are used in to check for XSS as they help in visually confirming the vulnerability by showing a visual display of the script entered.

The HTML <iframe src> attribute is used to specify the URL of the document that are embedded to the <iframe> element.

STEP 5:

As we can see in the above image, we successfully obtained an alert stating XSS which visually confirms that the website is vulnerable to a reflected XSS attack.

PRACTICAL EXAMPLE FOR REFLECTED XSS

STEP 1

Make sure you create an account and add some items to your cart and place an order by providing an address and card details accepted by the transaction page. Once completing the order check your order details.

STEP 2

Once you've placed your order, go to Account->Order and Payments-> track orders. You will be directed to the page above. Here click on the truck symbol to track your order.

STEP 3

Once you track the order you obtain an item id as shown in the search box. The id parameter does not seem to be validated and we shall try to inject a malicious JavaScript payload into the parameter.

STEP 4

We us the <iframe src="javascript:alert(`XSS`)"> script in the id parameter and we get a successful hit on the reflected XSS pop up on our main screen indicating it is vulnerable to a reflected XSS attack.

PRACTICAL EXAMPLE FOR STORED XSS

STEP 1

For testing stored XSS we head to the last login IP page which can be found by referring to the picture above. The page as shown displays the IP of the last logged in device.

STEP 2

We use the burp suite proxy to intercept the request and proceed to view the request headers. We then send the request to the repeater where we can resend the request by modifying it with our requirements to get a successful hit on stored XSS.

STEP 3

Once sent to the repeater we create our own header called True-Client-IP and assign the value of <iframe src="javascript:alert(`XSS`)">. We then logout of the portal and login again after sending the request to check if the XSS payload executes.

STEP 4

As we can see here the payload gets a successful hit. This header is also stored indefinitely in the request header. Therefore, if a user logs into this site even after n number of times the script executes the same number of times.