Updated April 12, 2025
Web Application Penetration Tests are some of the more involved tests we regularly perform at Blue Goat. These tests always place us in a new and unique environment that tests our reconnaissance skills. Part of the skill of being a good penetration tester comes down to the tester’s ability to properly evaluate the actual risk that comes from a vulnerability. This can be greatly skewed from the conventional risk rating for similar vulnerabilities based on our unique environment.
Chaining Vulnerabilities
One way that major vulnerabilities can get overlooked is if there is a chain of multiple exploits needed to get the maximum effect. While any one part of it would be its own vulnerability, it may not be severe enough to get easily found. A good example of this would be an internal application with a SQL injection vulnerability on the same network as an external application with a Server-Side Request Forgery (SSRF) vulnerability.
In this hypothetical scenario, hackers could not attack the external server directly. Similarly, the vulnerable internal server is unreachable from their position. This is where chaining the two vulnerabilities together would provide maximum severity, even if the severity is greatly lessened on its own. Attacking the internal SQL injection vulnerability would be a massive win for the attackers.
Case Study
Blue Goat was tasked with testing an external web application on this engagement. This was a Gray Box test where we had an unauthenticated, user, and admin role on the application. Testing revealed this to be a secure application with a mature security team. This often means that we will have to look more carefully to uncover vulnerabilities that may have been overlooked.
One immediate problem that presented itself was the user ID generation scheme. IDs were generated incrementally, meaning that the application had an IDOR vulnerability. It is very important to look at the impact of a vulnerability like this. A good example could be a banking site. If you visit a page such as /account?id=20, and visiting /account?id=21 gives you access to another account page, this is a big deal.
In this instance, resources were restricted from other users. Trying to manipulate the user ID parameter did not allow us access to other users’ data. This is still not a best practice to have in place since attackers can quickly iterate through IDs even just to validate the existence of an account. User IDs should be a unique value that is ideally randomly generated and unrelated to other user’s IDs.
During further testing, our testers identified a password reset functionality. These areas can have major vulnerabilities attached to them. This specific one relies on recovery questions for the user to be able to set a new password. Recovery questions are a dangerous feature on an application due to how easy it can be to find that information online. Sending temporary recovery passwords to the user’s email can be a better way to ensure security
While watching requests and responses go through our web proxy, we noticed that a request was being made to an API endpoint to request the user’s security information. The team at Blue Goat noticed that it was possible to directly make a request to that endpoint as an authenticated user to find the security questions of any other user on the application. Knowing this information could allow an attacker to scrape that information, and then simply rely on some social media reconnaissance to try and find the answers to the recovery questions.
This vulnerability, combined with the IDOR vulnerability mentioned earlier, means that an attacker could write a small script to pull the security questions for every user on the platform and begin targeted attacks.
Remediation
Broken access control is the #1 vulnerability on the OWASP Top 10 list. It is extremely prevalent in modern applications, as it can be very easy to miss. Great care needs to be taken to ensure that users are properly restricted from accessing sensitive information. Giving users the least privilege possible while still allowing them to do everything they need on the application is a best practice in preventing broken access control vulnerabilities. In this example, it would have also been far harder to pull all of this information if a randomized ID generation system had been in place.
Test Your Web Application Security With Blue Goat Cyber
Web Application Penetration Tests can be a complicated process. Our team is highly trained and certified to perform these tests and can work with you to ensure that your web presence is fully hardened against attack. Contact us to learn more.
Vulnerability Chaining FAQs
Vulnerability chaining is the technique of combining multiple lower-severity vulnerabilities to achieve a more serious security breach. Individually, each flaw might seem minor, but together they can lead to unauthorized access, data exfiltration, or system compromise.
Chained vulnerabilities can bypass security controls that would otherwise stop an isolated issue. Attackers exploit the interdependencies between flaws to escalate privileges, pivot across systems, or extract sensitive data undetected.
Yes. Many severe attacks begin with low-risk flaws (e.g., information disclosure, insecure redirects, or weak authentication) that, when combined, form a high-impact attack path. Never ignore minor issues—they may be puzzle pieces to something bigger.
A common example might include:
- Misconfigured API that leaks usernames
- Brute-force vulnerability due to weak rate-limiting
- Privilege escalation flaw in user role assignments
Together, these allow an attacker to go from zero access to admin control.
Expert testers don’t just look for individual flaws—they analyze attack paths, combining findings to simulate how a real attacker would escalate access. At Blue Goat Cyber, our reports highlight both individual findings and how they could be chained.
Effective threat modeling maps how attackers move through a system, making it easier to identify chained vulnerabilities. STRIDE, DFDs, and attack trees are useful methods to visualize these potential chains during design and testing.
- Complex web applications
- IoT and embedded systems with limited visibility
- API-driven architectures
- Cloud environments with misconfigured roles or over-permissioned services
The more components and integrations, the more opportunities for chaining.
- Fix all identified vulnerabilities, regardless of severity
- Use zero trust principles to limit lateral movement
- Conduct layered penetration testing and red teaming
- Prioritize defense-in-depth and least privilege access
No. Most automated scanners only flag individual vulnerabilities. Chaining requires human intelligence, contextual analysis, and creative thinking, which is why manual pen testing is essential for accurate risk assessment.
We provide:
- Advanced penetration testing that simulates real-world attacker behavior
- Threat modeling workshops to anticipate potential chains
- Detailed reports showing how multiple issues interact
- FDA and HIPAA-aligned remediation support to ensure compliance
