Channels of Information

only for RuBoard - do not distribute or recompile

Web applications involve the flow and storage of information, and the goal of security is to protect that information so that it can t be seen or modified except by the appropriate parties. For a typical database-backed Web application, information travels through several conduits, all of which are points of attack that are subject to inspection or subversion. Opportunities for compromise present themselves in many ways:

• One information channel goes over the network between the Web server and the clients that access it. Potential insecurities include having the connection wiretapped by a third party or having the client himself submit false information or excessive amounts of information in an attempt to mislead or overwhelm your application.

• Information flows between Apache and the MySQL server. Traffic over this channel may be subject to snooping.

• The Apache server executes Web scripts and those scripts in turn may read and write files or connect to the MySQL server. By default, all Web scripts run with the privileges of the user and group IDs under which Apache itself runs. This means that if several people have permission to install scripts for the Web server to execute, one person s script may gain access to another person s Web-related files.

• People sometimes store MySQL connection parameters (such as usernames and passwords) in files. Failure to protect these files from inspection by other users can lead to unauthorized database access.

• MySQL itself stores information in database tables that are represented by files. These files should be accessible only to the MySQL server. In a poorly administered installation, other people with login accounts on the server host may be able to bypass the server and access database files directly.

The dangers related to these various sources of information interact, such that a weakness in one area can lead to exploits in another area. If you have scripts that perform database operations, you might store MySQL connection parameters in a file for use by those scripts. Another person who has no MySQL access but can install Web scripts may be able to write a script that, when run by Apache, gains access to your parameter file and uses its contents to access your databases. In this way, file system access translates into database access. This issue may concern you particularly if you have a Web-hosting account with an ISP on a server shared by many other users about whom you know nothing and have little reason to trust.

Feeling nervous yet? You should. Nevertheless, there are a number of techniques for dealing with such problems:

• To guard against the dangers posed by clients who submit bad data to an application (either deliberately or just by mistake), the application should validate anything it cannot afford to take for granted.

• Keeping Web scripts and files secure involves proper file ownerships and access permissions. It also helps to keep executable scripts outside the Web server document tree. However, file security is difficult to achieve if multiple users have access to the Web server. Under some circumstances you may need to consider moving your installation to a different provider.

• Managing access to the MySQL server s data directory is a matter of properly setting up file permissions and user ID under which the server runs, and of keeping the MySQL account names and passwords secure.

• To protect information from being intercepted and inspected as it travels over a network connection, you can use an encrypted channel.

The following sections discuss these issues in more detail and outline your options for preventing problems.

only for RuBoard - do not distribute or recompile