A recently tracked vulnerability, CVE-2024-45336, is making waves in the web security community. This bug, found in the handling of HTTP redirects, may cause sensitive headers—like Authorization—to unintentionally leak to unintended domains after a series of cross-domain and same-domain redirects.

Let’s break down how this works, what the impact can be, and see an example in real code.

When your application makes an HTTP request, it might add headers like

Authorization: Bearer my-super-secret-token

Suppose you request

GET https://a.com/

If a.com responds with a redirect (HTTP 302) to b.com, most HTTP clients understand the risks and will drop sensitive headers for the redirected request to avoid leaking your secrets.

First Redirect:

a.com/ (with Authorization header)

→ redirects to →

b.com/1 (no sensitive headers sent, as expected)

Second Redirect (same-domain):

b.com/1 (no sensitive headers, as above)

→ redirects to →

b.com/2

The problem?

Since you never meant to trust b.com with your authorization secret, this can be a critical leak!

Let’s say an attacker somehow gets you to visit

https://a.com/

Your client sends an Authorization header for a.com.

First redirect:

a.com → 302 redirect → https://b.com/steal

Second redirect:

b.com/steal → 302 redirect → https://b.com/yourtoken

Now, most libraries see this as a "safe" same-domain move.

- The client restores the sensitive header, so Authorization: ... is now sent to b.com/yourtoken!

If b.com is controlled by an attacker... your authorization token is now in their hands.

Code Example (Python’s requests, before patch)

import requests

headers = {
    "Authorization": "Bearer my-secret-token"
}

r = requests.get("https://a.com/", headers=headers, allow_redirects=True)
print(r.url)

If a.com redirects to b.com/1 and then to b.com/2, your Authorization header could end up on b.com/2.

Simulated Flask Servers

Here’s a quick Flask setup to test this locally.

# server_a.py
from flask import Flask, redirect
app = Flask(__name__)

@app.route("/")
def root():
    return redirect("http://localhost:5001/step1";)

# server_b.py
from flask import Flask, redirect, request
app = Flask(__name__)

@app.route("/step1")
def step1():
    return redirect("http://localhost:5001/final";)

@app.route("/final")
def final():
    # This should not get your token, but it might!
    print("Headers received at /final:", dict(request.headers))
    return "Final!"

Run both servers, then do

import requests
headers = {"Authorization": "letmein"}
requests.get("http://localhost:500/";, headers=headers, allow_redirects=True)

Check the output in server_b’s logs—do you see "letmein"? If so, your HTTP library is vulnerable.

Original References

- GitHub Security Advisory for Python Requests
- CVE Detail Page (example)
- Red Hat: CVE-2024-45336
- OWASP: Insecure Redirects

Why This Matters

If your backend or automation uses popular HTTP libraries (think Python requests, Go http.Client, Node.js axios, and others) and you’re passing secrets in headers, you might be leaking them across trust boundaries without realizing it!

APIs: Third-party APIs receiving tokens not meant for them.

- SSO/Authentication: Credentials meant for internal domains get sent out.

Audit redirect chains and restrict which domains your apps allow.

For Python requests, apply patches corresponding to requests#6499.

Key Takeaways

- CVE-2024-45336 exposes sensitive headers via redirect chains that cross domains and then revert to referencing the same domain.

Audit dependencies quickly, and update vulnerable libraries.

Stay safe!
If your software follows HTTP redirects, audit your header-handling urgently. Even "safe" clients can have dangerous defaults.


*Exclusive post by AI for learning and awareness. Please cite responsibly.*

Timeline

Published on: 01/28/2025 02:15:28 UTC
Last modified on: 01/30/2025 19:14:21 UTC