3

Take a random PHP site. It is essentially guaranteed that its web server is configured as follows: serve any file from the document root, except for certain files or paths that are blacklisted. Scripts are also made executable using a similar model: all .php files are executable by the web server except the blacklisted ones.

ASP.NET is configured the same in IIS: *.aspx files are, by default, executable from any directory, and one is supposed to blacklist directories like a public "uploads" location to prevent vulnerabilities.

I don't know about other web servers, but in IIS it is entirely possible to flip this around, by removing all handler mappings and then whitelisting very specific files / paths. Given a well-structured codebase, one can have just two such mappings: a single mapping for a "/public/" to be served by the StaticFileHandler, and another mapping that maps "/index.php" - and nothing else - to the FastCgiModule. For ASP.NET, it's a bit more work, but if this were a goal, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.

Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?

RomanSt
  • 1,220
  • 10
  • 25
  • 1
    Short answer: Because properly making and maintaining whitelists is *hard*. – Iszi Sep 24 '14 at 22:46
  • @Iszi harder than maintaining security-hole-free blacklists? As someone who has made and maintained both, I have to disagree. – RomanSt Sep 24 '14 at 22:59
  • 3
    Harder than maintaining security-hole-free blacklists? Perhaps not. Harder than maintaining a blacklist that provides some security while still allowing the website to function? I should think so. Unfortunately, most businesses still place higher value (and dollars) on usability/functionality than security. – Iszi Sep 24 '14 at 23:41
  • 1
    cgi-bin is almost white-listed to the mod_cgi handler, in my experience. – jjanes Sep 25 '14 at 05:21

2 Answers2

4

Because web-server content changes frequently and it would be annoying to have to constantly add new files to a whitelist.

For ASP.NET, it's a bit more work, but if this were a goal, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.

But you don't typically deploy .aspx, .php files through a tool. You just drop them in the directory. It would require a huge change in how scripting languages work. They would cease to be scripting languages and become more like compiled languages.

Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?

Going the other way around would be based on the assumption that allowing user uploads is a normal use-case for everyone installing the webserver. Its not very likely that the majority of webserver instances allow user uploads, as most are undoubtedly corporate intranets or non-interactive sites that simply publish material to the user.

developerwjk
  • 157
  • 3
1

tl;dr: it is expensive

it works if you have

  • a waf that allows whitelisting + learning-mode
  • automated whitelist-generation
  • automated deployment-cycles and a full-blown testing/QA - environment that tests ANY new function and feature
  • good regression-testing
  • ...
that guy from over there
  • 3,494
  • 18
  • 28