Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirect hardening #1460

Merged
merged 4 commits into from
Nov 5, 2024
Merged

Redirect hardening #1460

merged 4 commits into from
Nov 5, 2024

Conversation

charmander
Copy link
Contributor

@charmander charmander commented Nov 1, 2024

Note

As a security fix, this is already deployed.

As far as I know, the `urllib.parse`-based filtering is safe, but there’s no legitimate way for the `GET` handler to receive a `referer` – the entire handler is only there in case someone manually goes to their browser’s address bar and loads the current address while in the middle of 2FA, and possibly shouldn’t exist at all.
Just applying normal good practice to a key place; as far as I know, nothing was exploitable.
instead of filtering just on the 2FA endpoint – for consistency.
Of course it was exploitable!

This is “fixed” in WebOb 1.8.8, but it’s not really WebOb’s responsibility to turn `Location: //…` into an absolute URL where the value is treated as a path-absolute URL. In fact, since RFC 7231 (the latest HTTP/1.1 specification), `Location` doesn’t need to be absolute; WebOb shouldn’t touch it at all. Treating the value differently from clients is bound to cause confusion (e.g. when we move away from WebOb, would this have been a problem waiting to happen?). WebOb’s current fix is to alter the prefix to `/%2f`, which is *semantically different*.

WebOb 1.8.8 also checks for the specific prefix `"//"`, but it still uses `urljoin`, which will happily cause exactly the same problem with `" //evil.example"` (substitute tab for space on older patches of Python, e.g. 3.10 before 3.10.12 (CVE-2023-24329)). That’s not an issue for what’s probably the most common way to have this open redirect vulnerability – what we did, echoing the request path – but, again, it’s not WebOb’s issue in general.

Finally, we should probably just redirect to slash-normalized URLs globally before even getting to the Python layer, but… another time.
@charmander charmander merged commit 4a6930a into Weasyl:main Nov 5, 2024
4 checks passed
@charmander charmander deleted the redirect-hardening branch November 5, 2024 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant