111–120 of 165 posts
FWIW gixy (nginx configuration checker) catches this: https://github.com/yandex/gixy/blob/master/docs/en/plugins/a... (and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)
Earlier quoted context omitted.
It's done for speed. Straightforward text replacement is so much faster than checking to see if a path is properly terminated by a slash. And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2.
> And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2. More like because it was much faster out of the box, and came with many batteries included while Apache2 required mods to be separately install.
Earlier quoted context omitted.
That has been a known issue in nginx for a very long time and its a common attack vector at CTFs: https://book.hacktricks.xyz/network-services-pentesting/pent...
There is a LFI vulnerability because: /imgs../flag.txt Transforms to: /path/images/../flag.txt I've only implemented a handful of HTTP servers for fun, but I've always resolved relative paths and constrained them. So I'd turn "/path/images/../flag.txt" into "/path/flag.txt", which would not start with the root "/path/images/" and hence denied without further checks. Am I wrong, or, why doesn't nginx do this?
At risk of asking a dumb question, is there any good reason that you’d want nginx to allow traversing into “..” from a URL path? It just seems like problems waiting to happen. Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. http://localhost/foo../secretfile.txt gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret http…
In this case part of the URL is being interpreted by nginx as a directory (http://localhost/foo) due to how that URL is mapped in the configuration to the local filesystem. Apparently it references a directory, so when nginx constructs the full path to the requested resource, it ends up with "${mapped_path}/../secretfile.txt" which would be valid on the local filesystem even if it doesn't make sense in the URL. Notice how the location of the slashes doesn't matter because URLs don't actually have path elements (even if we pretend they do), they are just strings.
This is a very common problem that I have noticed with web servers in general since the web took off. Mapping URLs directly to file paths was popular because it started with simple file servers with indexes. That rapidly turned into a mixed environment where URLs became application identifiers instead of paths since apps can be targeted by part of the path and the rest is considered parameters or arguments.
And no, it generally doesn't usually make sense to honor '.' or '..' in URLs for filesystem objects and my apps sanitize the requested path to ensure a correct mapping. It's also good to be aware that browsers do treat URLs as path-like when building relative links so you have to be careful with how and when you use trailing '/'s because it can target different resources which have different semantics on the server side.
OK hear me out: a Linux capability like option that removes the .. option from the kernels file name parser. Like web apps have been seen various bypasses involving somehow smuggling two dots somewhere since we were on dial up modems. It's time to look for a way to close this once and for all, as the Linux kernel has done with several other classes of user land bugs.
/some/../path
../some/path makes sense sometimes at least
... but I'd imagine it wouldn't as useful as you think it is, because many apps resolve .. before passing it to the OS
At risk of asking a dumb question, is there any good reason that you’d want nginx to allow traversing into “..” from a URL path? It just seems like problems waiting to happen. Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. http://localhost/foo../secretfile.txt gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret http…
That has been a known issue in nginx for a very long time and its a common attack vector at CTFs: https://book.hacktricks.xyz/network-services-pentesting/pent...
Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?
It's LITERALLY app hosting 101 and people did it that way 20+ years ago.