Re: User-supplied paths
In the HTTP protocol there are explicit places for communicating user-supplied variables - in the query string or POST body. So why, for the love of Tim, are they putting the (user-supplied) verification code in the request path?
While I agree, generally speaking, with the sentiment, the HTTP specification (RFC 2616 for HTTP/1.1) does not distinguish between the abs_path and query-string portions of Request-URI for this purpose, or between the Request-URI and the message-body. All of that data comes from the client (generally the user agent, though some intermediaries, such as proxies, may alter it), and all of it is untrusted.
The CGI 1.1 draft specification (never standardized) did explicitly allow program data in the abs_path (what you call "the request path" above). The actual CGI program can appear before the end of the abs_path, and any subsequent path components are passed to it as "PATH_INFO". It's up to the server to decide how the abs_path is partitioned between program-specifier and path-info. Presumably it does so by looking for a translated path component that refers to an executable and not a hierarchical container, though that distinction may be somewhat arbitrary on systems without hierarchical filesystems.
Of course, CGI is widely deprecated these days, and using this design pattern for anything security-related is almost certainly a terrible idea.