goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't usually go that far. Usually the script name roughly corresponds to the name of a table (or database view), and the PATH_INFO corresponds to the primary key.
Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this.
If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't.
1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists.
2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661.
3. The attack then depended on a bug in dbus, CVE-2018-10662
4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection.
So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
> It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin
The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.
a.srv ended up in PATH_INFO because index.html existed.
The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.
MultiViews doesn't let HTML files have PATH_INFO by default. Only files that Apache considers "scripts" get PATH_INFO (e.g., .php). Therefore /index.html/a.srv would normally return 404 Not Found, even with MultiViews on.
They could have done further configuration to let HTML files take PATH_INFO, but this Rube Goldberg machine of multiple mistakes bears no more connection to MultiViews than mod_rewrite. In fact, I see no mention in the article of MultiViews or its module, mod_negotiation. So how do we know they were using MultiViews and not mod_rewrite, which people use much more often for this amount of indirection?
Either way, this exploit is impossible in the original suggestion, to just use MultiViews with PHP files to remove the ".php"
You know, to this day, if someone came to me and said "we want to run a site for five years on an LTS Linux distro release on a fairly weak machine, with auto-updates to system packages but no other maintenance intended. We're not gonna bother with monitoring or whatever. It's mostly static but it'll have a small dynamic component, say 500 LOC worth, maybe. If we ever have to manually touch this thing aside from maybe bouncing it once or so a year we'll consider that a failure. What should we use?" I'd probably say... Apache and PHP.
Sometimes I'm in the middle of messing with the Lovecraftian horror that is the modern JS stack or screwing with extracting what I need from whatever awful request object someone cooked up or any number of other things that aren't accomplishing anything of business value and I wonder whether maybe somewhere we veered way in the wrong direction, as an industry.
I've seen that Nginx can remove the .php suffix, with its try_files directive. but I haven't see how it can handle PATH_INFO of arbitrary length. Can you point me to the documentation that you're thinking about?
