141–150 of 165 posts
Earlier quoted context omitted.
Is this can work for mobile devices ?
Yeah, the full URL can be specified in Bitwarden clients (browser extension, mobile app) and then never touched again. The secret path only leaks if users use Bitwarden's sharing feature. It's not a "pre-shared secret" in that sense, as it can publicly leak by design.
Sharing features did you mean organization, bitwarden send ?
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.
If user gives your app a directory to play with, exiting that dir via ../something is the last thing you should do, it's horrible malpractice that just causes annoyance
"distro scripts" near always just show direct path to /var/lib/something for data and /usr/something for rest.
Earlier quoted context omitted.
Most (I hope all) distributions already run nginx as a separate user. It's best practice. But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).
There is no reason the web server needs to have access to the database file, the application that needs it should be running under a different user.
To be honest, I'm not sure if it's even possible to run the application/interpreter/cgi (e.g. php) as a child of the nginx process - though with Apache I'm still seeing that occasionally.
OT but this isn't the first time I've seen someone mistake the verb "delve" with "dwelve": > ...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 i…
>I'm just curious about the provenance of this mistake Because of English pronunciation (pronounciation? :-P). English is extremely irregular, there are a thousand of footguns in the language - both spoken and written -, so as non-native speakers we tend to make small mistakes that stick to our brains like glue, and it's very hard to get rid of (rid off? :-P). For me it kinda makes sense to say "dwelve" because it re…
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…
[Unit]
Description=Caddy webserver
Documentation=https://caddyserver.com/docs/
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service
StartLimitIntervalSec=14400
StartLimitBurst=10
[Service]
User=caddy
Group=caddy
# environment: store secrets here such as API tokens
EnvironmentFile=-/var/lib/caddy/envfile
# data directory: uses $XDG_DATA_HOME/caddy
# TLS certificates and other assets are stored here
Environment=XDG_DATA_HOME=/var/lib
# config directory: uses $XDG_CONFIG_HOME/caddy
Environment=XDG_CONFIG_HOME=/etc
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
# Do not allow the process to be restarted in a tight loop.
Restart=on-abnormal
# Use graceful shutdown with a reasonable timeout
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s
# Sufficient resource limits
LimitNOFILE=1048576
LimitNPROC=512
# Grants binding to port 443...
AmbientCapabilities=CAP_NET_BIND_SERVICE
# ...and limits potentially inherited capabilities to this
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# Hardening options
LockPersonality=true
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectControlGroups=true
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectSystem=strict
ReadWritePaths=/var/lib/caddy
ReadWritePaths=/etc/caddy/autosave.json
ReadOnlyPaths=/etc/caddy
ReadOnlyPaths=/var/lib/caddy/envfile
[Install]
WantedBy=multi-user.targetOK 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.
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)
I just gave nix a go and so far it seems great. But do you know, if they’re a nicer options finder? The one I found where you just search all several thousand options kinda sucks. I want to just see my package (say, ssh) and just the ssh options, but the results get littered with irrelevancy.
The title is significantly editorialized. The post title is: 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.
Earlier quoted context omitted.
>I'm just curious about the provenance of this mistake Because of English pronunciation (pronounciation? :-P). English is extremely irregular, there are a thousand of footguns in the language - both spoken and written -, so as non-native speakers we tend to make small mistakes that stick to our brains like glue, and it's very hard to get rid of (rid off? :-P). For me it kinda makes sense to say "dwelve" because it re…
Dwindling dwarves dwell dweep :)
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.