Phát triển web với PHP và MySQL - p 36 pot

The documentation for mod_auth_mysql can be found at http://www.zend.com or http://www.express.ru/docs/mod_auth_mysql_base.html Next The next chapter explains how to safeguard data at all stages of processing from input, through transmission, and in storage. It includes the use of SSL, digital certificates, and encryption. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 325 18 7842 CH14 3/6/01 3:35 PM Page 325 18 7842 CH14 3/6/01 3:35 PM Page 326 CHAPTER 15 Implementing Secure Transactions with PHP and MySQL 19 7842 CH15 3/6/01 3:40 PM Page 327 E-commerce and Security P ART III 328 In this chapter, we will explain how to deal with user data securely from input, through trans- mission, and in storage. This will allow us to implement a transaction between us and a user securely from end to end. Topics include • Providing secure transactions • Using Secure Sockets Layer (SSL) • Providing secure storage • Why are you storing credit card numbers? • Using encryption in PHP Providing Secure Transactions Providing secure transactions using the Internet is a matter of examining the flow of informa- tion in your system and ensuring that at each point, your information is secure. In the context of network security, there are no absolutes. No system is ever going to be impenetrable. By secure we mean that the level of effort required to compromise a system or transmission is high compared to the value of the information involved. If we are to direct our security efforts effectively, we need to examine the flow of information through all parts of our system. The flow of user information in a typical application, written using PHP and MySQL, is shown in Figure 15.1. User’s Browser Stored Pages & Scripts Web Server Data Files PHP Engine MySQL Data MySQL Engine Internet FIGURE 15.1 User information is stored or processed by the following elements of a typical Web application environment. The details of each transaction occurring in your system will vary, depending both on your sys- tem design and on the user data and actions that triggered the transaction. You can examine all of these in a similar way. Each transaction between a Web application and a user begins with 19 7842 CH15 3/6/01 3:40 PM Page 328 the user’s browser sending a request through the Internet to the Web server. If the page is a PHP script, the Web server will delegate processing the page to the PHP engine. The PHP script might read or write data to disk. It might also include() or require() other PHP or HTML files. It will also send SQL queries to the MySQL daemon and receive responses. The MySQL engine is responsible for reading and writing its own data on disk. This system has three main parts: • The user’s machine • The Internet • Your system We will look at security considerations for each separately, but obviously the user’s machine and the Internet are largely out of your control. The User’s Machine From our point of view, the user’s machine is running a Web browser. We have no control over other factors such as how securely the machine is set up. We need to bear in mind that the machine might be very insecure or even a shared terminal at a library, school, or café. Many different browsers are available, each having slightly different capabilities. If we only consider recent versions of the most popular two browsers, most of the differences between them only affect how HTML will be rendered and displayed, but there are security or function- ality issues that we need to consider. You should note that some people will disable features that they consider a security or privacy risk, such as Java, cookies, or JavaScript. If you use these features, you should either test that your application degrades gracefully for people without these features, or consider providing a less feature rich interface that allows these people to use your site. Users outside the United States and Canada might have Web browsers that only support 40-bit encryption. Although the U.S. Government changed the law in January 2000 to allow export of strong encryption (to non-embargoed countries) and 128-bit versions are now available to most users, some of them will not have upgraded. Unless you are making guarantees of security to users in the text of your site, this need not concern you overly as a Web developer. SSL will automatically negotiate for you to enable your server and the user’s browser to communicate at the most secure level that they both understand. We cannot be sure that we are dealing with a Web browser connecting to our site through our intended interface. Requests to our site might be coming from another site stealing images or content, or from a person using software such as cURL to bypass safety measures. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 329 19 7842 CH15 3/6/01 3:40 PM Page 329 We will look at the cURL library, which can be used to simulate connections from a browser, in Chapter 17, “Using Network and Protocol Functions.” This is useful to us as developers, but can also be used maliciously. Although we cannot change or control the way that our users’ machines are set up, we do need to bear it in mind. The variability of user machines might be a factor in how much functional- ity we provide via server-side scripting (such as PHP) and how much we provide via client- side scripting (such as JavaScript). Functionality provided by PHP can be compatible with every user’s browser, as the end result is merely an HTML page. Using anything but very basic JavaScript will involve taking into account the different capabilities of individual browser versions. From a security perspective, we are better off using server-side scripting for such things as data validation because, that way, our source code will not be visible to the user. If we validate data in JavaScript, users will be able to see the code and perhaps circumvent it. Data that needs to be retained can be stored on our own machines, as files or database records, or on our users’ machines as cookies. We will look at using cookies for storing some limited data (a session key) in Chapter 20, “Using Session Control in PHP.” The majority of data we store should reside on the Web server, or in our database. There are a number of good reasons to store as little information as possible on the user’s machine. If the information is outside your system, you have no control over how securely it is stored, you cannot be sure that the user will not delete it, and you cannot stop the user from modifying it in an attempt to confuse your system. The Internet Like the user’s machine, you have very little control over the characteristics of the Internet, but, like the user’s machine, this does not mean that you can ignore these characteristics when designing your system. The Internet has many fine features, but it is an inherently insecure network. When sending information from one point to another, you need to bear in mind that others could view or alter the information you are transmitting, as we discussed in Chapter 13. With this in mind, you can decide what action to take. Your response might be to • Transmit the information anyway, knowing that it might not be private. • Encrypt or sign the information before transmitting it to keep it private or protect it from tampering. E-commerce and Security P ART III 330 19 7842 CH15 3/6/01 3:40 PM Page 330 • Decide that your information is too sensitive to risk any chance of interception and find another way to distribute your information. The Internet is also a fairly anonymous medium. It is difficult to be certain whether the person you are dealing with is who they claim to be. Even if you can assure yourself about a user to your own satisfaction, it might be difficult to prove this beyond a sufficient level of doubt in a forum such as a court. This causes problems with repudiation, which we discussed in Chapter 13, “E-commerce Security Issues.” In summary, privacy and repudiation are big issues when conducting transactions over the Internet. There are at least two different ways you can secure information flowing to and from your Web server through the Internet: • SSL (Secure Sockets Layer) • S-HTTP (Secure Hypertext Transfer Protocol) Both these technologies offer private, tamper resistant messages and authentication, but SSL is readily available and widely used whereas S-HTTP has not really taken off. We will look at SSL in detail later in this chapter. Your System The part of the universe that you do have control over is your system. Your system is repre- sented by the components within the dotted line as shown previously in Figure 15.1. These components might be physically separated on a network, or all exist on the one physical machine. It is fairly safe to not worry about the security of information while the various third-party products that we use to deliver our Web content are handling it. The authors of those particular pieces of software have probably given them more thought than you have time to give them. As long as you are using an up-to-date version of a well-known product, you will be able to find any well-known problems by judicious application of your favorite Web search engine. You should make it a priority to keep up-to-date with this information. If installation and configuration are part of your role, you do need to worry about the way soft- ware is installed and configured. Many mistakes made in security are a result of not following the warnings in the documentation, or involve general system administration issues that are topics for another book. Buy a good book on administering the operating system you intend to use, or hire an expert system administrator. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 331 19 7842 CH15 3/6/01 3:40 PM Page 331 One specific thing to consider when installing PHP is that it is generally more secure, as well as much more efficient, to install PHP as a SAPI module for your Web server than to run it via the CGI interface. The primary thing you need to worry about is what your own scripts do or don’t do. What potentially sensitive data does our application transmit to the user over the Internet? What sensitive data do we ask users to transmit to us? If we are transmitting information that should be a private transaction between us and our users or that should be difficult for an inter- mediary to modify, we should consider using SSL. We have already talked about using SSL between the user’s computer and the server. You should also think about the situation where you are transmitting data from one component of your system to another over a network. A typical example arises when your MySQL database resides on a different machine from your Web server. PHP will connect to your MySQL server via TCP/IP, and this connection will be unencrypted. If these machines are both on a private local area network, you need to ensure that network is secure. If the machines are communicat- ing via the Internet, your system will probably run slowly, and you need to treat this connec- tion in the same way as other connections over the Internet. PHP has no native way of making this connection via SSL. The fopen() command supports HTTP but not HTTPS. You can, however, use SSL via the cURL library. We will look at the use of cURL in Chapter 17. It is important that when our users think they are dealing with us, they are dealing with us. Registering for a digital certificate will protect our visitors from spoofing (someone else imper- sonating our site), allow us to use SSL without users seeing a warning message, and provide an air of respectability to our online venture. Do our scripts carefully check the data that users enter? Are we careful about storing information securely? We will answer these questions in the next few sections of this chapter. Using Secure Sockets Layer (SSL) The Secure Sockets Layer protocol suite was originally designed by Netscape to facilitate secure communication between Web servers and Web browsers. It has since been adopted as the unofficial standard method for browsers and servers to exchange sensitive information. Both SSL version 2 and version 3 are well supported. Most Web servers either include SSL functionality, or can accept it as an add-on module. Internet Explorer and Netscape Navigator have both supported SSL from version 3. E-commerce and Security P ART III 332 19 7842 CH15 3/6/01 3:40 PM Page 332 Networking protocols and the software that implements them are usually arranged as a stack of layers. Each layer can pass data to the layer above or below, and request services of the layer above or below. Figure 15.2 shows such a protocol stack. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 333 HTTP FTP SMTP … TCP/UDP IP Various Application Layer Transport Layer Network Layer Host to Network Layer FIGURE 15.2 The protocol stack used by an application layer protocol such as Hypertext Transfer Protocol. When you use HTTP to transfer information, the HTTP protocol calls on the Transmission Control Protocol (TCP), which in turn relies on the Internet Protocol (IP). This protocol in turn needs an appropriate protocol for the network hardware being used to take packets of data and send them as an electrical signal to our destination. HTTP is called an application layer protocol. There are many other application layer protocols such as FTP, SMTP and telnet (as shown in the figure), and others such as POP and IMAP. TCP is one of two transport layer protocols used in TCP/IP networks. IP is the protocol at the network layer. The host to network layer is responsible for connecting our host (computer) to a network. The TCP/IP protocol stack does not specify the protocols used for this layer, as we need different protocols for different types of networks. When sending data, the data is sent down through the stack from an application to the physical network media. When receiving data, data travels up from the physical network, through the stack, to the application. Using SSL adds an additional transparent layer to this model. The SSL layer exists between the transport layer and the application layer. This is shown in Figure 15.3. The SSL layer modifies the data from our HTTP application before giving it to the transport layer to send it to its desti- nation. SSL Handshake Protocol SSL Change Cipher HTTP SSL Alert Protocol … SSL Record Protocol TCP IP Application Layer SSL Layer Transport Layer Network Layer Host to Network Layer Host to Network FIGURE 15.3 SSL adds an additional layer to the protocol stack as well as application layer protocols for controlling its own operation. 19 7842 CH15 3/6/01 3:40 PM Page 333 SSL is theoretically capable of providing a secure transmission environment for protocols other than HTTP, but is normally only used for HTTP. Other protocols can be used because the SSL layer is essentially transparent. The SSL layer provides the same interface to protocols above it as the underlying transport layer. It then transparently deals with handshaking, encryption, and decryption. When a Web browser connects to a secure Web server via HTTP, the two need to follow a handshaking protocol to agree on things such as authentication and encryption. The handshake sequence involves the following steps: 1. The browser connects to an SSL enabled server and asks the server to authenticate itself. 2. The server sends its digital certificate. 3. The server might optionally (and rarely) request that the browser authenticate itself. 4. The browser presents a list of the encryption algorithms and hash functions it supports. The server selects the strongest encryption that it also supports. 5. The browser and server generate session keys: 5.1 The browser obtains the server’s public key from its digital certificate and uses it to encrypt a randomly generated number. 5.2 The server responds with more random data sent in plaintext (unless the browser has provided a digital certificate at the server’s request in which case the server will use the browser’s public key). 5.3 The encryption keys for the session are generated from this random data using hash functions. Generating good quality random data, decrypting digital certificates, and generating keys and using public key cryptography takes time, so this handshake procedure takes time. Fortunately, the results are cached, so if the same browser and server want to exchange multiple secure messages, the handshake process and the required processing time only occur once. When data is sent over an SSL connection, the following steps occur: 1. It is broken into manageable packets. 2. Each packet is (optionally) compressed. 3. Each packet has a message authentication code (MAC) calculated using a hashing algo- rithm. 4. The MAC and compressed data are combined and encrypted. 5. The encrypted packets are combined with header information and sent to the network. The entire process is shown in Figure 15.4. E-commerce and Security P ART III 334 19 7842 CH15 3/6/01 3:40 PM Page 334 . such a protocol stack. Implementing Secure Transactions with PHP and MySQL C HAPTER 15 15 I MPLEMENTING S ECURE TRANSACTIONS 333 HTTP FTP SMTP … TCP/UDP IP Various Application Layer Transport Layer Network. PM Page 328 the user’s browser sending a request through the Internet to the Web server. If the page is a PHP script, the Web server will delegate processing the page to the PHP engine. The PHP. encryption. Implementing Authentication with PHP and MySQL C HAPTER 14 14 IMPLEMENTING AUTHENTICATION 325 18 7842 CH14 3/6/01 3:35 PM Page 325 18 7842 CH14 3/6/01 3:35 PM Page 326 CHAPTER 15 Implementing