121–130 of 165 posts
If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.
Earlier quoted context omitted.
I would assume most people that are doing self-hosted are securing it behind a VPN like Wireguard instead of opening it to the whole web. (at least I hope so)
I am not. Working well so far. My instance is behind Caddy, behind a secret URL path. To talk to the instance, this “pre-shares secret” needs to be known first. So far I haven’t seen any abnormal hits. I’m closing in on 3 years of using it in this setup, via Vaultwarden. I’m aware that this is security through obscurity. The instance’s accounts use strong passwords and MFA.
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 should pretty much 100% of the time be disallowed, there is no sensible use case that is not "someone wrote ugly code" ../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 all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.
I use https://static-web-server.net/ 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/c…
Earlier quoted context omitted.
/some/../path should pretty much 100% of the time be disallowed, there is no sensible use case that is not "someone wrote ugly code" ../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
I don't agree. Those kinds of paths are often result of concatenation of several configuration options. Like APP_DIR=/some/app/bin; LOG_DIR="$APP_DIR/../logs". And APP_DIR comes to you from distro scripts, so you're not going to fork those scripts and support your own fork across updates, you just build upon those scripts.
Okay so I self-host Vaultwarden, what do I need to do to fix the vulnerability? The article mentions another flavor of the self hosted docker image though.
But anyways, said vuln doesn't apply to vaultwarden.
[1] https://github.com/dani-garcia/vaultwarden/blob/19e671ff25bf...
How is this not seen as a vulnerability in nginx? This behavior is utterly absurd, seems to have no beneficial purpose, and straightforwardly exploitable.
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.
More likely it is an omission, which could be rectified with a warning or failure running nginx -t (verify configuration).
The actual performance comes from an architectural choice between event vs process based servers, as detailed in the C10k problem article. [1]
Earlier quoted context omitted.
It does have to do with BitWarden: they wrote and shipped the buggy config.
It looks like they did say it was still beta and warned there could be issues though. I'll give them credit for that much.
"Everything is in beta!"
> ...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.
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)