Listen to this Post
Introduction:
Many web applications claim to protect sensitive files from unauthorized download using access control mechanisms, but a critical oversight can render these protections useless. When an application inadvertently returns the full raw binary of a file within an HTTP response—instead of a simple access denied message—an attacker can intercept that response, extract the binary data, and reconstruct the file locally, completely bypassing any download restrictions.
Learning Objectives:
- Understand how raw binary leakage in HTTP responses undermines file protection mechanisms.
- Learn to use Burp Suite to intercept, analyze, and extract raw binary data from responses.
- Implement server-side mitigations to prevent accidental exposure of file contents.
You Should Know:
- The Anatomy of Raw Binary Leakage in Web Responses
Raw binary leakage occurs when a server responds to a request for a protected file by sending the actual file’s binary data—often preceded by a ZIP file signature like PK\x03\x04—instead of a proper error or redirection. This commonly happens when developers mistakenly return the file contents in the response body of a REST API endpoint intended only to check permissions, or when a file download endpoint fails to validate authentication but still streams the file.
Why this is dangerous: Even if the client-side interface shows “Access Denied,” the underlying HTTP response may contain the complete file. Attackers using intercepting proxies like Burp Suite can capture this response before it reaches the browser, save the raw binary, and open it locally.
Step‑by‑step guide to identifying raw binary leakage:
- Set up Burp Suite as an intercepting proxy between your browser and the target application. Configure your browser to use 127.0.0.1:8080 as the proxy.
- Navigate to the protected file (e.g., a document viewer that claims “no download allowed”).
- In Burp, enable Intercept (Intercept is on). Click to view the file—Burp will capture the request.
- Forward the request and observe the response. Look for raw binary signatures in the response body, such as `PK` (ZIP), `%PDF` (PDF), `MZ` (EXE), or any non‑printable characters.
- Right‑click the response → `Send to Repeater` for further analysis.
Linux command to check for ZIP signatures in a captured file:
Save the raw response body as response.bin cat response.bin | xxd -l 4 | grep "PK" Expected output if ZIP: 00000000: 504b 0304 PK..
Windows PowerShell equivalent:
Read first 4 bytes as hex [System.BitConverter]::ToString((Get-Content -Path .\response.bin -Encoding Byte -TotalCount 4)) Output "50-4B-03-04" indicates ZIP file
- Using Burp Suite to Capture and Extract Protected File Binaries
Once you’ve identified a response containing raw binary, the next step is to extract and reconstruct the file. Burp Suite makes this straightforward with its “Save item” feature, but you can also manually copy the binary data.
Step‑by‑step extraction guide:
- In Burp Suite’s Proxy → HTTP history, locate the response that contains the raw binary.
- Select the response tab. You’ll see a mix of readable and binary data. If the response is large, Burp may truncate it—ensure “Show raw” or increase response size limits in Burp settings.
- Right‑click the response → `Copy` →
Copy body as bytes. Alternatively, go to `Response` → `Save body` to write the raw binary directly to a file (e.g.,leaked.zip). - Verify the saved file using file command or by attempting to open it.
Linux commands to verify and extract:
Check file type file leaked.zip If output shows "Zip archive data", proceed Extract contents unzip leaked.zip -d extracted_folder/
Windows (cmd) with certutil:
Save response body as base64 from Burp, then decode certutil -decode leaked.b64 leaked.zip Then extract using built-in PowerShell powershell Expand-Archive -Path leaked.zip -DestinationPath extracted\
Python one‑liner to save raw bytes from a Burp-copied hex dump:
If you copied hex from Burp's "Hex" tab, paste into a variable
hex_data = "504b030414000000..." truncated
with open("recovered.zip", "wb") as f:
f.write(bytes.fromhex(hex_data))
3. Exploiting the Leak: Full Local Reconstruction
With the raw binary saved as a proper file, you now have the protected file locally—regardless of any server‑side download restrictions. This technique bypasses token‑based authentication, IP whitelisting, or even time‑limited URLs, because the server itself sent the file contents in a response that the attacker legally received.
Example scenario: An e‑learning platform displays PDF previews but blocks “Download” buttons. However, the `/api/preview/{id}` endpoint returns the entire PDF binary. An attacker intercepts that response, saves it as lesson.pdf, and now has the unrestricted file.
Step‑by‑step exploitation using Burp Suite and curl:
- Identify the vulnerable endpoint – often an API call like `/getFile?id=123` or
/document/view/{id}. - Use Burp Repeater to resend the request and confirm the raw binary appears even with invalid or missing session cookies.
3. Automate extraction with curl for large‑scale testing:
curl -X GET 'https://target.com/api/protected/file/123' \ -H 'Cookie: session=invalid' \ --output leaked_file.bin file leaked_file.bin
4. If the file is chunked or encoded (e.g., base64 in JSON response), decode it:
Example: response contains {"data":"UEsDBBQ..."}
cat response.json | jq -r '.data' | base64 -d > decoded.zip
Mitigation for developers: Never return binary file content in a response unless the endpoint is explicitly designed for download AND enforces strict access control at every layer. Use `204 No Content` or `403 Forbidden` with a simple JSON error message instead.
- Why Access Control Isn’t Enough When Data Leaks
Access control mechanisms (RBAC, ABAC, or even OAuth scopes) only restrict who can request a resource—they do not automatically prevent the server from leaking data if the endpoint logic is flawed. In the original post, the researcher noted: “Access controlnya ada bahkan secure malah, tapi mereka harusnya gak boleh kasih raw binary file di response saat coba buka file.” Translation: Access control exists and is secure, but they shouldn’t give the raw binary file in the response when trying to open the file—instead, just give a regular message.
Key takeaways for security architects:
- Defense in depth requires that even if authorization passes, the response must be sanitized. A file preview endpoint should return only metadata or a thumbnail, not the original binary.
- Don’t trust client‑side enforcement – disabling the download button via JavaScript does nothing to stop an attacker using Burp Suite.
- Audit all API responses for unintentional binary leakage using automated tools like ZAP or custom scripts.
Linux script to recursively check responses for ZIP signatures:
Using grep and curl on a list of endpoints while read url; do curl -s "$url" | head -c 4 | xxd -p | grep -q "504b0304" && echo "Leak at: $url" done < urls.txt
5. Mitigation: Secure File Handling Practices for Developers
To prevent raw binary leakage, implement these server‑side controls:
1. Validate authorization before generating any file output.
In pseudo‑code:
if not user.has_permission(file_id):
return {"error": "Access denied"}, 403 DO NOT return file binary
- Use proper Content-Disposition headers only on genuine download endpoints.
For preview endpoints, return a safe representation (e.g., first page as image, or metadata JSON).
3. Avoid returning file contents in error responses.
Many frameworks accidentally dump file streams when an exception occurs. Wrap file operations in try‑catch and log errors without exposing data.
4. Implement response inspection in your CI/CD pipeline.
Use integration tests to verify that protected endpoints never return binary signatures:
Example test with curl and jq
response=$(curl -s -w "%{http_code}" -o /dev/null -X GET "https://dev.api/file/secret")
if [ "$response" -eq 200 ]; then
curl -s "https://dev.api/file/secret" | head -c 4 | xxd -p | grep -q "504b0304" && echo "FAIL: Binary leak"
fi
- Use security headers and CSP to mitigate, but do not rely on them.
While `X-Content-Type-Options: nosniff` helps, it won’t stop an attacker from saving the raw binary. -
Testing Your Own Applications for Raw Binary Leaks
As a penetration tester or developer, you should proactively test for this vulnerability. Here’s a comprehensive methodology:
Step 1 – Map file access endpoints – Use Burp Suite’s spider or a tool like Gau to discover endpoints containing file, download, preview, get, id, doc.
Step 2 – For each endpoint, modify the request to simulate unauthorized access:
– Remove or replace session cookies.
– Change `id` parameter to a file belonging to another user.
– Use HTTP methods like `HEAD` or `OPTIONS` to see if binary is still returned.
Step 3 – Analyze responses with automation.
Example Python script using requests:
import requests
url = "https://target.com/api/file/123"
cookies = {"session": "invalid"} tampered
r = requests.get(url, cookies=cookies)
if r.status_code == 200 and r.content[:4] == b'PK\x03\x04':
print(f"VULNERABLE: {url} leaked ZIP binary")
with open("leak.zip", "wb") as f:
f.write(r.content)
Step 4 – Use Burp Intruder to fuzz parameters and collect all responses where the body starts with common file magic bytes.
Windows tooltip: Use `findstr` on saved response files:
findstr /M /C:"PK" .bin
7. Beyond Files: Other Sensitive Data Leakage Risks
Raw binary leakage isn’t limited to file downloads. Any endpoint that returns sensitive structured data (e.g., private keys, database dumps, configuration files) as part of the response body can be exploited. Common examples include:
- API endpoints returning base64‑encoded binaries – decode and reconstruct.
- GraphQL introspection leaks – entire schema or file upload binaries.
- Cloud storage signed URLs – if the signed URL is returned in a response, an attacker can directly download the file.
- Error messages containing stack traces with file system paths or partial binaries.
Cloud hardening tip for AWS S3: Never return pre‑signed URLs in API responses that are accessible to unauthenticated users. Use temporary credentials or require the client to request the file through a backend that validates permissions each time.
Linux command to search for base64‑encoded ZIP in logs:
grep -E "([A-Za-z0-9+/]{4})([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)" access.log | \
while read line; do echo "$line" | base64 -d 2>/dev/null | head -c 4 | xxd -p | grep -q "504b0304" && echo "Potential leak"; done
What Undercode Say:
- Key Takeaway 1: Raw binary leakage is a subtle but critical vulnerability that completely bypasses access controls. Even if authentication is perfect, sending file contents in any response allows attackers to reconstruct the file locally.
- Key Takeaway 2: Burp Suite remains an essential tool for identifying such flaws—intercepting and inspecting responses for unexpected binary signatures should be part of every web application penetration test.
Analysis: The LinkedIn post highlights a real‑world scenario where a “protected” file was downloaded using nothing more than Burp Suite and a keen eye for raw binary data. This vulnerability is surprisingly common in SaaS platforms, e‑learning systems, and document management applications. Developers often assume that if a user cannot click a download button, the file is safe—but HTTP doesn’t lie. Security teams must enforce strict response‑level controls, including automated checks for binary magic bytes in all API responses that are not explicitly download endpoints. As APIs become more complex, the risk of unintentional binary exposure grows, making this a top‑priority finding in any web application security assessment.
Prediction:
As more organizations shift to API‑first architectures and microservices, the incidence of raw binary leakage is likely to increase—especially in rapidly developed prototypes where file handling logic is duplicated across endpoints. Automated scanners will soon incorporate magic‑byte detection as a standard check, and bug bounty programs will pay higher bounties for such findings. In the next 12–18 months, we expect to see at least one major data breach attributed to this exact vulnerability, prompting OWASP to add or expand guidance on binary response leakage in the API Security Top 10. Mitigation will shift from manual code reviews to CI/CD pipelines that reject any response containing file signatures from non‑download endpoints.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mohammedalqi They – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
