5

I understand that the files directory requires this in the .htaccess file:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

I know it prevents PHP from running in the files directory, but how does it work? Is SetHandler redirecting to a Drupal_Security_Do_Not_Remove_See_SA_2006_006 file that contains some code to prevent PHP files from running? If this is the case, where is this file?

  • 1
    Before this starts catching flags and close votes, I think this is on topic. Understanding why this works is important to learning more about Drupal security. – mpdonadio Jan 20 '17 at 4:30
  • 1
    Why does it work officially @mpdonadio? It's easy enough to infer that Apache is just as happy with being given an unregistered (non-existent) handler as a real one, but I couldn't find a reference – Clive Jan 20 '17 at 7:55
  • 2
    duckx, SetHandler does literally that - sets the file handler for a given context. In a PHP site that's going to be application/x-httpd-php more often than not, so without the directive any rogue php files that manage to get uploaded will be executed with the php handler if requested through the web. With the directive, those php files are benign as they would be executed with this non-existent handler, not php. As to the raw technical reason for it's working, I can't find a ref but I think what I mentioned in the previous comment is a reasonable assumption. there's no handler or action... – Clive Jan 20 '17 at 8:03
  • ...defined for that long string, ergo nothing special registered with Apache, so I think you're in "it works because Apache lets it" territory – Clive Jan 20 '17 at 8:05
  • 1
    It inherits from the vhost, then global settings. Global settings for .php files are usually to execute with the php handler, hence the problem – Clive Jan 21 '17 at 15:20
2

I believe what is happening is this: SetHandler is used to tell the web server how to 'execute' a file; its argument supplies the information required in a form specified by the actual handler modules.

The line in question sets the 'handler' to a value that has no meaning; there is no extension that can make use of it. Consequently, the web server, when something attempts to 'execute' a file controlled by this statement, fails.

Thus, the 'Drupal_Security_Do_Not_Remove_See_SA_2006_006' is not magic, nor does it refer to anything else (file or otherwise); it is simply a value with no meaning at all.

There is additional information in this post and those linked from it: https://www.drupal.org/node/652002

Not the answer you're looking for? Browse other questions tagged or ask your own question.