Server-side includes (SSI) are server directives that are embedded into HTML documents, and can be used with CGI scripts. SSI allows you to obtain server information (such as the server’s date and time) or execute various system commands. The problem is that when used in an insecure script, or on a system that allows certain SSI commands to be used, a hacker can violate your system and perform a number of unwanted actions. Many Web servers allow you to turn off SSI, and some allow you to control which SSI com- mands will be enabled. Check your server documentation to see if your Web server allows you to determine which commands can be disabled. Due to the problems that can result from SSI, the best solution for security will be to disable SSI from your system, so that these commands can’t be exploited.
there are ways to get this information regardless of method used, and there is no substitute for good security there are some virtues to obfus- cation.The POST method should be used as an alternative.
Your script should set limits on the amount of data accepted, so that incorrect data will have a better chance of being ignored. For example, if a variable returns the last name of a person, you could set a length on the data being returned. By checking variables such as CONTENT_LENGTH, you could ignore excessive amounts of data being passed to the script, so that there is less chance that a hacker will pass large amounts of data in an attempt to crash the program.
The GET method should never be used when sensitive data is being sent to a CGI program.This is because any GET command will appear in the URL, and will be logged by any servers. For example, let’s say that you’ve entered your credit card information into a form that uses the GET method.The URL may appear like this: http://www.freebsd.com/ card.asp?cardnum=1234567890123456. As you can see, the GET
method appends the credit card number to the URL.This means that anyone with access to a server log will be able to obtain this information.
Never include sensitive information in a script.At times, you may find it useful to include usernames and passwords in your CGI program, or have this information passed from form data to a database. If included in your code, you should remember that hackers who can access source code would be able to view this information. If you are using a com- piled language, then this will be more difficult to obtain. Regardless, you should never give more information than is absolutely necessary. By including passwords and usernames in your code, you are creating a pos- sible security risk.
Never give more access than is absolutely necessary.In the same light, you should never provide more access than is absolutely necessary for a user to complete a necessary task.This not only applies to permissions you assign to various user accounts on your server, but also user accounts that your CGI program uses to access data. For example, if your program accessed a SQL Server database, then you wouldn’t want to use the “sa” account (which is the system administrator account). By giving this sig- nificant power to a user, a hacker may take advantage of it and acquire access to sensitive data.
Program on a computer other than the Web server, and ensure temporary files and backup files of your scripts are removed from the server before your site goes live.You should program your CGI scripts and programs on a computer other than the Web server. In doing so, you will avoid the possibilities of hackers modifying your code as a program is being written.This will also lessen the chances of hackers accessing temporary and backup files on the hard disk. If you are using languages such as C or C++, then your code is compiled before it is available for execution on the Web server.This may make you think that no one can read the source code. However, even if you’ve removed the source code for your CGI pro- gram from the Web server before your site goes live, you should ensure that no backup or temporary files are left on the server.These may be created when programming the code, and hackers who access these files may access the files and view your source code.
Double-check the source code of any third-party CGI programs.If third- party CGI programs are used, you should review the source code for any possible security holes. A simple way to acquire access to a server would be to make a CGI program available to others, and include code that sends information to the author. Looking over the source code of the program before making it available on your site can identify this threat. If a CGI program doesn’t make its source code available, and you are unsure whether the author is trustworthy, then you should avoid using the program altogether.
Test your script by entering data that does not mimic the activities of a normal user to try to force unpredictable behavior.Testing is always an impor- tant part of any programming. Before making your CGI programs avail- able to the public, you should test them thoroughly. Use a variety of different user accounts, including that of an anonymous user, so you can see who can access the script and whether it will work with the proper accounts.Try inputting incorrect data to see how your script deals with problems. By putting your CGI script through the paces of dealing with various input and problems, you can find problems before a hacker does.