Concept of XSS

Cross-site scripting is also known as XSS where X stands for CROSS and SS stands for SITE SCRIPTING (just our assumption). It is an injection-based attack where the attacker submits a malicious code that is accepted by the server and has the ability to harm the company’s infrastructure or leak the PII (Personal identification information) of their users.

XSS is the most common type of vulnerability. It is always placed in OWASP's top 10. Using popular and modern frameworks while developing the website might reduce the risk of cross-site scripting but it won't eradicate the risk completely. So, XSS will always be there no matter what.

XSS can be found where the user input is required; in the Web application like username, address, and profile field or even in an image file name uploaded to the server.

TYPES OF XSS:

There are mainly three types of XSS:

• Reflected XSS
• Stored XSS
• DOM XSS

Reflected XSS

Reflected XSS arises when the malicious code supplied by the attacker is immediately shown in the response of the site. An attacker could only exploit the Reflected XSS by tricking the user into opening the vulnerable page in a website and then the attacker can gain the session cookies, impersonate the user and gain full access to their account, which can also virtually deface the website.

Reflected XSS arises when the user input is sanitized properly and then executed by the server.

For Example:

There is an online shopping portal that has a search functionality and its URL for the search term KNOWLEDGE will be

https://vulnerable-website.com/search?term=knowledge

and when the attacker searches for a JavaScript code instead of the item he wishes the URL will be like

https://vulnerable-website.com/search?term=<script>alert(1)</script>

Reflected XSS Example

Here, JavaScript treats the malicious code injected by the attacker as a legit one coming from the source and executes the code, resulting in a pop-up alert box.

An attacker could only exploit this vulnerability by tricking the user into opening the link. It can be done by placing the unsafe links in an attacker-controlled website or sending them through messages or emails.

Ways to find reflected XSS:

• Find every parameter on the website.
• Try injecting the simple payloads like <script>alert(1)</script>.
• Monitor the website carefully if the website is accepting the code and you see a pop-up. Congrats you have found an XSS and if it doesn’t know what is stopping it from being fired, ask yourself whether it is the firewall or the sanitization or use BurpSuite to check and play around.
• If the website doesn’t allow some characters like “, >, <, /, or tags like a script. Try their alternatives or try encoding them, who knows the developer might allow encoding to process.
• Try different payloads and know which characters are allowed and which are blocked. This will give you a lot of insight into the working of web applications.

STORED XSS

As you might have guessed by name the stored XSS, is a type of XSS where the malicious code supplied by the attacker is stored in the server and would execute whenever the user visits the page. It is also referred to as a persistent XSS.

Generally, this type of XSS can be found in the comments section or post section of a website where the user input is stored in the server. Sometimes, XSS can even be stored in the username of a user or even as their profile display, and whoever visits the profile of the user the payload will fire.

Blind Cross-site Scripting is a form of persistent XSS. It generally occurs when the attacker’s payload is saved on the server and reflected back to the victim from the backend application. For example in feedback forms, an attacker can submit the malicious payload using the form, and once the backend user/admin of the application will open the attacker’s submitted form via the backend application, the attacker’s payload will get executed. Blind Cross-site Scripting is hard to confirm in a real-world scenario but one of the best tools for this is XSS Hunter.

DOM-Based XSS

This type of XSS occurs when the javascript supplied by the user is taken into the sources and given back by the sinks.

This is one of the hardest types of XSS to find.

If the web application is using any of the below-mentioned functions. In its JavaScript code and within that function if there is a call to a variable then we could inject our own javascript code into it.

document.url
document.referrer()
location()
location.href()
location.search()
location.hash()
location.pathname()
sinks:
element.innerHTML()
element.outerHTML()
setinterval()
eval()
setTimeout(
document.write( document.writeln()

If the JavaScript code we supplied passes through any of the sources which get executed in the sinks then we will have our XSS pop-up.

Let's see an example

DOM Based Example

Here we could see that there is a source location.href(“”) which has a variable of # if we could inject our payload into the #. It would get executed in the third line divElement.innerHTML = source; //sink and we would get our XSS popped up.

POLYGLOT: The King Payload

An XSS Polyglot is a mixture of different injections and payloads. These are generally made by bug hunters having a lot of experience. 

These Polyglots are used to break the HTML and all the blacklists and whitelists which are placed to prevent the popping of alert boxes.

Some of examples XSS polyglots are:

CHECK HUNTER'S VIEWS ON XSS EXPLOIT

We hope this helps. If any suggestions or doubts you can add a comment and we will reply as soon as possible.