Cross-Site Scripting Exploitation

“Are you one of them, who thinks that Cross-Site Scripting is just for some errors or pop-ups on the screen?” Yes?? Then today in this article, you’ll see how an XSS suffering web-page is not only responsible for the defacement of the web-application but also, it could disrupt a visitor’s privacy by sharing the login credentials or his authenticated cookies to an attacker without his/her concern.

I recommend, to revisit our previous article for better understanding, before going deeper with the attack scenarios implemented in this section.

Table of Content

  • Introduction to Cross-Site Scripting
  • XSS Post Exploitation
    • XSS through File Upload
    • Reverse Shell with XSS
    • Session Hijacking with Burp Collaborator
    • Credential Capturing with Burp Collaborator

Introduction to Cross-Site Scripting

Cross-Site Scripting is a client-side code injection attack where malicious scripts are injected into trusted websites.

In this attack, the users are not directly targeted through a payload, although the attacker shoots the XSS vulnerability by inserting a malicious script into a web page that appears to be a genuine part of the website. So, when any user visits that website, the XSS suffering web-page will deliver the malicious JavaScript code directly over to his browser without his knowledge.

 “XSS” thus has been classified into three main categories:

  • Stored XSS
  • Reflected XSS
  • DOM-based XSS

I guess you’re now having a clear vision about -“What is XSS” and “How it occurs”. So let’s try to exploit the vulnerable labs over The Portswigger Academy and bWAPP in order to capture up the authenticated cookie of the users and the server’s remote shell.

But before making our hands wet with the exploits, let’s understand what is Blind XSS?

Blind XSS

Many times the attacker does not know where the payload will end up and if, or when, it will get executed and even there are times when the injected payload is executed in a different environment i.e. either by the administrator or by someone else.

So, in order to exploit such vulnerabilities – He blindly deploys up the series of malicious payloads over onto the web-applications, and thus the application stores them into the database. Thereby, he thus waits, until the user pulls the payload out from the database and renders it up into his/her browser.

Let’s Start !!

XSS through File Upload

Web-applications somewhere or the other allow its users to upload a file, whether its an image, a resume, a song, or anything specific. And with every upload, the name reflects back on the screen as it was called from the HTML code.

As the name appears back, therefore we can now execute any JavaScript code by simply manipulating up the file name with any XSS payload.

Boot back into the bWAPP’s application by selecting the “Choose your bug” option to “Unrestricted File Upload” and for this time we’ll keep the security to “High”.

Let’s now upload our renamed file over into the web-application, by browsing it from the directory.

Great !! Form the above image, you can see that our file name is over on the screen. So as we hit the Upload button, the browser will execute up the embedded JavaScript code and we’ll get the response.

Reverse Shell with XSS

Generating a pop-up or redirecting a user to some different application with the XSS vulnerability is somewhere or the other seems to be harmless. But what, if the attacker is able to capture up a reverse shell, will It still be harmless? Let’s see how we could do this.

Fire up your Kali terminal and then create up a reverse-php payload by calling it from webshells  directory as

Now, in order to capture the remote shell, let’s manipulate the $ip parameter with the Kali machine’s IP

Back into the vulnerable application, let’s opt the “Unrestricted File Upload” and then further we’ll include the ReverseXSS.php file.

Don’t forget to copy the Uploaded URL, i.e. right-click on the Upload button and choose the Copy Link Location.

Great!! We’re almost done, time to inject our XSS payload. Now, with the “Choose you bug” option, opt the XSS – Stored (Blog).

Over into the comment section, type your JavaScript payload with the “File-Upload URL”.

But wait!! Before firing the submit button, let’s start our Netcat listener

nc –lvp 1234

Cool !! From the below image, you can see that, we are into our targeted web-server.

I’m sure you might be wondering – Why I made a round trip in order to capture up the Reverse Shell when I’m having the “File Upload” vulnerability open?

Okay!! So, think for a situation, if you upload the file directly and you’ve successfully grabbed up the Reverse shell. But wait!! Over in the victim’s network, your IP is disclosed and you’re almost caught or what if your Ip address is not whitelisted. Then?

Over in such a situation, taking the round trip is the most preferable option, as you’ll get the reverse connection into the victim’s server through the authorized user.

Session Hijacking with Burp Collaborator Client

As in our previous article, we were stealing cookies, but, impersonating as an authenticated user, where we’ve kept our netcat listener “ON” and on the other side we logged in as a genuine user.

But in the real-life scenarios, things don’t work this way, there are times when we could face blind XSS i.e. we won’t know when our payload will get executed.

Thus in order to exploit this Blind XSS vulnerability, let’s check out one of the best burpsuite’s plugins i.e. the “Burp Collaborator Client”

Don’t know what is Burp Collaborator? Follow up with this section, and I’m sure you’ll get the basic knowledge about it.

Login into the PortSwigger academy and drop down till Cross-Site Scripting and further get into its “Exploiting cross-site scripting vulnerabilities”, choose the first lab as “Exploiting cross-site scripting to steal cookies” and hit “Access the lab” button.

Here you’ll now be redirected to blog. As to go further, I’ve opened a post there and checked out for its content.

While scrolling down, over at the bottom, I found a comment section, which seems to have multiple inputs fields, i.e. there is a chance that we could have an XSS vulnerability exists.

Now its time to bring “Burp Collaborator Client” in the picture. Tune in your “Burpsuite” and there on the left-hand side click on “Burp”, further then opt the “Burp Collaborator Client”.

Over into the Collaborator Client window, at the “Generate Collaborator payloads” section, hit the Copy to clipboard button which will thus copy a payload for you.

Cool!! Now, come back to the “Comment Section” into the blog, enter the following script with your Burp Collaborator payload:

Great!! From the below image, you can see that our comment has been posted successfully.

Time to wait!! Click on the Poll button in order to grab up the payload-interaction result.

Oops!! We got a long list, select the HTTP one and check its “Response”. From the below image you can see that in the response section we’ve got a “Session Id”. Copy it for now !!

Now, back into the browser, configure your proxy and over in the burpsuite turn you Intercept “ON”.

Reload the page and check the intercepted Request.

Great!! We’re having a Session ID here too, simply manipulate it up with the one we copied earlier from the collaborator.

Hit the Forward button, and check what the web-application offers you.

Credential Capturing with Burp Collaborator

Why capture up the session cookies, if you could get the username & passwords directly??

Similar to the above section, it’s not necessary, that our payload will execute over at the same place, where it was injected.

Let’s try to capture some credentials over as in some real-life situation, where the web-page is suffering from the Stored XSS vulnerability.

Back into the PortSwigger account choose the next defacement as “Exploiting cross-site scripting to capture passwords”.

As we hit “Access The Lab”, we’ll get redirected to the XSS suffering web-page. To enhance more, I’ve again opened up a blog-post there.

Scrolling the page again, I got encountered with the same “comment section.” Let’s exploit it out again.

Back into the “Burp Collaborator”, let’s Copy the payload again by hitting “Copy to Clipboard”.

All we need was that payload only, now inject the comment field with the following XSS payload.

Let’s hit the “Post Comment” in order to check whether it is working or not. The below image clears up that our comment has been posted successfully.

Now let’s wait over into the “burp Collaborator” for the results. From the below image you can see that our payload has been executed at some point.

Let’s check who did that.

Oops!! It’s the administrator, we’re having some credentials.

But where we could use them?

Over at the top of the blog, there was an account login section, let’s check it there.

Cool!! Let’s try to make a dry run over here. Tune in your proxy and capture up the ongoing HTTP Request.

Okay !! Let’s manipulate the username and password with the one we captured earlier in the Burp Collaborator.

Great!! Now simply hit the Forward button and there you go….

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contachere