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?

4
  • 1
    Short answer: Because properly making and maintaining whitelists is hard.
    – Iszi
    Commented Sep 24, 2014 at 22:46
  • @Iszi harder than maintaining security-hole-free blacklists? As someone who has made and maintained both, I have to disagree.
    – RomanSt
    Commented Sep 24, 2014 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
    Commented Sep 24, 2014 at 23:41
  • 1
    cgi-bin is almost white-listed to the mod_cgi handler, in my experience.
    – jjanes
    Commented Sep 25, 2014 at 5:21

2 Answers 2

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.

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
  • ...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .