Pro PHP Security phần 5 docx

184 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION username and password. Basic Authentication over unencrypted networks should therefore be used only in cases where modest security will suffice, such as applications that are more-or- less public but need to be reasonably able to attribute actions or access to a particular user. A great example of this is an application such as a photo manipulator that stores no actual copies of photos or any other privacy-related data, but that is greatly enhanced by allowing users to save preferences from session to session, and access them again on different computers. HTTP Digest Authentication RFC 2068, which defines HTTP 1.1 (available at Yeea+ cWT_Ve cWT#!')Ye^]), was issued in January 1997, just seven months after RFC 1945, and it carried over the Basic Authentication specification from the earlier version. But it also explicitly allowed for extensions to the protocol’s authentication methods, and it introduced HTTP Digest Authentication, referring the reader to RFC 2069 (available at Yeea+ cWT_Ve cWT#!'*Ye^]) for a complete description. HTTP Digest Authentication is capable of protecting a user’s password in transit over even an unencrypted network by including it in a message digest that has been hashed with the ^U& function. Digest Authentication is handled by Apache’s experimental ^`UPRfeYPUZXVde module (see Yeea+ YeeaURaRTYV`cX U`Td ^`U ^`UPRfeYPUZXVdeYe^]), as follows: 1. A client requests a protected resource. 2. The server sends back a %!"F_RfeY`cZkVU header, along with a HHH2feYV_eZTReV+ 5ZXVde header (with Basic Authentication it was a HHH2feYV_eZTReV+3RdZT header) that includes a nonce or a “number used once.” A nonce is typically a client IP address concatenated with a timestamp and some sort of private key (or data known only to the server), all expressed in hexadecimal format. 3. The client, after collecting a username and password from the user, sends back a second request for authentication. This request is in the form of an 2feY`cZkVU header that includes the username (as plaintext) and then an extensive message, an MD5 hash (or digest; hence the name, Digest Authentication) of the three (or four) following items: 1. An MD5 hash of username:realm:password (in that colon-delimited format). 2. The nonce that it has just received. 3. An MD5 hash of the original HTTP request method:URI (again in colon-delimited format); and an optional hash of the other original headers and the body of the request, if there is one. Since POST data is sent in the body of the request, using the optional body hash allows the server to verify that the values have not been changed in transit. This is unnecessary for GET requests, because the GET values are hashed as part of the URI. 4. When it receives this 2feY`cZkVU header back, the server can use the plaintext username to look up its own stored username:realm:password hash, and it already knows both the nonce (which it had originally sent) and the request information from the previous request. It can therefore construct its own digest, using the same algorithm that the client used, and compare the two. Based on this comparison, it will approve (or reject) this second request. SnyderSouthwell_5084.book Page 184 Wednesday, July 27, 2005 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION 185 The server may reuse nonces (somewhat ironically, since by definition they are “numbers used once”), or it may issue a new nonce on every request by including an 2feYV_eZTReZ`_:_W` header in the response. By issuing a different nonce for each request, the server decreases the ability of an attacker to replay previous requests as a means of hijacking a session, but also adds a certain amount of overhead for the server, as it may need to account for multiple parallel requests from the same client, and therefore accept multiple nonces as valid at any given time. It is important to remember that, unless the digest contains the optional fourth part (a hash of the original headers and body), any POST or PUT values could conceivably be tampered with by HTTP proxies or other servers that handle the request in transit. As of this writing, unfortunately, Apache’s ^`UPRfeYPUZXVde still hasn’t implemented entity-body digests (see the RfeYZ_e option of the 2feY5ZXVdeB`a directive, at Yeea+ YeeaURaRTYV`cX U`Td ^`U ^`UPRfeYPUZXVde Ye^]RfeYUZXVdeb`a), so there is not yet any possibility of attaining this added level of security using Apache. When and if this is implemented in the future, however, it promises to add significantly to the power of HTTP authentication to verify transactions, even without a heavy- duty security protocol like SSL in place. Furthermore, usernames are always transmitted in plaintext with Digest Authentication. And so, as we said earlier, Digest Authentication is no substitute for SSL if you need to secure every single part of your transmissions. But because the password is irreversibly hashed, it can indeed be considered secure, and you can thus have a fair level of confidence that the user making the request has some right to be using the password. That may be enough for your application, particularly if you are concerned only with limiting the ability to make requests, and not especially concerned with keeping either the content of those requests or the resulting responses private. Implementing Digest Authentication with Apache You have decided that you’d like to implement the reasonably secure Digest version of authen- tication for your application. If you have c``e access so that you can set Apache up correctly, it itself can do a lot of the work for you, using (as we noted earlier) Apache’s ^`UPRfeYPUZXVde module (see Yeea+ YeeaURaRTYV`cX U`Td ^`U ^`UPRfeYPUZXVdeYe^]). The configuration process is very straightforward, and has only two steps. The first step is to edit YeeaUT`_W, adding an entry like the following in either the main section or a virtual host container. These directives could also appear 2feY4`_WZXYeeaUT`_W. This example assumes that you want to require Digest Authentication in the hZ\Z directory: -=`TReZ`_ hZ\Z/ $XWK7\SH'LJHVW 2feY?R^V>jAc`eVTeVUHZ\Z 2feY5ZXVde5`^RZ_ hZ\Z  hZ\ZRU^Z_ Yeea+ ^Zcc`c^jac`eVTeVUhZ\ZT`^ hZ\Z 2feY5ZXVde7Z]V fdc ]`TR] VeT UZXVdeah CVbfZcVgR]ZUfdVc - =`TReZ`_/ In this example, you are protecting the hZ\Z URI and any URIs residing in directories under it. After specifying the 2feYEjaV you want to put into effect, you provide an 2feY?R^V, which is the arbitrary realm name that will be displayed to the user in the username-password request SnyderSouthwell_5084.book Page 185 Wednesday, July 27, 2005 12:24 PM 186 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION window, and which identifies a particular authentication realm. The 2feY5ZXVde5`^RZ_ directive can specify multiple URIs on more than one server that the authorization should apply to. Clients can therefore use the same username and password for multiple web locations, even on different servers, provided that the webservers serving those locations have similar config- urations. This kind of flexibility is rarely needed, but it is an interesting feature of the Digest Authentication specification. You also specify the location of the password file, here fdc ]`TR] VeT UZXVdeah. Finally, you instruct Apache to require that every user be valid (as defined in the password file) with the generalized gR]ZUfdVc instruction; without it, you would need to list every user for whom authentication should be performed. The second step is to create that password file, using Apache’s YeUZXVde command, which has the following syntax: YeUZXVdeLTNaRddhU7Z]VcVR]^fdVc_R^V The optional T switch tells YeUZXVde that you wish to create a new password file, and is used with the first entry only. The aRddhU7Z]V and cVR]^ parameters must match the corresponding directives in YeeaUT`_W, and fdVc_R^V is the username you wish to create or update. So to continue our example, we create the UZXVdeah file and add the first user, ^d`feYhV]]. YeUZXVdeT fdc ]`TR] VeT UZXVdeah>jAc`eVTeVUHZ\Z^d`feYhV]] 2UUZ_XaRddh`cUW`c^d`feYhV]]Z_cVR]^>jAc`eVTeVUHZ\Z ?VhaRddh`cU+ CVejaV_VhaRddh`cU+  The YeUZXVde program will prompt you twice for the password for fdVc_R^V, and then create the UZXVdeah file. Note that we are working as c``e, since the fdc ]`TR] VeT directory is generally not writable by normal users. The YeUZXVde command does not ask for a user’s current pass- word before changing the password to a new value, which is another reason to make sure that the password file is not editable by other users. Additional username/password combinations can be appended to the file (or updated) by calling YeUZXVde without the T switch: YeUZXVde fdc ]`TR] VeT UZXVdeah>jAc`eVTeVUHZ\ZTd_jUVc With this command, if the username does not already exist in the given realm, then YeUZXVde will create it. If it does, then its password will be updated. The password file you have just created will look something like this: ^d`feYhV]]+>jAc`eVTeVUHZ\Z+$S#)&VT#!#SVU#WW#"SVRR))US!)&"VT Td_jUVc+>jAc`eVTeVUHZ\Z+U"(VR&"T$$$$#VR$R(W!(V(R'S)#!((( The format of the file should be fairly obvious at a glance: username, realm, and hashed digest separated by colons. The hash is not, however, a hash of just the password; rather, it is an MD5 hash of the string fdVc_R^V+cVR]^+aRddh`cU. This is, of course, the same package of informa- tion sent by the client along with the 2feY`cZkVU header. The validation check is therefore a simple matter of comparing the client’s submitted hash to what is stored here. Note that if one user has a password in multiple realms, there will be multiple lines in the password file for that user. That is why both the username and the realm must be included in plaintext in the file, as well as in the digest. SnyderSouthwell_5084.book Page 186 Wednesday, July 27, 2005 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION 187 ■ Caution Digest Authentication can break in Internet Explorer if your application uses P86E variables, because IE doesn’t handle the URI field correctly when generating the 2feY`cZkVU header. Fortunately, there is a workaround: use a version of Apache greater than 2.0.51 and the following directive, in either YeeaUT`_W or YeRTTVdd in the appropriate directory: 3c`hdVc>ReTY>D:62feY5ZXVde6_RS]VBfVcjDecZ_X9RT\.@_ Once you have completed these two steps (using YeeaUT`_W or YeRTTVdd to tell Apache to require passwords, and creating the password file), you are ready to begin using Digest Authentication, and Apache will manage the process of negotiation with the client by itself. Your PHP scripts will have the same access to the authenticated username at PD6CG6CLC6>@E6PFD6CN as they would for Basic Authentication. Two-factor Authentication A recent wrinkle in authentication routines is Two-factor Authentication, in which two separate but concurrent authentication processes are required. The best two-factor authentication is typi- cally said to require both knowledge of some secret and the possession of some token obtained by some other channel than the one being authenticated. The token might be transmitted via cell phone or email, or it might be encoded on a smart card or flash memory device and physically handed to the user. For an example of a commercial implementation of two-factor authentica- tion, see Yeea+ hhhcdRdVTfcZejT`^ _`UVRda0ZU.""&(. There is some concern that two-factor authentication alone doesn’t provide any real increase in security, because a man-in-the-middle can intercept both the token and the pass- word as easily as the password alone, and use the intercepted credentials to either replay the original request or fabricate a new one. Accordingly, the strongest two-factor authentication requires that the second factor be sent to the server out-of-band, using some means other than (for a web application) an HTTP request. An application might require a signed email to autho- rize a web transaction, or better still a phone call or SMS text message. An extremely paranoid application could require that the second factor be notarized and sent via registered mail, holding the transaction in a suspended state until the veracity of the request can be verified. Since most of us don’t need to go to such extremes to authorize transactions, we present two practical examples of reasonably secure two-factor authentication in the text that follows: the use of a client SSL certificate as a backup to password authentication, and the use of one- time keys to reliably authorize individual requests. Certificate-based Authentication Using HTTPS If you recall our discussion of SSL from Chapter 7, you’ll remember that the server authenticates itself to the client by means of a CA-signed Server Certificate, using public-key encryption to prove its identity. The client can authenticate itself to the server using exactly the same mechanism. To effect an HTTPS request, it sends a Certificate containing a CA-signed Public Key (which it expects the server to validate by checking the CA Signature) along with the message, which it has signed using its Private Key. The server attempts to verify the message signature using the client’s Public Key (contained in the Certificate, which it approves because it trusts the Certificate SnyderSouthwell_5084.book Page 187 Wednesday, July 27, 2005 12:24 PM 188 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION Authority, or CA, that has signed it). If that signature is valid, the client is considered to be authenticated. This method cannot be successfully employed for a large userbase without substantial administrative overhead. Each user must generate a Private Key, and from that key a Certificate Signing Request (CSR). The CSR must be signed using the organization’s CA key, and the resulting Certificate given back to the user. Each user must install his Private Key and Certificate in any browser that he will use to connect to the application. And the Certificates must be managed: stored for verification, renewed when they expire, and revoked if they become invalid for any reason. And still, passwords should be used, because a Client Certificate authenticates only that client, and not the identity of the actual user at the keyboard. The use of a password, something the user knows, with an SSL Client Certificate, some- thing the user possesses, might be considered a kind of two-factor authentication. In reality, though, the possession claim is more than a little dubious. It’s not so much that the user possesses the Certificate as that the client’s web browser possesses it. But if that Certificate is being stored on removable media like a USB key, for instance, then it can be physically moved from computer to computer by the person who possesses it. Despite all these difficulties, however, implementing SSL remains the most powerful way to provide systematic security. Apache’s ^`UPdd] module offers a fairly easy way to manage that implementation. Configuring PRGBVVO to Use Client Certificates At its simplest, Client Certificate authentication requires each visitor to the protected part of your site to present a Certificate, issued by you and signed with your CA Certificate, and a signed message as proof of identity. Compared to the creation and installation of Client Certificates, configuring the server to use them is trivial. In YeeaUT`_W, add the following three directives to any server, virtual server, location, or directory block that you want to protect: -=`TReZ`_ dVTcVe/ cVbfZcVR4]ZV_e4VceZWZTReVdZX_VUUZcVTe]jSjeYV424VceZWZTReVZ_TRTce DD=GVcZWj4]ZV_ecVbfZcV DD=GVcZWj5VaeY" DD=424VceZWZTReV7Z]VT`_W dd]Tce TRTce - =`TReZ`_/ The DD=GVcZWj4]ZV_ecVbfZcV directive tells the server that a verified Client Certificate must be presented for access to the specified area. By setting DD=GVcZWj5VaeY to one level, you effec- tively require that the presented Certificate be signed with a CA Certificate known to the server. In other words, the server is not allowed to go up the CA chain to find a known CA (which would be a depth of greater than 1), and the Certificate is not allowed to be self-signed (which would be a depth of 0). The DD=424VceZWZTReV7Z]V directive is used to specify the exact CA Certificate (here, the one located at T`_W dd]Tce TRTce) that is allowed to sign the Client Certificates. SnyderSouthwell_5084.book Page 188 Wednesday, July 27, 2005 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION 189 Creating the Certificates As you’ll recall from our discussion in Chapter 7, Certificates are generated via a three-step process. First, a private RSA key is generated. That key is used to create a Certificate Signing Request, which is sent to a Certificate Authority. The CA uses its own key to sign the CSR, gener- ating a Certificate that is sent back to the requestor. In the case of Client Certificates, these steps might all be carried out on the same server by a system administrator, who would then deliver the Private Key and Certificate to the client via a secure channel, such as on a USB key or over a protected LAN. Ideally, however, and marginally most safely, the end user would generate the key and CSR on her own workstation, and send just the CSR to a CA or an admin- istrator for signing. An excellent practical description of this process using OpenSSL for Windows can be found at Yeea+ hhhZ^aVefdfd oc[^``_Vj ac`[VTed ^ZdT T]ZV_eTVceRfeYYe^]. Using a Client Certificate Once that user receives the signed Certificate back from the CA or administrator, that Certifi- cate must be recombined with her Private Key and converted to PKCS#12 format (see Yeea+ hhhcdRdVTfcZejT`^ cdR]RSd _`UVRda0ZU.#"$)) so that MSIE, Firefox, and other browsers will understand it. Assuming that she has already generated an RSA key (here, located at T]ZV_e\Vj) and a signed Certificate (here, T]ZV_eTce), the following command will convert them to a PKCS#12 Certificate called T]ZV_ea"#: `aV_dd]a\Td"#Via`ceZ_T]ZV_eTceZ_\VjT]ZV_e\Vj➥ `feT]ZV_ea"#_R^V4]ZV_e4Vce When `aV_dd] converts the Certificate, it will ask for an “export password” to protect the contents of the Private Key. This password can be anything the user likes, but it must be provided in order to convert the Certificate, and it will be needed again when that converted Certificate is installed in the user’s web browser. Different browsers provide different mechanisms for certificate installation, although double- clicking a Certificate may be enough to install it in the operating system’s default browser. In Firefox, client certificates are installed in Tools ➤ Options ➤ Advanced ➤ Certificates ➤ Manage Certificates ➤ Import. When you click the Import button to import a new certificate, the Certificate Manager will ask for the password used to protect that certificate, as shown in Figure 9-2 (Firefox refers to certificate files as “backups”). You may check that the Certificate has actually been installed by viewing the installed Certificates at (again in Firefox) Tools ➤ Options ➤ Advanced ➤ Certificates ➤ Manage Certificates ➤ Your Certificates, as shown in Figure 9-3. SnyderSouthwell_5084.book Page 189 Wednesday, July 27, 2005 12:24 PM 190 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION Figure 9-2. Importing a PKCS#12 Certificate into Mozilla Firefox Figure 9-3. The Certificate Manager in Mozilla Firefox with a single, self-signed Client Certificate installed SnyderSouthwell_5084.book Page 190 Wednesday, July 27, 2005 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION 191 The certificate management process for users preferring Apple’s Safari browser is a bit unusual, as all of Safari’s Certificates are managed by the OS X Keychain Access utility, as shown in Figure 9-4. Figure 9-4. The OS X Keychain Access utility with a single, self-signed Client Certificate installed Verifying an SSL Connection Once both Apache and the client web browser have been configured to use a Client Certificate, Apache should be able to verify without any assistance whether the client has succeeded in making a secure connection by presenting a valid Certificate upon an HTTPS connection. For additional safety, however, you might very well want to have your application make its own independent check that a secure connection has been made. You can do that with the following code, which can be found also as TYVT\DVTfcV4`__VTeZ`_aYa in the Chapter 9 folder of the downloadable archive of code for Pro PHP Security at Yeea+ hhhRacVddT`^. -0aYa  UZdR]]`hSjUVWRf]e R]]`h.72=D6, cVRd`_., SnyderSouthwell_5084.book Page 191 Wednesday, July 27, 2005 12:24 PM 192 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION  cVbfZcVDD= ZWZddVePD6CG6CL9EEADNl cVRd`_.J`f^fdefdVR_DD=T`__VTeZ`_W`ceYZdcVbfVde, n  ZWDD=R_UeYVcVZdR4]ZV_e4VceZWZTReV  cVbfZcV4VceZWZTReVZee`SVgVcZWZVU V]dVZWZddVePD6CG6CLDD=P4=:6?EPG6C:7JN2?5 PD6CG6CLDD=P4=:6?EPG6C:7JN 72:=65+_f]]l cVRd`_.EYVdVcgVcT`f]U_`egVcZWjj`fc4]ZV_e4VceZWZTReV, n V]dVl R]]`h.ECF6, n ZWR]]`hl YVRUVc9EEA ""%!$7`cSZUUV_, 0/ -5@4EJA6Ye^]AF3=:4 H$4 5E5I9E>="!EcR_dZeZ`_R] 6? Yeea+ hhhh$`cX EC iYe^]" 5E5 iYe^]"ecR_dZeZ`_R]UeU/ -Ye^]i^]_d.Yeea+ hhhh$`cX "*** iYe^]i^]+]R_X.V_/ -YVRU/ -^VeRYeeaVbfZg.T`_eV_eejaVT`_eV_e.eVie Ye^],TYRcdVe.feW) / -eZe]V/4`__VTeZ`_?`eDVTfcV- eZe]V/ - YVRU/ -S`Uj/ -Y"/4`__VTeZ`_?`eDVTfcV- Y"/ -a/-0.cVRd`_0/- a/ - S`Uj/ - Ye^]/ -0 ViZe, n  T`__VTeZ`_dVTfcVT`_eZ_fVhZeYdTcZae 0/ The script defaults to disallowing a connection, declaring the R]]`h flag as 72=D6. You first check whether the 9EEAD key in the PD6CG6C superglobal array is set. The 9EEAD key exists only if SSL is enabled by ^`UPdd]. If the key doesn’t exist, then the connection is not secure, and so you leave the flag set to 72=D6 and specify that SSL must be used for communication in the cVRd`_ variable. You then check whether the server is configured to accept Client Certificates, and if so, whether the verification check of the CA’s signature passed. If the DD=P4=:6?EPG6C:7J key in the PD6CG6C array is set, then a Client Certificate was requested and received by Apache. But if the value of this key is 72:=65+_f]], then verification of that Certificate has failed, and so you again leave the R]]`h flag set to 72=D6 and specify the reason. If neither of those checks for an SnyderSouthwell_5084.book Page 192 Wednesday, July 27, 2005 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION 193 insecure connection is ECF6, then the connection must indeed be considered secure, and you set the flag to ECF6. After completing these two checks, you either exit after generating a window (accompa- nied by a %!$7`cSZUUV_ header) that explains why the connection has not been found to be secure, or you permit the user to continue with the application. How to Read Client Certificate Details in PHP Once you are sure that the user has made a secure connection, you need to find and use the information in the Client Certificate in order to help authenticate the client. As we suggested in the previous section, the details of that Certificate will be available to PHP in the superglobal PD6CG6C array, in a series of keys starting with DD=P4=:6?EPD. The most important of these values for our purposes is the Common Name on the certificate, which is stored in PD6CG6CLDD=P4=:6?EPDP5?P4?N. This identifies the bearer. Figure 9-5 is a portion of the output from the aYaZ_W` function, showing these Certificate-related values on a secure server with Client Certificates enabled. Figure 9-5. Partial output from aYaZ_W` on a secure server with client certificates enabled All entries in the left column with the blue background are keys for the PD6CG6C super- global array. Keys beginning with DD=P4=:6?EPD refer to the Certificate’s subject, or bearer, while those beginning with DD=P4=:6?EP: refer to the Certificate’s issuer, or the CA. SnyderSouthwell_5084.book Page 193 Wednesday, July 27, 2005 12:24 PM [...]... command ls -l: drwxr-xr-x -rw-r r-lrwxrwxrwx -rw-r r-drwxrwxrwx 2 1 1 1 2 timb timb timb timb timb www 68 20 Nov www 54 5 20 Nov www 4 9 Nov www 724 20 Nov www 68 20 Nov 15: 04 15: 04 22 :57 15: 06 15: 05 images index .php lib -> /usr/lib /php upload .php uploads We’re interested in the first column, which contains slots for ten characters, although frequently some of those slots are left unfilled For convenience,... users but for processes as well This brings us to our next topic, protecting the system itself, by keeping processes in their proper places 2 15 SnyderSouthwell _50 84.book Page 216 Saturday, July 16, 20 05 6:14 AM 216 CHAPTER 10 ■ CONTROLLING ACCESS II: PERMISSIONS AND RESTRICTIONS Protecting the System from Itself We’ve been talking about keeping users’ permission to operate confined to appropriate areas... authentication, dd` (Step 3 in Figure 9-6) redirects the user to the following URI: Yeea+ T^dViR^a]V`cX ]`XZ_aYa0RfeY.6 ;58 \YjeLsN8YKT3V $5 1 95 SnyderSouthwell _50 84.book Page 196 Wednesday, July 27, 20 05 12:24 PM 196 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION Figure 9-6 The Single Sign-On process The RfeY value is the base64-encoding of a message consisting of the user’s authenticated identity along... schemes; and where appropriate, we have provided PHP- based solutions to the dilemma of accomplishing this authentication safely and easily Now that we can have some confidence in who our users are, we will turn in Chapter 10 to controlling their access to the various parts of your server’s resources 207 SnyderSouthwell _50 84.book Page 208 Wednesday, July 27, 20 05 12:24 PM SnyderSouthwell _50 84.book Page 209... SnyderSouthwell _50 84.book Page 218 Saturday, July 16, 20 05 6:14 AM 218 CHAPTER 10 ■ CONTROLLING ACCESS II: PERMISSIONS AND RESTRICTIONS PHP s Own Resource Limits PHP has its own set of resource limits, set in php. ini, that control the most common resource limits There are no correct or recommended settings for these directives; you need to analyze your own applications to determine what limits are appropriate,... two problems has its own solution 213 SnyderSouthwell _50 84.book Page 214 Saturday, July 16, 20 05 6:14 AM 214 CHAPTER 10 ■ CONTROLLING ACCESS II: PERMISSIONS AND RESTRICTIONS umask We solve the first of these two problems (new files are group read-only) with a little filesystem voodoo, made possible by the fact that each user possesses a umask value, stored in his login script (typically ~/.bash_profile)... -) and you also want the set-group-id bit set, you would use the command chmod 2770 /path/to/directory SnyderSouthwell _50 84.book Page 2 15 Saturday, July 16, 20 05 6:14 AM CHAPTER 10 ■ CONTROLLING ACCESS II: PERMISSIONS AND RESTRICTIONS PHP Tools for Working with File Access Controls PHP includes native functions that essentially duplicate the unix system utilities that we have been discussing; the chown(),... online applications When working with PHP s chown() function, you must use an octal mode specification In PHP, octal numbers are prefixed with a 0 (zero) to ensure that the following three digits are interpreted as octal rather than decimal values The equivalent of chmod 7 75 /path/to/file would therefore be chown( '/path/to/file', 07 75 ) Similarly, if you want to use PHP to set the set-group-id bit on... V_T`UV>VddRXV method does the work of encrypting the message This rather complex process is portrayed in Figure 9-7 Figure 9-7 The message encryption process SnyderSouthwell _50 84.book Page 201 Wednesday, July 27, 20 05 12:24 PM CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION In general terms, the message encryption process works like this: a signed plaintext message is symmetrically encrypted by Blowfish... others) But there are two problems with this approach, and they both arise when a user creates a new file or directory in the shared area The first has to do with file permissions By default, the mode for new files is 644, and the mode for new directories is 755 These permissions mean that a new file or directory is writable only by its owner, and not by any group users The other problem is that new files . ]`XZ_aYa0RfeY.6 ;58 YjeLsN8YKT3V $5 SnyderSouthwell _50 84.book Page 1 95 Wednesday, July 27, 20 05 12:24 PM 196 CHAPTER 9 ■ CONTROLLING ACCESS I: AUTHENTICATION Figure 9-6. The Single Sign-On process The. ""%!$7`cSZUUV_, 0/ - 5@ 4EJA6Ye^]AF3=:4 H$4 5E5I9E>="!EcR_dZeZ`_R] 6? Yeea+ hhhh$`cX EC iYe^]" 5E5 iYe^]"ecR_dZeZ`_R]UeU/ -Ye^]i^]_d.Yeea+. of code for Pro PHP Security at Yeea+ hhhRacVddT`^. -0aYa  UZdR]]`hSjUVWRf]e R]]`h.72=D6, cVRd`_., SnyderSouthwell _50 84.book Page 191 Wednesday, July 27, 20 05 12:24 PM 192 CHAPTER