| Author | Post |
|---|
Martin
Member
| Joined: | Tue Jun 14th, 2005 |
| Location: | |
| Posts: | 66 |
|
Posted: Tue Dec 5th, 2006 05:28 pm |
|
My hosting provider is going to move accounts to a new server and I seem to need to re-upload files and re-install everything:-(.
I do have a question though. I thought that the use of the cgi-bin was obsolete? Am I mistaken or is the cgi-bin indeed no longer really neccessary?
Because according to their helpfile I am still forced to use the cgi-bin for cgi and pl files.
Martin
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Tue Dec 5th, 2006 10:07 pm |
|
Martin
The cgi-bin has been obsolete since 1996. In fact, over the years, the cgi-bin has been the source of the biggest security flaw Apache has ever had.
Prior to that date Apache did not support file extensions. So the only way you could tell Apache that a file was to be executed was to put it in the CommonGatewayInterface-Binaries (cgi-bin) directory. Why "binaries"? Because you could also put compiled c and bash programs in there too.
In 1996 Apache added support for extensions with the AddHandler cgi-script .cgi .pl directive. You can actually make any extension an executable with the AddHandler directive.
But, how did Apache ever know that a cgi-bin was the executable repository in the first place. That was defined in the httpd.conf by the ScriptAlias value. You could make any directory the executable repository, such as cgi-sbin. And, every file in that directory's path would be processed as an executable. So, when Apache came out with the AddHandler directive they also added the Options +ExecCGI directive. If that directive is applied to a directory then Apache will execute any files in that path tree that matches the extensions in the AddHandler. Yeah, it actually took Unix people a half a frickin decade to figure something that simple out!!
But, then we get into the idiotic culture of Unix. The term "unix security" has never been about unix being a more secure platform, it's always meant "job security" for the super-user on a unix system On unix the super-user is a tyrant. Understand that when the web came along all webmasters were unix system admins who moved over from the corporate/academic unix main frame culture where these petty tyrants had held businesses hostage for ten years, and today still terrorize most universities (tenure fallout). These dick-weeds still infest the web with their presence at an alarming proportion. And to put it quite bluntly, people like Apache, Plesk, CPanel, etc. are still intimidated by them, which is why all systems still ship to satisfy these dick-weed grey beards.
Example: For over 5 years if you ran Perl & PHP on an Apache server you had a gaping security hole, and everyone at Apache, Perl, and PHP knew it. It took 5 years to come up with the suExec utility that closed that hole. But, Apache still ships with suExec not running - why, because they are afraid of exposing the fact that those old grey-breads were full of crap for 5 years claiming there was no hole when they knew damned well there was indeed a hole.
To this day, all unix/Apache systems still install by default to use the cgi-bin, in deference to an idea that has been obsolete for ten years. Pity their wives, these guys are probably a real bore in the bedroom. For a few years even Microsoft played this game by defaulting to require a cgi-bin (the old NT server days).
But, end of story. If your server will not execute a cgi script anywhere in the domain path, then you can fix the damned server to run in the 21st century instead of the 20th century. Place a file named .htaccess in the path of your cgi script (either in the same directory or even in the domain's home directory). The period at the beginning means that it is a "hidden" file so your FTP client may not show the file until you change the FTP client's options to "Show Hidden Files". In the .htaccess file put the two lines
Options +ExecCGI
AddHandler cgi-script .cgi .pl
If you have FrontPage Extensions you already have a .htaccess file - you can just add those two lines at the bottom of that file. If you've never used an .htaccess and don't know if your FTP client can "see" it, place an .htaccess file in an empty directory before you try it anywhere else. If, for some reason you can not "see" it and can't get your FTP client to "show" it, you can always delete the directory to get rid of it. Why is this important? Because you MAY need to immediately get rid of an .htaccess if your server is set up to not allow you to add .htaccess files. That's right, these petty two-bit tyrants can still keep you from doing this with the AllowOverride directive in the httpd.conf file for Apache. If AllowOverride does not allow Options in .htaccess files Apache can not access anything in that directory until you remove the Options or the .htaccess file itself. Consider this scenario: putting an .htaccess in your domain's home directory with Options set and then discovering that you can not make your FTP client "show" you the file, then discovering that Options are not allowed and Apache can not access any of the pages in your domain until you can fix the .htaccess. DON'T get yourself in that position.
If your webserver's admin tells you that you have to run a script in a cgi-bin for security reasons, do the world a favor and kill the lying bastard (slowly), then go find a real host to work with.
|
Current time is 10:18 pm | |
|
|
|
