(and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)

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://localhost/foo/../secretfile.txt the same way? Why does “..” in paths only work sometimes?

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.

Exposing email and private keys of GCP accounts only gives you $500 reward? WTF. Google being Google I guess.

Hunting for Nginx Alias Traversals in the wild

and the hn submission highlights the bitwarden vulnerability while there is a google one discussed as well.

If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?

> ...we started dwelving into the code base...

The author may not be a native speaker, but this is far from a judgement on their English. I'm just curious about the provenance of this mistake, given the scarcity of words that begin with "dw". At first I thought it was a typo -- especially on a QWERTY keyboard -- but I've seen it often enough to question this.

As an aside, I didn't know Github code search accepted regex.

Horse pucky. In those days, Apache httpd held dominant market share. Nice historical hijacking.

> This vulnerability has been disclosed to Bitwarden and has since then been fixed. Bitwarden issued a US$6000 bounty, which is the highest bounty they issued on their HackerOne program.

That's a ridiculously low payout.

https://book.hacktricks.xyz/network-services-pentesting/pent...

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.

That fully depends upon the file permissions. In this case, let's assume that a user has permissions to read files all the way from the web index directory (../index.html) back to the root directory (/). At that point, since they have permission to traverse down to the root directory, they now have permission to view any world viewable file that can be traversed to from the root directory, for instance /etc/passwd.

In other words, imagine a fork with three prongs, and your web server resides on the far right prong. Imagine that the part of the fork where the prongs meet (the "palm" of the fork) is the file system. If your web server residing on the far right prong of that fork allows file permission to files and directories that lead all the way to the palm of the fork, at that point you could continue accessing files on other prongs once you have reached the palm.

(FreeBSD has this in ordinary openat(2) as O_RESOLVE_BENEATH.)

You could just run nginx as a separate user with very limited rights, or just run it on Docker. This, plus updating regularly usually fixes 90% of security issues.

    /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

If you are serving files to web from the folder, the web framework should handle not taversing the public root folder it was tasked to serve. If are rolling your own, well now you have to consider all kinds of stuff, including this.

Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a hardened container image and a hardened NixOS module.

I wouldn't recommend Caddy. Their official docker image runs as root by default [1], and they don't provide a properly sandboxed systemd unit file [2].

[1]: https://github.com/caddyserver/caddy-docker/issues/104

[2]: https://github.com/caddyserver/dist/blob/master/init/caddy.s...

EDITED: phrasing

https://github.com/troglobit/merecat/

Treat any web request like you would a real user on a Linux system you'd need to give access to to download files via scp. Chroot, strict permissions, etc. Can't escape what you can't escape. A ../ should return the same as expected in the shell, permission denied

It's LITERALLY app hosting 101 and people did it that way 20+ years ago.

It may require more fiddling with group memberships, but it's well worth it.

Probably really screwing things up. Ouch.

Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root.

A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...