Bypassing reCAPTCHA v3 During VAPT: A Case Study in Automated SQLi Validation

During a recent authorized VAPT engagement, I encountered an interesting scenario where a potential SQL injection point was protected by reCAPTCHA v3, making traditional automated exploitation tools ineffective.

This write-up covers the discovery, the challenge introduced by modern bot protection, and how I built a controlled automation workflow to validate the issue.

🔍 Initial Discovery

While testing a registration endpoint, I observed unexpected behavior in a contact number field.

When inserting alphabetic input instead of numeric values, the application returned a database error.

This strongly indicated a potential SQL injection vulnerability due to improper input validation and backend query handling.

⚠️ The Challenge: reCAPTCHA v3 Protection

Before deeper validation, the endpoint was protected with:

Google reCAPTCHA v3

This introduced a key limitation:

• Automated tools like sqlmap could not reliably operate
• Tokens were dynamically generated per session
• Direct request replay failed due to token invalidation

At this point, manual testing confirmed the signal — but automation was required for proper validation.

🧠 Approach to Controlled Automation

To proceed within the scope of the engagement, I focused on building a workflow that could:

• Maintain legitimate client-side interaction
• Generate valid reCAPTCHA v3 tokens per session
• Pass fresh tokens into automated requests dynamically
• Preserve session consistency during testing

This allowed controlled automation while still respecting the application's intended client-side security flow.

⚙️ Implementation Overview

I built a Python-based automation script using Selenium that:

• Launches a real browser session
• Loads the target registration page
• Triggers reCAPTCHA execution through normal client-side flow
• Extracts generated tokens dynamically
• Stores tokens for consumption by sqlmap

This allowed each request to remain valid under reCAPTCHA v3's expectations while still enabling structured testing.

🧪 SQLMap Integration

Once token generation was stabilized, I integrated it with sqlmap by:

• Injecting dynamically generated reCAPTCHA tokens into requests
• Maintaining session cookies for consistency
• Controlling request flow using eval-based synchronization

This enabled sqlmap to continue testing without breaking request validation flow.

👉 Full script and sqlmap command: GitHub Repository: https://github.com/sameerwire/reCAPTCHA-v3-Token-Harvester/

🧪 Result

The testing confirmed:

• The parameter showed SQL injection-like behavior
• Error-based database responses were consistently observed

However, after manual verification and impact analysis:

The issue was determined to be non-exploitable in a real-world scenario due to backend constraints and query structure limitations.

🔧 Making It More Robust (Future Improvement)

While the current implementation worked for controlled testing, a more production-grade approach would involve replacing Selenium-based token harvesting with a Puppeteer-driven orchestration layer.

Why Puppeteer improves this workflow:

• Better control over Chrome DevTools Protocol (CDP)
• More stable execution of modern JavaScript-heavy flows
• Easier interception of network requests and responses
• More reliable handling of async reCAPTCHA execution timing
• Lower flakiness compared to Selenium in complex SPAs

Suggested architecture upgrade:

• Puppeteer handles browser automation + token lifecycle
• Node.js service exposes a local API endpoint: /get-token
• sqlmap (or custom injector) fetches fresh tokens per request
• Centralized session + token manager improves reliability

This would make the workflow:

• More modular
• More stable under load
• Easier to extend for other WAF / bot protection scenarios

🧩 Key Takeaways

1. CAPTCHA is a friction layer, not a fix

It slows automation but does not eliminate backend vulnerabilities.

2. Automation still requires validation logic

Even with tooling, human analysis is required to determine exploitability.

3. Error-based signals remain valuable

Database errors often reveal deeper structural weaknesses.

4. Engineering perspective matters in VAPT

Sometimes the challenge is not exploitation — but building a valid testing pipeline.

📌 Conclusion

This case reinforced a simple reality in modern security testing:

Security controls like reCAPTCHA v3 increase friction — but secure backend logic is what truly prevents exploitation.

Even though the SQL injection was ultimately not exploitable, the exercise demonstrated how layered defenses can obscure underlying issues and how controlled automation can help validate them responsibly.

🔗 Resources

• GitHub: https://github.com/sameerwire/reCAPTCHA-v3-Token-Harvester/ Includes:
• Selenium-based token generator
• SQLMap integration command
• Test workflow setup

Special thanks to p4n7h3rx for the help!