5 ms·

Certainly disabling access to directories like .git, .svn or .hg should be default in any webserver. It is a pity to see this option not active by default in a

by ktpsns 8y ago

Certainly disabling access to directories like .git, .svn or .hg should be default in any webserver. It is a pity to see this option not active by default in a Debian/Ubuntu Apache2 installation, c.f. https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/conf.d/security https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/... which mentions it (1) only for svn and (2) has it commented out.

jolmg 8y ago
I feel that'd be like shoemakers putting metal plates on top of their shoes to prevent bullets from penetrating when customers shoot themselves in the foot. It's silly. Those same customers could shoot themselves in the leg (another software they misuse and expose .git/ from), or hurt their foot via some other method that the plate can't protect from (expose other non-git sensitive information via the webserver; i.e. the webserver can't predict all ways it can be misused). However, now I see you said it should be Ubuntu and not Apache that should do this default configuration. I guess that'd make a little more sense as Ubuntu could be interpreted in this analogy as the vendor of the boot, pants and gun, and is generally geared toward beginner cowboys. The real solution, though, would be for the customers to learn to use the gun properly. If they shoot themselves, then that's valuable experience they can learn from. If you put the metal plate, they might go on without realizing they're shooting themselves.
- judge2020 8y ago
  The difference being in this situation, shooting yourself in the foot can cause loads of confidential user information to be stolen by someone exploiting this (when storing DB credentials in SCM)
- ktpsns 8y ago
  In fact Debian ships Apache with a decent default setup which also allows further Debian packages to seamlessly hook into the configuration (with directories likes /etc/apache2/conf.available and /etc/apache2/conf.enabled and softlinks inbetween). Apache itself does not have any "default" configuration at all, it most likely also starts fine with an empty configuration file. Of course "fixing" security problems at the level of the web server feels like adding a firewall to your server instead of avoiding daemons listening on public ports. It feels wrong. But it can be seen as another layer of security.
- pjc50 8y ago
  This kind of anti-safety sentiment isn't based on a real consideration of user needs, just a victim-blaming machismo. Reminds me of mongodb shipping exposed to the internet by default. (You can of course buy shoes with metal plates in them to prevent injury, they're called "safety boots" and are mandatory in some workplaces)
  - jolmg 8y ago
    I'm not anti-safety, I'm anti-bad safety design. I clarified the point of the analogy in a reply to another reply. EDIT: You can't substitute gun safety knowledge with legislation that requires all things (and I mean all) to protect against gun misuse.
    - 21 8y ago
      Defense-in-depth is not bad design, it's good design.
- fake-name 8y ago
  Uh.... steel toed boots are a very common thing?
- mikeash 8y ago
  It would be more like car makers building cars that won’t engage the starter motor if the transmission isn’t in Park, garage door openers reversing if they encounter too much resistance, or lawn mowers that won’t run if you don’t hold down a safety bar. Which is to say, anti-footgun measures are extremely common anywhere foot-shooting is.
  - jolmg 8y ago
    The difference here, and the main point of my analogy is that webservers and git are completely unrelated things like shoes and guns are. That all webservers should guard against misuse with another random piece of software is like having all shoes have protections specifically against a random product that's completely unrelated to shoes. Also, to take the analogy further, the original suggestion was to guard against specific directories .git, .hg, etc. That's like having all shoes protect against only specific models of guns and not others. The point here is that if you want to take this methodology for security, then you'll have to come with an enumeration of all ways the user hurt himself and implement a safety measure for each. That's neither effective nor efficient. Think of all pieces of clothing being required to be bullet-proof, cut-proof, stab-proof, acid-proof, hunger-proof, suffocation-proof, smash-proof, etc. You can't have everything protect the user from everything else via having a safety mechanism for each model-specific thing.
    - mikeash 8y ago
      How is that different from my examples where they protect against certain common dangers but don’t even attempt to protect against all the ways you can hurt or kill yourself with them?
      - jolmg 8y ago
        That the safety mechanisms in your examples depend only of knowledge of the object's own mechanisms or generic "other things". For example, your garage door opener reverses when it encounters resistance from anything. It's not that it only reverses when there is one of a specific list of car models that are in its way, and continues to try to close when there is a human in its way or some other type of vehicle or thing. It'll work even if a new type of thing that never existed before gets in its way. It's also different in that it doesn't limit the products functionality when it thinks that you want to make an exception to its primary purpose. A garage door opener is not going to refuse to open when you're trying to come in with a vehicle on fire. A webserver serves files, and inside .git/ are files. You ask it to serve them, then its going to serve them. That you didn't realize you were coming into the garage with a vehicle on fire is no reason for the garage door opener to be required to implement a security mechanism for that very specific thing when there's loads more you could do without realizing.
DCoder 8y ago
It's interesting to compare this behaviour against IIS. If Apache can't identify the MIME type of the requested file, it will serve it without a Content-Type header. IIS will return a 404 instead.

by ktpsns 8y ago

jolmg 8y ago

I feel that'd be like shoemakers putting metal plates on top of their shoes to prevent bullets from penetrating when customers shoot themselves in the foot. It's silly. Those same customers could shoot themselves in the leg (another software they misuse and expose .git/ from), or hurt their foot via some other method that the plate can't protect from (expose other non-git sensitive information via the webserver; i.e. the webserver can't predict all ways it can be misused). However, now I see you said it should be Ubuntu and not Apache that should do this default configuration. I guess that'd make a little more sense as Ubuntu could be interpreted in this analogy as the vendor of the boot, pants and gun, and is generally geared toward beginner cowboys. The real solution, though, would be for the customers to learn to use the gun properly. If they shoot themselves, then that's valuable experience they can learn from. If you put the metal plate, they might go on without realizing they're shooting themselves.

judge2020 8y ago
The difference being in this situation, shooting yourself in the foot can cause loads of confidential user information to be stolen by someone exploiting this (when storing DB credentials in SCM)
ktpsns 8y ago
In fact Debian ships Apache with a decent default setup which also allows further Debian packages to seamlessly hook into the configuration (with directories likes /etc/apache2/conf.available and /etc/apache2/conf.enabled and softlinks inbetween). Apache itself does not have any "default" configuration at all, it most likely also starts fine with an empty configuration file. Of course "fixing" security problems at the level of the web server feels like adding a firewall to your server instead of avoiding daemons listening on public ports. It feels wrong. But it can be seen as another layer of security.
pjc50 8y ago
This kind of anti-safety sentiment isn't based on a real consideration of user needs, just a victim-blaming machismo. Reminds me of mongodb shipping exposed to the internet by default. (You can of course buy shoes with metal plates in them to prevent injury, they're called "safety boots" and are mandatory in some workplaces)
- jolmg 8y ago
  I'm not anti-safety, I'm anti-bad safety design. I clarified the point of the analogy in a reply to another reply. EDIT: You can't substitute gun safety knowledge with legislation that requires all things (and I mean all) to protect against gun misuse.
  - 21 8y ago
    Defense-in-depth is not bad design, it's good design.
fake-name 8y ago
Uh.... steel toed boots are a very common thing?
mikeash 8y ago
It would be more like car makers building cars that won’t engage the starter motor if the transmission isn’t in Park, garage door openers reversing if they encounter too much resistance, or lawn mowers that won’t run if you don’t hold down a safety bar. Which is to say, anti-footgun measures are extremely common anywhere foot-shooting is.
- jolmg 8y ago
  The difference here, and the main point of my analogy is that webservers and git are completely unrelated things like shoes and guns are. That all webservers should guard against misuse with another random piece of software is like having all shoes have protections specifically against a random product that's completely unrelated to shoes. Also, to take the analogy further, the original suggestion was to guard against specific directories .git, .hg, etc. That's like having all shoes protect against only specific models of guns and not others. The point here is that if you want to take this methodology for security, then you'll have to come with an enumeration of all ways the user hurt himself and implement a safety measure for each. That's neither effective nor efficient. Think of all pieces of clothing being required to be bullet-proof, cut-proof, stab-proof, acid-proof, hunger-proof, suffocation-proof, smash-proof, etc. You can't have everything protect the user from everything else via having a safety mechanism for each model-specific thing.
  - mikeash 8y ago
    How is that different from my examples where they protect against certain common dangers but don’t even attempt to protect against all the ways you can hurt or kill yourself with them?
    - jolmg 8y ago
      That the safety mechanisms in your examples depend only of knowledge of the object's own mechanisms or generic "other things". For example, your garage door opener reverses when it encounters resistance from anything. It's not that it only reverses when there is one of a specific list of car models that are in its way, and continues to try to close when there is a human in its way or some other type of vehicle or thing. It'll work even if a new type of thing that never existed before gets in its way. It's also different in that it doesn't limit the products functionality when it thinks that you want to make an exception to its primary purpose. A garage door opener is not going to refuse to open when you're trying to come in with a vehicle on fire. A webserver serves files, and inside .git/ are files. You ask it to serve them, then its going to serve them. That you didn't realize you were coming into the garage with a vehicle on fire is no reason for the garage door opener to be required to implement a security mechanism for that very specific thing when there's loads more you could do without realizing.

DCoder 8y ago

It's interesting to compare this behaviour against IIS. If Apache can't identify the MIME type of the requested file, it will serve it without a Content-Type header. IIS will return a 404 instead.