COM372: Notes, Chapter 17
Implementing Secure Transactions with PHP and MySQL
pages 379-398
Security Basics
Secure Transactions: Security is never absolute over a network, but you can make it very difficult to obtain information, to the point where it just isn't worth an attacker's time. You have to look at all points of transmission of information, from browser to server and back, and make sure all are secure.
Browser security: Users have control over browsers, and can disable cookies, JavaScript, or other browser tools that you may have been thinking of using in your security scheme. You also have no physical control over who has or will use the browser other than the intended user, if that machine is in a public place (library, internet cafe, etc.). This argues against using JavaScript for data validation. For the most control and security, do everything on the server.
Internet: Assume that malicious parties will trap your information as it passes over the internet. You might transmit non-secure information (basic page content), digitally sign before transmitting, encrypt, or keep it off the internet. Don't assume that anyone is who they claim to be, or that they are honest (see repudiation, chapger 15). Use Secure Sockets Layer (SSL) or Secure HTTP (S-HTTP)for private, tamper-resistent messages.
Server: Given a physically secure server with up-to-date applications software and security patches, you are most of the way there toward having a secure system. Make sure you know what you are doing as you set up users, accounts, access privileges, etc., for both you web, ftp, and database access. Also, make sure that your scripts are handling your data the way you think they are, by debugging and testing them thoroughly.
Methods
Secure Sockets Layer (SSL): This is an unofficial standard for exchanging sensitive information, supported by all contemporary browsers. SSL provides a means for servers to authenticate network transmissions, and for browsers to do the same, using a set of signed excryption algorithms. This is done as a "hand shake," through the exchange of keys used to match encryption and decryption. The many steps are listed and diagrammed on p. 385-386.
Screening User Input: You'll probably create errors if you don't, but for security purposes, make sure you do. Screen user input, that is. Here's what's been covered previously:
- Use addslashes() to filter data before it is passed to the database, escaping out characters that might cause problems (single quotes, etc.), and use stripslashes() to take them out when you want to use the original data
- Use the magic_quotes_gpc and magic_quotes_runtime directives (turned on in the php.ini file) to apply formatting to incoming GET, POST, and cookie variables (magic quotes_gpc), and to data going to and from the database (magic_quotes_runtime).
- Use strip_tags() to strip out HTML and PHP tags from a string (assuming you don't want them included in the string).
- Use htmlspecialchars() to convert characters to html entity equivalents (e.g., < to <).
Special Security: HTML files need to be available for execution, but not for writing. This is done in the Apache or IIS systems, giving limited permission to web users, greater permission to web authors. This is done at directory and file levels, with permission usually inherited to subdirectories. In general, separate scripts from the data that they write. Don't bother with encrypting data to be stored on the same machine that the encrypting script would be stored on: access to the script gives access to the data, so why do it? Similarly, you (as administrator) will limit access to MySQL files when you set up users and apply permissions to individual databases. Storing MySQL access passwords inside a PHP script isn't all that bad because, once again, the scripts are hidden from outside, and if a cracker gets access to the PHP script itself, they have already compromised your system and probably already have access to your database. Make sure that any included sensitive PHP files (e.g., a database connect string with id and pw) have a PHP extension so they can't be loaded directly by someone guessing the file name (e.g., connect.inc would be sent to the browser that requested it, not hidden by the PHP parser as connect.php would be).
Credit Card Numbers: This is simple. Don't store a credit card number if you don't have to. If you do this, make sure that you have the knowledge that it takes, and that you have someone dedicated to keeping up with the latest threats. You want to know absolutely that you have a state of the art security setup before you risk storing credit card information.
GPG: Gnu Privacy Guard is a open-source encryption method used for sending email; it is usuable without restrictions (no copyrights or license fees). Source, installaction, testing, and use are described on p. 389-397.