Classnotes | UNIX03 | RecentChanges | Preferences Showing revision 1 As we have said, CGI scripts are the best entrypoint for a potential cracker. This is because most CGI scripts are quick hacks produced by persons not familier with the security implications involved.
There are numerous ways to attack a CGI script: you could attempt to exploit some buffer-overflow, use the script to destroy data (perhaps the script is a front-end to a database), or simply try to insert tainted information into the script causing it to perform functions on the underlying filesystem that the administrator might not want. Because of these things, there are few fundamental design principles that should be kept in mind when researching a particular script:
Can the script run via an alternative interface? I.e., if it uses a database behind the scenes, can it instead interface with another non-CGI application that deals with the database? This can also mean whether or not the CGI can be run securely at certain intervals from a crob-job to generate static pages that are actually read by Apache.
