In the world of bug bounty hunting, it’s easy to get comfortable with familiar vulnerabilities like Cross-Site Scripting (XSS) and SQL Injection. But as programs mature, basic vulnerabilities become harder to find. To stay ahead, you need to expand your skillset to identify lesser-known vulnerabilities. Here are five often-overlooked vulnerabilities and how you can catch them in the wild.
1. Server-Side Request Forgery (SSRF)
Overview: Server-Side Request Forgery (SSRF) vulnerabilities allow an attacker to make requests to internal or external services on behalf of the server. This vulnerability can expose sensitive internal endpoints, interact with cloud services, and even escalate to remote code execution (RCE) in certain scenarios.
Why It’s Overlooked: SSRF often hides in functionalities like image uploads or URL previews, where a server-side application fetches external resources without sufficient input validation.
How to Catch It:
- Identify Input Points: Look for any functionality where the application makes HTTP requests based on user input. This is common in image URLs, PDF generators, and import/export tools.
-
Payloads: Use payloads that attempt to reach internal services, such as:
http://localhost:80
-
http://169.254.169.254
(for AWS metadata service exploitation)
- Tools: Burp Suite’s Collaborator tool can help you detect SSRF by checking if the server makes a request to a controlled URL. Other tools like ssrfmap can automate SSRF discovery in various cloud environments.
Example: If you find an SSRF, attempt to fetch sensitive information by targeting internal IP ranges or cloud provider metadata endpoints. In cloud environments, metadata endpoints can leak instance credentials, escalating the attack.
2. Host Header Injection
Overview: Host Header Injection occurs when an application trusts user-supplied Host headers without proper validation. This can lead to various issues, including web cache poisoning, bypassing security mechanisms, and even SSRF in certain cases.
Why It’s Overlooked: Many developers assume Host headers are controlled by the client and ignore them in their validation processes, especially if they only test for parameters in the URL or POST body.
How to Catch It:
- Identify Usage of Host Header: Check endpoints where the server’s behavior might change based on the Host header value, such as redirects, URL generation in emails, or multi-tenant applications.
-
Payloads:
- Use payloads like
X-Forwarded-Host: evil.com
andHost: evil.com
to check if the application reflects or uses the Host header without validation.
- Use payloads like
- Tools: Manual testing with Burp Suite is effective here, particularly the Repeater tool to modify headers and observe responses.
Example: If you’re testing an application that generates password reset links or email verifications, try injecting your own Host header value. This can sometimes allow you to intercept these emails with links pointing to your controlled domain.
3. HTTP Parameter Pollution (HPP)
Overview: HTTP Parameter Pollution (HPP) occurs when an attacker manipulates HTTP parameters by injecting additional ones, potentially leading to unexpected application behavior, bypassing access controls, or even escalating to data manipulation.
Why It’s Overlooked: HPP can be subtle and is often missed during testing, as applications don’t always handle duplicate parameters consistently. Some developers assume parameter order doesn’t matter or that only the first instance will be used.
How to Catch It:
- Identify Vulnerable Endpoints: Look for endpoints that handle multiple parameters, such as search filters or multi-step forms.
-
Payloads:
- Try injecting duplicate parameters, such as
?user=admin&user=guest
, to see how the application resolves them.
- Try injecting duplicate parameters, such as
- Tools: Use Burp Suite or ffuf to automate parameter injection and check the application’s response to each variation.
Example: Suppose you find a vulnerable endpoint like /api/user?role=admin&role=guest
. If the application processes role=admin
over role=guest
, you might gain unauthorized admin access by exploiting this ambiguity.
4. Insecure Deserialization
Overview: Insecure deserialization occurs when untrusted data is deserialized by an application without proper validation. This can lead to attacks like remote code execution, privilege escalation, and data tampering.
Why It’s Overlooked: Deserialization attacks are often specific to certain languages (e.g., Java, PHP) and can be challenging to exploit without a deep understanding of the application’s data serialization and deserialization processes.
How to Catch It:
- Identify Serialized Data: Look for indicators like base64-encoded data in cookies, API parameters, or request bodies.
-
Payloads: Use known payloads for deserialization attacks, such as:
- Serialized object injection payloads for Java or PHP (e.g., Gadget chains).
- Tools: ysoserial and marshalsec can help you generate exploit payloads for various deserialization frameworks.
Example: If you find a Java application that accepts serialized data in cookies, try injecting a malicious payload using ysoserial. If successful, this can lead to code execution on the server.
5. Business Logic Vulnerabilities
Overview: Business logic vulnerabilities exploit the application’s workflow rather than a technical flaw. These vulnerabilities allow users to bypass expected constraints, perform unauthorized actions, or manipulate data in unintended ways.
Why It’s Overlooked: Business logic vulnerabilities are unique to each application, requiring a deep understanding of the app’s intended functionality. Automated scanners can’t identify these vulnerabilities, so they often require manual analysis.
How to Catch It:
- Map Out Workflows: Analyze the application’s workflow and identify assumptions in the business logic. Try to perform actions out of order, modify parameters, or bypass steps.
- Common Targets: Look for multi-step forms, checkout processes, and account management features.
- Testing Approach: Attempt actions like increasing a product’s quantity after checkout, changing prices via parameter tampering, or accessing privileged functions from a standard user account.
Example: In an e-commerce site, try to bypass payment verification by manipulating the order status or finalizing orders without a valid payment. Similarly, look for ways to apply discounts multiple times or stack them beyond intended limits.
Top comments (0)