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

The documentation for mod_auth_mysql can be found at

or
/>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