| ▲ | nick-sta 7 hours ago | |||||||
I’m not sure what the nextjs vulnerability is supposed to showcase - they’re putting secrets on their 404 page and relying on cloudflare to not show it? | ||||||||
| ▲ | tracker1 6 hours ago | parent | next [-] | |||||||
It's possible you're rendering more than just a simple 404, such as an SPA response or other result as part of an application response that may leak more information... I think it's not a severe issue in most cases, and maybe something worth noting or addressing if you are at least aware of it, you can just 404 without content, for example in the .well-known/ path. I run most of my apps behind Caddy, which handles that path itself and doesn't forward requests to that path, so I'm curious how it handles it tbh. I'm also not sure that there's a clear/good fix for this, since CF is allowing the traffic through so that ACME negotiation can work against the final application host. | ||||||||
| ▲ | nightpool 6 hours ago | parent | prev | next [-] | |||||||
Basically, it shows that Cloudflare's WAF (which is supposed to intercept requests before they make it to the origin server), is trivially bypassable by using the `.well-known/acme_challenge` path. That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated | ||||||||
| ▲ | cowsandmilk 6 hours ago | parent | prev [-] | |||||||
All their examples rely on having poorly configured origins. At least the PHP and Tomcat ones might be blocked by a WAF, but the Next.js one would rely on the WAF blocking responses that included secrets (which I’m not sure they do). | ||||||||
| ||||||||