Let’s get started with XSS, in order to get those critical bugs- CSRF, SSRF, RCE. Most of the time, an XSS flaw is the cause of a vulnerability that is exploited and escalated to a critical find.

First and foremost, the structure: we will start by learning about the basics of XSS, then: the thing you should know- How a browser & website function, later: types of XSS- understanding the impactful XSSs’, and lastly: XSS in Bug Hunting.

I know you know. But do you know, what you don’t know? XSS is a Cross-Site Scripting attack, a very basic one for a Security Tester. But still, no harm in re-reading(or skipping). Remember that- Learn, Unlearn & Re-learn. So, here it is.

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it — OWASP.

XSS holds the Seventh rank in OWASP Top 10(2017) A7:2017-Cross-Site Scripting (XSS). It’s not that, XSS is uncommon now, but the fact that other vulnerabilities have gained priority.

Also, automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET. — getting into White Box/Grey Box Testing.

In Simple Words: If you can control the JavaScript, on which a typical website functions. Then, XSS is a possibility.

Before diving in deep, it's important to get the basics right.

We know the world runs on some basic rules & principles, to save us from havoc. In a similar manner, the Internet does, & so, the browser and websites do.

Browser & Websites co-exist together on the basis of certain rules. Some rules, mentioned-below, that you should know of, to have a clear understanding of the security impact of a flaw:

1. Same-Origin Policy- SOP

The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors — Mozilla.

In Simple Words: The server defines the rules for a browser, in which Website1 can interact with a Website2.

2. Cross-Origin Resource Sharing- CORS

CORS is an HTTP-header based mechanism that allows a server to indicate any other origins (domain, scheme, or port) than its own from which a browser should permit loading of resources — Mozilla.

In Simple Words: CORS is the HTTP header, that server sends, to state a browser, which sites are in its friends list/allow list.

3. Cross-Site Request Forgery tokens- CSRF tokens

To prevent cross-origin writes, an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token is added. You must prevent cross-origin reads of pages that require CSRF token — Mozilla.

In Simple Words: CSRF Tokens are- a one-time use, non-predictable(random) and long (at least- 16 bytes /128 bits) token(value/key), generated by the server (not in control of the user) — given to a browser to perform a single task.

4. HTTP Cookie

An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with later requests to the same server. Typically, it’s used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol — Mozilla.

In Simple Words: Cookie is, generally, a replacement of your credentials (Username & Password) that a server sends back and forth to the browser to remind him of a particular session(HTTP-a Stateless protocol, that forgets who you are & what you want from him, after every request) and keep a track of the activities performed.

5. HTTPOnly -Set-Cookie

HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client-side script accessing the protected cookie. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can be sent to a hacker’s computer or Web site with the script. A cookie is set on the client with an HTTP response header.

In Simple Words: HTTPOnly attribute specifies that a cookie is not accessible through script, but only by an HTTP header.

Note: The use of the above individual technique is not enough, but, when used together, can mitigate the risk of cross-site scripting. Used alone, they cannot completely eliminate the danger of cross-site scripting.

There are several other rules that are used by a browser for safe-secure communication. But, here we are limiting the scope of the rules for an XSS.

Now, that we know what an XSS is and How a browser & website function, on the basis of certain rules. Let’s move further to types of XSS and important XSSs’ in Bug Hunting.

Types of XSS (generally):

1. Reflective XSS- your payload impacting you/logged-in user, *
2. Stored XSS- your payload-impacting other users’ *
3. DOM XSS- vulnerable document-object model*
4. Blind XSS- tricky to get the result of your injected payload*
5. Self XSS -out of scope in bug hunting(or low impact/informational)
6. Flash-based XSS -obsolete(flash is simply dead)

*(important in bug hunting — as can have severe impacts- CSRF, SSRF, RCE.)

We will be discussing the below XSS types, that are relevant from a Bug Hunting perspective:

1. Reflective XSS
2. Stored XSS
3. DOM XSS
4. Blind XSS

1. Reflected XSS Attacks

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable website, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

Reflected XSS Attacks often require social engineering tricks to deliver the impact.

2. Stored XSS

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Classic Example for a Stored XSS:

Samy (computer worm), that was designed to propagate across the social networking site MySpace by Samy Kamkar. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload making Samy the fastest-spreading virus of all time.

The worm itself was relatively harmless; it carried a payload that would display the string “but most of all, samy is my hero” on a victim’s MySpace profile page as well as send Samy a friend request. When a user viewed that profile page, the payload would then be replicated and planted on their own profile page continuing the distribution of the worm. MySpace has since secured its site against the vulnerability. Read More.

3. DOM XSS

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script. So that the client-side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client-side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed on the response page (due to a server-side flaw).

When looking for a DOM-Based XSS, keep an on DOM Objects like:

1. Source
2. Sink

Check if your input/payload can control the output.

Source — where your input goes to.

document.url
document.documentURI
document.URLUnencoded
document.baseURI
document.referrer
location
location.href
loaction.search
location.hash
location.pathname
window.cookie
window.referrer
window.name

Sink — where your input is reflected back.

element.innerHTML()
element.outerHTML()
eval()
setTimeout()
setInterval()
documemt.write()
document.writeln()

4. Blind XSS

Blind XSS vulnerabilities belong to persistent XSS vulnerabilities. These vulnerabilities arise when the attacker's injected payload is preserved by the web server and executed as a malicious script in another component of the application or in a totally different application.

For Example:

An attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application Here, it could be an internal application where the administrator reviews the access logs or the application exceptions.

Also, the above XSS kinds could be further categorized into two:

1. Server XSS
2. Client XSS

Server XSS occurs when untrusted user-supplied data is included in an HTTP response generated by the server. The source of this data could be from the request, or from a stored location. As such, you can have both Reflected Server XSS and Stored Server XSS.

In this case, the entire vulnerability is in server-side code, and the browser is simply rendering the response and executing any valid script embedded in it.

Client XSS occurs when untrusted user-supplied data is used to update the DOM with an unsafe JavaScript call. A JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. This source of this data could be from the DOM, or it could have been sent by the server (via an AJAX call, or a page load). The ultimate source of the data could have been from a request, or from a stored location on the client or the server. As such, you can have both Reflected Client XSS and Stored Client XSS.

DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the Server.

CheatSheets:

Now that, we have covered the Basics of XSS. We are ready to escalate the attack. Refer to the below cheat-sheets that could help to bypass common WAFs & Filters.