Security misconfigurations and IDORs (Insecure Direct Object References) continue to be among the most critical and common vulnerabilities in modern web applications. In this walkthrough, I explore the vulnerable-by-design Log Snare app and show how an attacker can escalate from a basic user to impersonating admins across organizations — using nothing more than a browser and some basic recon.

Let's dive in.

🐳 Getting Started with Log Snare

Spinning up Log Snare locally is a breeze using Docker:

docker pull seaerkin/log-snare docker run -p 127.0.0.1:8080:8080 seaerkin/log-snare

Once it's up, visit: 👉 http://127.0.0.1:8080

Now let's begin the journey from a lowly user to a cross-org admin.

None

🔍 Challenge 1: Nosy User 🕵️🤑

"As a regular user, you can view employees of your company… but you want to view employees of another company."

Exploit: Classic IDOR

Visit:

http://127.0.0.1:8080/app/employees/1

Now change the URL to:

http://127.0.0.1:8080/app/employees/2

None

data from another company appears. No authorization checks. No token validation. This is a textbook IDOR vulnerability.

✅ Lesson: Always validate that the user requesting the data belongs to the organization that owns it.

🧨 Challenge 2: Power Trip 😎🚀

"You're just a basic user… but that can be fixed."

The goal here is to escalate to admin — and it's easier than it should be.

Exploit: UI Control Doesn't Equal Access Control

  • Go to the Settings page.
  • You'll see a checkbox or toggle that appears disabled.
  • Right-click the checkbox > Inspect Element.
  • Manually remove the disabled attribute in the browser dev tools.
  • The "Update" or "Save" button becomes active — click it.

You're now an admin.

None

✅ Lesson: Disabling UI elements is not a security control. The backend must enforce permission checks server-side.

🔥 Challenge 3: Administer Another Org 🔥🥵

"You're an admin now. Can you impersonate a user from another organization?"

Let's go.

Step-by-Step Exploit

  1. Visit:

http://127.0.0.1:8080/app/settings

As an admin, you now have access to the "Impersonate User" feature.

  • Select any user.
  • Capture the request. You'll see:

GET /app/impersonate/<uid>

This uid is not easily guessable — but where does it come from?

🧠 Finding the UID of Another Org

Go to:

http://127.0.0.1:8080/app/users/Q29tcGFueUlkOjE=

This Base64 string (Q29tcGFueUlkOjE=) decodes to CompanyId:1.

Change it to:

CompanyId:2

Base64 encode it:

Q29tcGFueUlkOjI=

Visit:

http://127.0.0.1:8080/app/users/Q29tcGFueUlkOjI=

You can now view users from Company 2.

None

Final Impersonation

  • Inspect the user table — you'll find a uid associated with each user.
  • Pick one, then impersonate them using:

GET /app/impersonate/<company2_user_uid>

💥You are now impersonating an admin in another company.

💭 Final Thoughts

This was an awesome, hands-on experience in finding and chaining vulnerabilities — and just as importantly, understanding how to prevent them.

What started as a simple IDOR turned into full admin control of another organization. These challenges are a fun reminder that basic oversights can lead to serious breaches if not caught early.

👉 Want to try it yourself? Get Log Snare on GitHub

Happy hacking — responsibly. 🛡️