XYZ of XSS

Hello Ninjas! Today I am going to share everything(Almost Everything :P) that I know about Cross-site Scripting vulnerabilities. I would aim to clear all your doubts regarding this vulnerability.

So lets get started :)

Cross-site Scripting or simply XSS is a vulnerability that allows an attacker to execute malicious JavaScript on victim browser. XSS is a client-side injection vulnerability therefore it doesn’t directly affect the server but it targets the clients(users) of that web application.

So XSS is all about “WHERE AM I COMING FROM AND WHERE AM I GOING”

You’re thinking I am high on weed. Don’t you? Well it’s not the case.

WHERE AM I COMING → INJECTION POINTS

WHERE AM I GOING —> REFLECTION POINTS

INJECTION POINTS: The input field where you can inject something. Let’s take an example:

In the pic above you can see there two injection points 1.Path 2.Search Field.

Always remember: Path is also a potential injection point.

XSS may exist like this: https://vulnsite.com/”><script>alert(1)</script>

Now, If you hit on search then it will show you this:

We can see the search field is controlled by a parameter name “q” which means search and “q” are both the same Injection Point.

There are many injection points on a website many of them can be POST-Parameters that you’ll find by Burp-Crawling, Many of them are on authenticated endpoints that means in order to find them one must be logged in, then we have parameters in the urls that can be found via tools such as waybackurls, paramspider etc, then the path etc.

Now lets talk about REFLECTION POINTS:

The location in the response code where the Injection reflects back is called as Reflection Point.

We’ll understand 3 scenarios of reflection for XSS:

When the injected input reflects back between two opening and closing HTML tags then we can call it “Reflection between HTML Tags as Text”.

Here you can see I injected a word with special characters ><”’ in the keyword parameter and it got reflected at 5 places in the response.

In the screenshot you can see 3 out of those five reflections, 2 of them gone through url encoding before getting reflected on the page however one came as it is.

So in order to do XSS here we need > < ( ) “ or ‘ because we need to create our HTML tag and make a function to initiate XSS pop up.

also our injection is inside the title tag and we cannot execute JS up there inside the title so we need to come out and execute payload.

Hence final payload would be:

</title><script>alert(1)</script>

2. Reflection as HTML attribute value:

When the reflection is inside an attribute value inside an HTML Tag:

For example:

<input type=”text” id=”search_keyword” name=”keyword” value=”vflexo”’><” placeholder=”Search for Products, Category &amp; Brands”>

Fortunately this side did not encode/filter > < inside the reflection in HTML attribute value hence we can XSS it by adding payload “><script>alert(1)</script>

“> added before <script>alert(1)</script> is for getting out of the developer’s initial double quote and then > closes the input tag right there.

BUT BUT BUT……

But just for the sake of learning lets assume it did escape or encoded > < in response code.

Does that mean we can’t XSS here?

Hell Nooo!! We can :)

When the reflection is inside HTML attribute value between quotes we can use javascript event-handlers to trigger XSS using payload like this:

“onmouseover=alert(1);”

The initial “ in the payload is to balanced first double quote added by developer and then onmouseover=alert(1); event handler calling function is there and then the double quote in the end is to balance second double quote added by the developer.

When we add such payload in the injection and load the url.

It simply executes XSS when mouse is moved to the particular entity , here it was search field.( You can use other event handlers such as oninput, onclick etc the execution action would depend on what event-handler has been used)

3. Reflection inside the JavaScript:

Sometimes, the injection gets reflected inside the JavaScript i.e. between the opening and closing script tags just like this:

We can pass special characters ‘)(;// along with the input because that’s all we need here in this case for the XSS to work. After passing these special characters here I found the they all reflected back as it is without filtering/escaping/encoding.

So we can use these special characters without any hesitation.

Final payload for this test case would be ‘);alert(1);//

‘); to take us out of setcurrent function and close it.

alert(1); to add additional function in the JS code.

// to comment out the rest

The payload would perfectly fit inside the code:

When you load url with this payload it triggers XSS:

THAT’S ALL ! THIS IS HOW YOU CAN TEST XSS!

AND YEAH THE THIRD TEST CASE WAS ALSO A DOM BASED XSS :D

When I removed the payload from it, it was still giving me the POP-UP.

Because the payload got saved into the DOM, it is not persistent like Stored-XSS, once I closed the browser and opened again and opened the endpoint without payload, the XSS was gone.

That helps understanding how DOM-Based XSS is like :)

A FEW MORE IMPORTANT POINTS:

The stored XSS can be found on persistent data fields such as Username, Comment, Post, Description etc. And one can find Blind XSS on endpoints that are making the payload travel to some other related web application of the same organization. Such fields can be feedback form, User-Agent Header value, Address value for shopping, Product Review etc.

There is more I think I can share about tricks/tricks to craft payloads and WAF-Bypassing techniques but I guess that I will cover in my next blog post.

I hope you enjoyed reading.

Those who want to buy me a Coffee can DM me :P

Happy Hacking Fellas ✌️