4 ms·

The vulnerability is happening because the web server is running as a user with elevated permissions. If it were running as a user who only had permissions to r

The vulnerability is happening because the web server is running as a user with elevated permissions. If it were running as a user who only had permissions to read files from the webserver's serving directory this would obviate the problem. Not that you shouldn't also validate input (in a whitelist rather than blacklist as others have said): just goes to show that security is a multifaceted problem with lots of ways to be paranoid. :)

nebulous1 10y ago
You don't need elevated privileges to read /etc/passwd
- daveloyall 10y ago
  That is correct. sebboh@namagiri:~$ ls -al /etc/passwd -rw-r--r-- 1 root root 1450 Jun 7 09:08 /etc/passwd So, there's this idea of running publicly facing services as a user which has less privileges than a normal interactive user. This user might be called 'nobody' or 'apache', etc. However, on your average distribution, /etc/passwd is accessible to the 'nobody' user or the 'apache' user. There are various work arounds: + run your service in a chroot or jail. + employ some kind of SE Linux thing. + ...? I've only ever used the first one.
  - delinka 10y ago
    Since ages now: https://en.wikipedia.org/wiki/Shadow_password https://en.wikipedia.org/wiki/Shadow_password
    - daveloyall 10y ago
      That doesn't mean you should allow your app to access `file://` ... (Nor allow it out of a chroot.) Simply knowing some usernames on your system could provide an attacker with clues...