Web Site Security Issues - HTML

Now that we have covered most of the general risks, let’s examine risks and solutions specific to the Web.

File permissions
A good understanding of the underlying file system on any system you use is essential to maintaining a secure system. Insufficient permissions will cause problems for your visitors—overly generous permissions can expose critical information you would rather not reveal.

When deploying a Web site, consider what rights and file ownership is truly necessary. Whenever possible assign rights to the Web server instead of general users. For example, on a Linux system where the Apache server runs as user www-data, the following permissions may be enough for your documents:

In the preceding example, the file is owned by your user ID, with read, write, and execute permissions. The group ownership is set to the user ID that the Web server runs under. The group permissions only allow read and execute, the minimum permissions necessary for the server to serve the file.

Unused but open ports
Any open port on a server presents a vulnerability that could be exploited. As such, it’s important to only have the ports open that you really need. First and foremost, shut down and even uninstall any services that you don’t need. For example, if you don’t need an FTP server, don’t even install one.

The next step is to perform a port scan on your system to see what ports are open that you may not know about. There are many ways to perform a port scan, including the following:

Use your browser and visit one of the online port scanners, such as the one at DSL Reports or the Shields Up scanner at Gibson Research

• Use a scanner application.
• Use a telnet application to probe certain ports for activity. For example, the following command will attempt to connect via the SMTP port (25) of the local machine: telnet localhost 25

CGI scripts
Common Gateway Interface (CGI) scripts are common targets for hackers. Many CGI scripts are poorly written from a security perspective, allowing savvy hackers to exploit them in various ways. Some exploits were fairly benign, such as using the formmail CGI script on a server to send anonymous e-mail (typically spam). Other CGI exploits are very dangerous, allowing hackers admin access to your server.

Whenever using CGI scripts, consider the following:

• Don’t overly expose your CGI scripts. Avoid calling them where they will show in the browser’s address bar with explicit arguments.
• Use CGI scripts from reputable sources and do some research into any security issues regarding the scripts you use.
• Use intelligent file ownership and permissions with your scripts (see the File permissions section earlier in this section). Assign rights to the Web server user instead of the world, and protect your CGI directories from browsing.
• Follow the same rules with your scripts that you do with your operating system and applications—audit their logs and update them as necessary to avoid issues.

Buffer overflows
Buffer overflows are widely used exploits. The concept of a buffer overflow is fairly simple: force an application to accept more data than it expects, causing it to overwrite other data in memory with specific data. For example, consider the following:

1. An application calls a subroutine, placing the address of the calling code on the memory stack so it can return after execution.
2. The subroutine’s data is also mapped via the stack.
3. An exploit creates an overflow in the data area, causing new data (a new return address) to be written as the subroutine’s return address.
4. The subroutine returns to the new address, typically accessing previously placed rogue code, a privileged command prompt, or other exploitable environment.

This is only one example of how a buffer overflow exploit can be used. The cure for such exploits is to keep your software up-to-date, as most exploits are fixed quickly after they are found. Monitoring security updates and patches for your system is critical to avoiding this issue.

Compromised systems
There is no easy cure for a compromised system. Once the system has been compromised you can never be truly sure of the extent of the compromise. Typically, the following steps are the only recourse:

1. Isolate the system
2. Take stock of the damage, perhaps finding the method used to compromise the system
3. Back up any salvageable data
4. Reinstall the system from scratch, avoiding the component(s) that were compromised the first time