Abusing Broken Access Control and SQL Injection in the Wild

Hi all! How are you guys? I hope everything is fine. It's been quite a while since I last wrote an article — probably over a year. Work and university life kept me pretty busy, and I just didn't have the time to sit down and write, even though there were a lot of things I wanted to share and document. So, this time I'm easing back into it with a light story.

A few weeks ago, I was helping a family member register at a school that offered online registration. Out of curiosity and habit, as someone who's into web security, I started poking around the application to see how it was built.

Let's just call the site: www.site.com

Broken Access Control

I began with the usual suspects — trying SQL Injection on the login form, checking for auth bypasses, and other basic attacks. Unfortunately, nothing worked — at least at first.

So I tried viewing the source code and started fuzzing with ffuf:

Explanation

• -u : target URL. Make sure to include FUZZ so ffuf knows where to test.
• -w : wordlist file. You can use a list from SecList or dirsearch.
• -fs 0 : filters out responses with size 0. Helpful to reduce false positives.
• -c : adds color to the output (because colors make bugs more fun)

Unfortunately… nothing useful came up.

Since fuzzing didn't give anything, I switched to Burp Suite and ensured my proxy was set using FoxyProxy.

After refreshing the page and attempting to log in again, I noticed a file called spk.php

which I somehow missed during fuzzing. Accessing it via browser returned a 302 Found with a pop-up saying "Silakan login terlebih dahulu" — which means I am asked to log in first.

Hmm. Not very helpful. But then I checked the raw response in Burp. Even though it was a 302 redirect, the source code was still visible. I found:

And further down… an admin dashboard with a logout button. I switched Burp's layout to a top-bottom view and clicked on the Render tab.

I started collecting URLs from the dashboard:

• index.php
• alternatif.php
• kriteria.php
• nilai.php
• spk.php

Then I tried adding a new student to see whether access was read-only or if I could go further.

It worked. Next, I edited the student's name from test-poc to test-poc-change.

SQL Injection

After taking a break, I was about to shut down my laptop. But then I thought "Why not go just a bit further?"

So I revisited the request used to edit the student data:

Normally, a success message like "Data berhasil diperbarui" appears.

I added a single quote:

The message disappeared.

Then I added another quote:

The success message came back. That looked suspiciously like a classic SQL injection indicator. I copied the full request and saved it as inject.txt.

SQLMap Exploitation

Start sqlmap with this command:

What each option does

• -r : read the raw request file.
• -p : test only the nama parameter
• --level 3 : deeper and more extensive tests
• --risk 3 : includes higher-risk payloads
• --random-agent : rotates user-agent strings
• --batch : no prompts, just run
• --ignore-redirect : super important here; avoids 302 redirection that would otherwise break injection
• --dbs : dumps database names if vulnerable

Conclusion

Writing this story reminds me how much I enjoy documenting things like this. Even though this was just a small finding, it felt good to dive back into the habit of writing again. Hopefully, I can keep it up and share more in the future.

Interestingly, this kind of vulnerability is something I often come across during bug bounty hunting — especially in private programs. It shows how even simple misconfigurations can have a big impact, and how important it is to test and secure applications thoroughly.

Maybe that's all from me, hopefully it won't take me another year to post again. I'm RyuuKhagetsu, see you in next article.