From ‘Access Denied’ to P1: Escalating SQL Injection

In bug hunting, the difference between a “dead end” and a P1 vulnerability is often just a matter of persistence and the right methodology. Recently, during an engagement on Bugcrowd, I encountered a target that initially seemed completely hardened. My requests were met with “Access Denied” messages, but I knew the surface area had to be larger than what appeared on the surface.

From ‘Access Denied’ to P1: Escalating SQL Injection

In bug hunting, the difference between a “dead end” and a P1 vulnerability is often just a matter of persistence and the right methodology. When I first attempted to visit this target, I was met with an immediate “Access Denied” (403 Forbidden) response. Many researchers would have taken this at face value, assumed the target was fully hardened, and moved on to another program. I knew, however, that a 403 response is often just a sign that you haven’t found the right entry point yet.

The Recon Phase

Rather than giving up, I chose to dig deeper. I started by using Katana to crawl the application and map out hidden endpoints that aren’t visible through standard manual browsing. This process of mapping the attack surface is where I uncovered the endpoints that were actually accessible, despite the main landing page being restricted.

katana -jc -u [Target_URL]

The crawler returned a list of endpoints. One in particular stood out, as it seemed to handle data queries for the product catalog. To expand my reconnaissance, I also utilized tools like Waybackurls, Waymore, GAU, GAUplus, and Golinkfinder to perform deep link discovery and JavaScript file analysis, ensuring no hidden parameters or API routes were left unexamined.

The Discovery

I noticed the product display page utilized multiple URL parameters. As a researcher, I know that filter parameters are high-risk vectors for injection because they often interact directly with the database. I began systematically fuzzing each parameter. When I injected a single quote (’) into the YEAR parameter, the application returned a verbose database error:

com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near the keyword ‘and’.

This was the “Aha!” moment. The error confirmed three critical facts:

1. Backend Tech: The application was running Microsoft SQL Server.
2. Lack of Sanitization: The input was being concatenated directly into the query.
3. Vulnerability: The application was susceptible to SQL Injection.

Manual Verification

Before automating, I manually validated the vulnerability to ensure it was a genuine flaw and not a false positive. In a UNION-based SQL injection, the injected sub-query must align perfectly with the original (super) query’s column count. To do this, I first used an ORDER BY clause to determine that the super query was returning only 1 column.

A key trick here was using -2025 for the YEAR parameter. By setting this to a value that doesn’t exist in the database, I forced the original query to return no results. This cleared the way for the system to display only the output of my injected sub-query instead.

Furthermore, because the original database query likely ends with another single quote (to close the initial statement), I used — and a space (represented as — ) to comment out the remainder of the original SQL statement. This prevents the database from executing the leftover syntax, which would otherwise trigger a syntax error and break my injection.

With the column count confirmed and the super query cleared, I successfully extracted metadata from the server. Using this approach, I confirmed:

Database Version: …&YEAR=-2025 union select @@version —

Database Name: …&YEAR=-2025 union select DB_NAME() —

To further escalate and retrieve the table names, I utilized the following URL-decoded payload:

https://www.target.com/AAOS/AAOM/WebViewer?OP=BO&YEAR=-2025 UNION SELECT table_name FROM information_schema.tables — -&CATEGORY=Swing&SEARCH=&COUNTRY=UNITED STATES&LIBRARY=Automatic Door Library

Exploitation

Once verified, I used sqlmap to assess the full scope of the exposure.

sqlmap -u “[URL_with_parameter_markedby*]” — dbs

The tool successfully identified 12 accessible databases, including sensitive system databases like master and Users. This confirmed that the vulnerability provided an entry point for full database enumeration and potential exfiltration.

Impact and Remediation

The business impact was severe: an attacker could exfiltrate sensitive customer data, tamper with system records, or potentially perform remote code execution depending on the server’s configuration.

To remediate this, the development team must shift away from dynamic string concatenation. The fix is two-fold:

1. Parameterized Queries: Use Prepared Statements to ensure user input is never treated as executable code.
2. Principle of Least Privilege: Configure the database user account used by the web application so that it cannot access system-level databases like master or msdb.

The Pro-Tip: Don’t Stop at 403 Forbidden

A “403 Forbidden” or “Access Denied” response is not the end of the road — it is often just a sign that you haven’t found the right path yet. Never give up on a target just because of an initial block. Expand your search surface by using automated crawling and discovery tools to find hidden gems:

• Katana: For advanced web crawling and endpoint discovery.
• Waybackurls/Waymore: To pull historical URLs and potentially find deprecated endpoints.
• GAU/GAUplus: To discover all URLs known to common search engines for a domain.
• Golinkfinder: To hunt for hidden links in JavaScript files.
• JavaScript Crawling: Always scan JS files to find API keys, hidden endpoints, and business logic flaws.

Conclusion

This case serves as a vital reminder: even in 2026, classic vulnerabilities like SQLi remain a massive threat to enterprise applications. Persistence in the reconnaissance phase and a methodical approach to parameter testing are the researcher’s most valuable assets. If you encounter a 403, change your strategy, use your toolkit to map the depth of the application, and keep digging. Your next P1 might be hiding behind a page you originally thought was restricted.

About the Author: PhD in Cybersecurity, Certified Ethical Hacker (CEH), and expert in web application security, active Bugcrowd researcher specializing in infrastructure defense.