-
Notifications
You must be signed in to change notification settings - Fork 258
feat: Add random path probing to bypass Next.js middleware redirects #28
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
base: master
Are you sure you want to change the base?
Conversation
|
Hi @fatguru - we should be sending the POST to both the index, and any on-site redirected path, are you seeing behaviour that doesn't show this? |
# FIX: Use the redirection from the POST response directly. Calling resolve_redirects() sends a HEAD request, which often receives a 200 OK on Next.js/RSC apps instead of the 307/303 triggered by POST.
|
Hi @infosec-au / Shubs, Thanks for the follow up. I have updated the branch with the fix. I also deployed a live reproduction case on Vercel to demonstrate exactly why relying on HEAD requests (resolve_redirects) causes false negatives on Next.js environments using Middleware. The Logic Flaw: Next.js Middleware often behaves differently based on the HTTP Verb.
Because the current scanner uses HEAD to check for redirects, it receives a 200, assumes there is no redirection, and fails to follow the attack path. Live Proof of Concept: Target URL: https://nextjs-middleware-a5780xxfd-fatgurus-projects.vercel.app/ Middleware Logic: Source Code (Redirects POST on root to /pwned). Verification Logs: I ran both versions of the scanner against this PoC.
Result: Scanner stops here. Never probes /pwned.
Result: Scanner successfully follows redirect and probes /pwned.(Note: Status 405 is expected here as the PoC endpoint doesn't accept POST, but it confirms the scanner reached the target destination). The code is updated and ready for review. Cheers! |
|
Hi @infosec-au any news regarding this? Tnx! |
Hi Team,
This PR addresses False Negatives caused by
middleware.tsredirects on the root path (/).The Problem:
Currently, the scanner defaults to probing
["/"]. In many Next.js deployments, the root path redirects (e.g.,307to/login). This redirection often strips the POST body before the RSC parser processes it, causing the scanner to miss vulnerable targets.The Fix:
I updated the default logic to probe both
/AND/{random_string}.Hitting a non-existent path triggers the Next.js Global Not Found handler (which is an RSC). This forces the server to parse the payload regardless of authentication middleware or root redirects.
Issue associated: Fixes #27
Cheers!