0

In the past, Apache used to serve cgi files from cgi-bin folder only, and it was always advised to avoid putting executable files in public folders. However, today's webservers fairly serve executable cgi file from everywhere.

What is the security risk for serving webpages directly from executable cgi files? For example, what is the risk for http://example.com/hello.cgi where executable file of hello.cgi is in the root (public) directory? (comparing with a non-executable PHP file of hello.php)?

Of course, cgi scripts are practically served via FastCGI to persist the connection, but does it have an better security too?

Improve this question

1 Answer 1

Reset to default
2

In short, separating CGI files, which are often scripts, makes it easier to ensure that the web server will never mistakenly return the text of the script to the client instead of executing the CGI and returning the results. If the script "source code" is revealed to the client, it may expose sensitive information, such as embedded database connection passwords or just information about how the script executes that could be abused by an attacker.

For example, the entire /cgi-bin directory is usually configured to execute files and never to return content. If you edit hello.cgi and leave an editor backup file hello.cgi~ behind, the server should never return that file as content if /cgi-bin is configured correctly. On the other hand, if that backup file is sitting in a normal web root that serves files, then the magic mapping of ".cgi -> execute" won't take effect for the hello.cgi~ file, and the server may therefore return the content of hello.cgi~ instead of executing it.

Improve this answer
4
  • I totally agree with the risk issues you quoted, but can't we overcome by include the actual code? I mean having hello.cgi with no code except including the actual code which is outside the public folders. Thus, upon a failure in webserver, nothing will be exposed except the full path to the actual script (which is inaccessible).
    – Googlebot
    Sep 26, 2012 at 18:28
  • If by this you mean having a file shell in the webroot which simply includes another file outside the webroot, you could do that, but it's more complex than simply segregating your scripts into a /cgi-bin directory with strict controls.
    – gowenfawr
    Sep 26, 2012 at 18:50
  • Also, to complicate the matter, newer languages like PHP permit you to mingle code and content within the same file, which was a major impetus for the shift away from /cgi-bin to inclusion of scripts within the webroot. So another aspect of the answer is "...and it used to make more sense, in the old days."
    – gowenfawr
    Sep 26, 2012 at 18:52
  • I am not against the idea of cgi-bin, but the point is that I use nginx not Apache, and the implementation of cgi-bin is not common in nginx or I am not aware of that.
    – Googlebot
    Sep 26, 2012 at 18:57

You must log in to answer this question.

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