Apache incorrectly resolves requests with paths starting with /index.php/

Question

In reviewing access logs I've noticed the below automated vulnerability scan for which Apache is returning a 200 status:

POST /index.php/api/Uploadify/preview HTTP/1.1

There's isn't a rewrite rule in place for this VHost and the file/URL doesn't exist. I can't seem to find an Apache directive for this and Google is convinced that I want to create this behaviour, not disable it.

Can someone explain to me to why Apache resolves this URL, and/or how to make it return a 404?

Answer 1

Apache's AcceptPathInfo

This behaviour is controlled with the AcceptPathInfo Directive in both Apache 2.2 and 2.4:

This directive controls whether requests that contain trailing pathname information that follows an actual filename (or non-existent file in an existing directory) will be accepted or rejected. The trailing pathname information can be made available to scripts in the PATH_INFO environment variable.

For example, assume the location /test/ points to a directory that contains only the single file here.html. Then requests for /test/here.html/more and /test/nothere.html/more both collect /more as PATH_INFO.

By default

• core handler rejects PATH_INFO for normal files

• other handlers like mod_cgi, mod_isapi or mod_php generally accept PATH_INFO.

If you want explicitly disable this for all handlers, use:

AcceptPathInfo Off

PHP-FPM

The AcceptPathInfo doesn't seem to work with PHP-FPM e.g. if there's a proxy handler like this:

<FilesMatch "\.php$">
    SetHandler  "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"
</FilesMatch>
<Proxy "fcgi://localhost/">
</Proxy>

In that case you could e.g. forbid access to all URLs containing .php/.

• Apache 2.2 LocationMatch & Access Control:

  <LocationMatch ".php/">
      Order deny,allow
      Deny from all
  </LocationMatch>
  

• Apache 2.4 LocationMatch & Access Control:

  <LocationMatch ".php/">
      Require all denied
  </LocationMatch>