Hi, I'm Saif Eldin. a security researcher and bug bounty hunter who enjoys finding real-world vulnerabilities.

About The Target

The Target is a social intranet platform used by modern enterprises to build their digital workplaces. It serves as a central hub for employees to collaborate, share knowledge, and integrate essential productivity tools.

While auditing the Target platform, I discovered a critical security vulnerability chain that allows an attacker to completely take over any organization on the platform. By combining a Broken Access Control flaw in the Page Groups feature with a Stored XSS, I was able to bypass CSRF protections and takeover any Organization on the platform.

Without much talk, let's begin.

The "Universal" Entry Point

Target allows users to create Page Groups, collections of pages where owners can collaborate with others by assigning them roles like Editor or Viewer. You should only be able to add users from your own organization.

However, while testing the logic of adding users to the page group, I noticed that the system relies on the user's internal ID to give access to the Page Group, and these IDs were sequential (e.g., 1, 2, 3…).

A thought crossed my mind: What if I add a User ID that belongs to a completely different organization?

I intercepted the request and replaced the ID with a random one

To my surprise, it worked. The system accepted any User ID and immediately granted that user access to my page group, regardless of their organization. There was no validation to check if the user was actually a member of my org.

This was a Broken Access Control issue. I kept it in my mind and continued my testing.

The XSS Discovery

Next, I moved on to testing the page editor functionality. While intercepting the request responsible for updating page content, I observed several parameters. This raised the question of whether any of them could be vulnerable to XSS. I began testing them one by one and eventually identified a parameter named placeholderTextwithin the widget configuration, which I then tested by injecting a simple XSS payload.

I saved the request and refreshed the page. Immediately, the alert popped up.

This was a Stored XSS vulnerability. Any user who viewed this page would have JavaScript execute in their browser.

Leveraging Stored XSS to Bypass CSRF

By now, I had found the XSS bug. But I kept thinking: How can I make this really dangerous?

I didn't want just a simple alert; I wanted full control.

Hmm, let's take a look at how the platform authenticates requests and see whether it's possible to steal the session.

The target platform uses two authentication mechanisms:

1. unvrsession: The session cookie.
2. xsrftoken: A CSRF token sent in both the cookie and the X-Csrf-Token header.

I tried to steal the session using:

alert(document.cookie)

Unfortunately, the unvrsession was protected with the HttpOnly flag and didn't show up. However, the xsrftoken was fully visible.

An idea struck me: Since I could steal the xsrftoken, I could bypass CSRF protections. I could combine the Stored XSS (to steal the token) with a CSRF (to perform privileged actions) using the stolen token. I tested it, and it worked perfectly.

Connecting The Dots

However, this attack would only impact the organization I belonged to, and that wasn't enough. I was aiming for the highest possible impact.

I started thinking……. how could I leverage this to attack other organizations as well?

The answer didn't come while I was staring at my screen. I was actually away from my laptop when the idea hit me. I suddenly remembered the first bug I found, the one where I could add anyone to my Page Group using their ID.

At that moment, everything clicked.

I realized I could mix these three bugs together:

1. The BAC Issue: To get people into my Page Group.
2. The XSS: To run hidden code on their browser.
3. The CSRF: To use their own account to perform the action.

The plan was simple but powerful:

I would add random people to my group, then use a payload that would invite me as an Admin to their organization.

I rushed to my laptop, opened my tools, and started testing right away. My goal was clear: invite myself as an Admin to the victim's organization.

First, I found the invite endpoint It was vulnerable to the CSRF bypass using the stolen token:

POST /api/app/organisations/{org_id}/invites
{"email":"0xs3fo@gmail.com","asAdmin":true}

But there was a problem. I didn't know the {org_id} of the victim. I couldn't hardcode it because I wanted to attack any organization.

So, I started searching for an API endpoint that might return the Org ID. I found this in my Burp history:

GET /api/apps/user

Response: {"userId": 123, "organisationId": 999, ...}

This endpoint returned the user's profile, including their organisationId. It was also vulnerable to the CSRF bypass using the stolen token.

Now I had all the pieces:

1. Steal xsrftoken via XSS.
2. Call /api/apps/user to get the victim's organisationId.
3. Call /api/app/organisations/{org_id}/invites to invite myself as Admin.

Crafting The Payload

I combined these steps into a single payload to be injected into the placeholderTextparameter:

<img src=x onerror="var t=document.cookie.match(/xsrftoken=([^;]+)/)[1];fetch('/api/apps/user',{headers:{'X-Csrf-Token':t}}).then(r=>r.json()).then(d=>fetch('/api/app/organisations/'+d.organisationId+'/invites',{method:'POST',headers:{'Content-Type':'application/json','X-Csrf-Token':t},body:JSON.stringify({email:'0xs3fo@gmail.com',asAdmin:true})}))">

How it works: It's a chain reaction. Once a victim views the page, this payload steals their xsrftoken. Then, it sends a request to /api/apps/user to get their organisationId. Finally, it sends an invitation request to make 0xs3fo@gmail.com an Admin of their organization.

Steps To Reproduce

1. Create a Page Group in my own organization.
2. Edited a page and injected the payload into the placeholderText parameter.

3. Used the Broken Access Control flaw to add the Victim's User ID to my Page Group as an Editor. Now, they were a member of my page group.

4. Once the victim visited my page, the XSS payload worked in silence and sent an Admin Invite From his organization to the email I injected.

5. I accepted the invite, logged in, and immediately deleted the original owner.

And now the entire organization is under my control.

This isn't just about taking over one organization. The impact is massive because it allows an attacker to hack the entire platform.

An attacker can create a single "Page Group," inject the XSS payload, and since the IDs is sequential you can make a simple script to add thousands of users to your Page Group For example from 1 to 200000.

The attacker doesn't need to know anyone's name or email; they just try a huge range of numbers and wait. Sooner or later, users from different organizations will log in, see this new page group, and click to check it out.

That single click is all it takes. The XSS triggers right away, and the attacker receives an Admin invite from the victim organizations.

It's a silent, automatic way to take over everything on the platform.

I reported the issue responsibly to the Target security team, providing detailed PoC steps and screenshots. They confirmed the bug and resolved it quickly.

Unfortunately, they classified this as High severity because the Broken Access Control issue was duplicate

الحمدلله ❤️

Follow Me

https://www.linkedin.com/in/0xs3fo/

https://x.com/0xs3fo