Hey guys. Welcome to the new post from ENCIPHERS. As we think, you must be knowing that Cross Site Scripting is the most prevalent vulnerability present in any web application even now. We have discussed the basics of XSS in this post. Take a look at that if you are a beginner, else continue with this one. Now there are many ways to exploit XSS. Now by the exploit, we don’t mean different payloads, that is one aspect of it, but we mean that you can find XSS at different places on a website. So let’s get started with it.

EXAMPLE 1: XSS in form input fields

Now, this is the place where we all start looking for XSS at the first sight. If we see any input field, we just try to put different payloads and see how the application responses to it.
Let’s see an example from Webgoat. If you see the problem for Stored XSS attack, there are two input fields, one for Title and other for the message.
We have put the payload

<script>alert('hello')</script>

in both of them. That’s how we usually do, insert payloads in all the input fields. And we got the popup as in below screenshot.

This was the most basic payload which won’t work always. So make sure to check our other post here and also see this awesome page from OWASP for further details on how to use different payloads when different filters are in place. So this was the simplest example to find XSS in a normal form input field.

EXAMPLE 2: XSS via image upload

Nowadays, many web applications ask users to upload an image. It can be the profile picture, any banner or logo for your company or any cover pic. Just think of any input method which allows you to upload a pic either from your computer or from Cloud.

Now trick to get the XSS, use XSS payload as the filename. For example, change the filename of the image you are uploading to,

"><img src=x onerror=alert(1)>.png

and you will get the XSS triggered.

Many times server even doesn’t check if the uploaded image is the correct extension like png or jpg. In this case, you can upload any file, just remember to give the XSS payload as the filename.

If you see that it isn’t working then URL encode the payload,

%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E.png

and try it.

Now, what should you do, if the server is checking the extension of the image and also checking the file? There is one way out of this by changing the content-type. We will look at that later in example 4.

EXAMPLE 3: XSS while importing Contacts or Tasks

If you come across situations, where you are getting a chance to import anything whether it be contacts, your files, your tasks or anything like that, try the same thing as in Example 2.

Just create a file and write anything inside it but give the XSS vector as the filename. If the server is checking the extension, like in the screenshot, it’s asking to only upload a CSV or vCard file, then upload the file with same extensions like .csv or .vcf.

"><img src=x onerror=alert(1)>.csv

It will work in many cases. If it says to Import from your Drive account or any account, just do the same thing i.e. save the filename as the XSS vector there and then import.
If it says that the file is not valid, then create a legal CSV or VCF file but give the XSS payload as the filename.

EXAMPLE 4: Triggering XSS by changing the Content-Type when the server isn’t checking the content

As we discussed in Example 2, there may be cases when just saving the filename as an XSS vector won’t trigger an XSS. In this case, you need to check another thing i.e changing the MIME Content-Type of a file.
For this, you will need a proxy interceptor such as BurpSuite. Let’s suppose there is an image upload functionality. The valid MIME’s for these should have been image/png or image/jpg. To check for this,
Create a normal HTML file with javascript’s alert function inside it. But give the filename with the proper extension of jpg or png like uploadPic.jpg.

Now intercept the request using Burpsuite, it will be something like this when you intercept the request:
HTTP request

POST /profile/image_icon/upload/ HTTP/1.0
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Length: 389
Cookie: [Cookie values]
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Disposition: form-data; name="image_upload"; filename="uploadPic.jpg"
Content-Type: image/jpg

Now change the filename to uploadPic.html and the content-type as text/html as shown below.

POST /profile/image_icon/upload/ HTTP/1.0
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Length: 389
Cookie: [Cookie values]
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Disposition: form-data; name="image_upload"; filename="uploadPic.html"
Content-Type: text/html

If the server isn’t checking the content of the file, XSS will be triggered.
This can also be used in Example 3 scenarios. You can also use it as a file upload vulnerability and try to upload a php file or so.

EXAMPLE 5: XSS via improperly implemented Markdown parsers

If you don’t know how Markdown works, see this page here. It is generally used in Forums or if you have reported any bugs via HackerOne you must have seen them. Now if the Markdown parser hasn’t been properly implemented, there might be several vulnerabilities which you can find.
Let’s take a specific example of creating a user-clickable link via Markdown. Its syntax is like this:
‍

[text to show on the page](link to go)

As an example let’s take:

[Go to this page](https://enciphers.com).

‍
After parsing it converts to,
Go to this page.
Now if you get where it’s going, instead of the link, you can put an XSS payload there like:
‍

[You have been hacked](javascript:alert(1);)

‍
It will trigger the XSS.
As we said, if the Markdown parser hasn’t been properly implemented then only this will happen. So you can try this when you find that Markdown is being used. Now since Markdown is generally used in Forums, it can also lead to Stored XSS which will be much more severe than the Reflected one.

So this was all for this post. We have discussed several tricks of finding XSS. These examples are the compilation of different reports disclosed and different posts and books we have gone through and these will definitely come in handy while looking for XSS in a web application. You can also make appropriate changes according to your needs in the examples. Now, these methods will give you more places to look for XSS vulnerabilities.
If you think there are any better methods you would like u to add to this post, please comment below and after reviewing we will definitely add it to this post. As for now, Keep Learning and Happy Hacking.:)

‍