Beyond the Wall: Bypassing OTP, WAF, and 403 for exploiting a SQL Injection

RemmyRemmy
4 min read

Table of contents

In this blog post, I’m going to share my experience exploiting a SQL Injection after bypassing WAF, the 403 Status Code, and OTP on a VDP program. I won’t go through my recon process here, as I’ve covered it in a previous XSS writeup, which you can read: 403 Forbidden? No Problem, Here’s a POST XSS | by Remmy | Medium

After opening up subdomains one by one, I stumbled upon a subdomain called “legacypanel.redacted.com.” However, the first thing I encountered was a “403 — Access denied.” As usual, I entered a dummy path to test whether this was a stubborn 403 on all paths or only on the main domain.

legacypanel.redacted.com/dummypath

After entering the dummy path, the code changed from 403 to 404, indicating that the 403 restriction was only applied on the main domain and not on other paths. The next step involved conducting a directory brute force on the target using my private wordlist. Following the fuzzing process with ffuf, I discovered the existence of a /dashboard path.

Upon accessing the dashboard, I encountered a registration page. I went ahead and registered, and the web application informed me that they had sent an OTP, but alas, the OTP was never sent to me.

So, I had already bypassed a 403, conducted a fuzz, but should I surrender just because the web application didn’t send me the OTP to my email? You can probably guess the answer :) Well, the answer is YES. I gave up, feeling hungry and tired. After a 30-minute break, I returned to the work.

There are several ways to bypass the OTP, and I tried these things:

  • I attempted to brute force the OTP code, but there was a rate limit, so I failed.

  • I experimented with magic OTPs, and as you can guess, I failed.

  • I tested a Race condition on OTPs, and again, I failed.

But, I finally found a way to bypass the OTP. The OTP was coming back in the response, and I had spent 30–45 minutes attempting various bypasses when the only necessary thing was to look at the responses. So, I entered the OTP and jumped into the web application.

The user dashboard of the web application featured a handy search box, allowing users to keep tabs on their orders and tickets. My initial experiment involved inputting a SQL Injection payload, specifically 1234’, which triggered a noticeable shift in the web application’s behavior. This alteration raised my suspicion, prompting me to consider the possibility of a SQL injection. As the situation seemed to demand further investigation, I found myself in need of exploring the matter more thoroughly.

After injecting a single quote, I tried the following payload: 1234’+and+ sleep(5) — Can you guess the output? WAF BLOCKED me. Now, I needed a way to bypass the WAF. I changed my payload to the following: 1234’/\*/and/**/sleep(5) — It didn’t work. Then, I started capitalizing the words in the payload: 1234’ // AND // slEEp(5) — and I got blocked again. I modified the payload to: 1234’ %2F%2A%2A%2FAnd%2F%2A%2A%2Fsleep(5) –*

If you’re thinking I got blocked by the WAF, you’re spot on — blocked again. The tricky part wasn’t the space or the comment; it turned out to be the closing parenthesis of the sleep() function. After scouring search engines and reading through some subreddits, an idea sparked in my mind.

The solution? Combining the payload with a URL-encoded Entered I tweaked the payload to incorporate this newfound insight:

1234'%2F%2A%2A%2FAnd%2F%2A%2A%2F%0Asleep(5) —

And? WAF blocked my again :(

Then I changed my payload to:

1234'%2F%2A%2A%2FAnd%2F%2A%2A%2F%0Asleep(5%29—

And, after implementing the final payload, success was achieved. I diligently compiled a comprehensive report (although I must confess, the report was bad :))), and promptly submitted it to the program. With a sense of accomplishment, I concluded my day as a contented hunter.

Conclusion

my journey through bypassing OTP, WAF, and the formidable 403 barrier to exploit a SQL Injection was both challenging and rewarding. From the initial hurdles of access denial to the intricate maneuvers required to bypass security measures, each step presented its own set of obstacles and lessons.

Through persistence, experimentation, and a dash of creativity, I uncovered vulnerabilities and devised strategies to overcome them. While some attempts ended in failure, each setback served as a valuable learning experience, pushing me to explore new approaches and refine my techniques.

Ultimately, the successful bypass of the OTP and the execution of the SQL Injection underscored the importance of perseverance and adaptability in the field of cybersecurity. By sharing my experience, I hope to inspire others to approach challenges with a tenacious spirit and a willingness to explore unconventional solutions.

Thank you for joining me on this adventure. Until next time, stay curious, stay vigilant, and happy hacking!

Remmy (@NineRemmy) / X (twitter.com)

0
Subscribe to my newsletter

Read articles from Remmy directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Remmy
Remmy

Bug bounty hunter and security researcher specializing in web, Android, and network penetration testing. Passionate about breaking applications, uncovering critical vulnerabilities, and understanding how systems fail. Experienced in adversary simulation, exploit development, and building custom vulnerable labs. Beyond security, I explore programming (JavaScript, Go, Rust) and competitive problem-solving. Always learning, always hacking.