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

Topics include • Providing secure transactions • Using Secure Sockets Layer SSL • Providing secure storage • Why are you storing credit card numbers?. User’s Browser Stored Pages & Scrip

The documentation for mod_auth_mysqlcan 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

325

15

Implementing Secure

Transactions with PHP and

MySQL

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 informainforma-tion 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

F IGURE 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

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

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

• 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

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 connecconnec-tions 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

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

333

HTTP FTP SMTP … TCP/UDP IP Various

Application Layer Transport Layer Network Layer Host to Network Layer

F IGURE 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

F IGURE 15.3

SSL adds an additional layer to the protocol stack as well as application layer protocols for controlling its own

operation.

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