INTRODUCTION
Cross-Site Scripting (XSS) attacks insert malicious scripts into websites that are otherwise reliable and benign. XSS attacks occur when an attacker transmits malicious code to a different end user utilizing an online application, generally in the form of a browser side script. These attacks are effective whenever a web application accepts user input without validating or encoding it before using it to make output.
An attacker can use XSS to send a harmful script to a careless user. The script will be executed by the end user's browser even if it shouldn't be trusted. Since it thinks the script is coming from a trustworthy source, the malicious script can access any cookies, session tokens, or other sensitive data kept by the browser and utilized with that site. These scripts have the power to totally alter the content of HTML pages.
Description
Cross-site scripting (XSS) attacks take place when:
1. Data enters an HTTP application from an untrusted source, typically a web request.
2. The data is presented to a web user as dynamic content that hasn't been malware-tested.
Types of XSS
Stored XSS
When an application obtains data from an unreliable source and includes that data inadvertently in later HTTP answers, stored XSS (also known as persistent or second-order XSS) occurs. The relevant data, such as comments on a blog post, user names in a chat room, or contact information on a client order, may be sent to the programme via HTTP requests. Other times, the information may come from unreliable sources, such as a webmail programme showing SMTP-received messages, a marketing programme showing social media updates, or a network monitoring programme showing packet data from network traffic.
Reflected XSS
The most basic type of cross-site scripting is reflected XSS. It occurs when an application receives data from an HTTP request and unsafely incorporates that data into the immediate response. The application doesn't further process the data, making it simple for an attacker to create an attack. If a user accesses the attacker-created URL, the attacker's script runs in the user's browser during that user's active application session. The script is then able to execute any operation and obtain any data that the user has access to.
DOM XSS
When client-side JavaScript in an application handles data from an untrusted source in an unsafe manner, typically by publishing the data back to the DOM, this is referred to as DOM-based XSS, also known as DOM XSS.
PROOF OF CONCEPT
By injecting a payload that forces your own browser to run some arbitrary JavaScript, you can verify the majority of XSS flaws. The alert() function has been used for this purpose for a long time since it is quick, secure, and difficult to overlook when called successfully. If the attacker has access to the input field's value, they can quickly create a malicious value that launches their own script.
Typically, a URL query string argument from the HTTP request would be used to populate the input field, allowing the attacker to deliver an attack using a malicious URL, similar to mirrored XSS.
TESTING FOR DOM XSS
STEP 1:
You must first launch the OWASP juice shop application, which is created for testing. As demonstrated in the following step, we use the search input form that is visible in the browser as a parameter.
STEP2:
The user's request is shown in the web browser's search area once the search request has been carried out. Additionally, we see that the search result is integrated into the website, as shown in the image up top.
STEP 3:
The sink and source elements of a request are essential to the idea of a DOM-based XSS. In the burpsuite chromium browser, we employ a tool called DOM invader to verify this. Some of the key sources that can result in DOM-XSS vulnerabilities include the following:document.write()
document.writeln()
document.domain
element.innerHTML
element.outerHTML
element.insertAdjacentHTML
element.onevent
As we can see, the component. The page is vulnerable to a DOM-based XSS because of the innerHTML sink element.
STEP 4:
Now let us try searching for <iframe src="javascript:alert(`XSS`)"> which is a javascript payload made for alerting. Alerts are used to check for XSS because they assist in visually validating the vulnerability by displaying the entered script visually.
The HTML <iframe src> attribute is used to specify the URL of the document that are embedded to the <iframe> element.
STEP 5:
The aforementioned image shows that we were successful in getting an XSS warning, which visually verifies that the website is open to reflected XSS attacks.
TESTING FOR REFLECTED XSS
STEP 1
Make sure you register, add some things to your cart, and then place an order by supplying an address and payment information that the transaction page accepts. Check your order details after placing it.
STEP 2
Go to Account->Order and Payments->track orders after placing your order. You will be taken to the aforementioned page. To track your order, click the truck icon here.
STEP 3
Once the order is tracked, you are given an item id, which is displayed in the search bar. We will attempt to insert malicious java script into the id argument since it does not appear to be validated.
STEP 4
We us the <iframe src="javascript:alert(`XSS`)"> script in the id parameter. The fact that it is susceptible to a reflected XSS attack is revealed by a successful hit on the reflected XSS pop up on our main screen.
TESTING FOR STORED XSS
STEP 1
We proceed to the last login IP page, which can be determined by looking at the image above, to test stored XSS. The IP of the most recent logged-in device is displayed on the page as is.
STEP 2
We intercept the request via the burp suite proxy and then look at the request headers. The request is then sent to the repeater, where it can be modified to meet our needs and sent again for a successful hit on the cached XSS.
STEP 3
Once directed to the repeater we create our own header called True-Client-IP and allocate the value of <iframe src="javascript:alert(`XSS`)">. After sending the request, we log out of the portal and then log back in to see if the XSS payload runs.
STEP 4
As we can see, the payload is successfully hit in this instance. Additionally, the request header permanently stores this header. As a result, the script runs the same amount of times no matter how many times a person registers into this site.
Comments