Secure Client/Server-Interaction

13.4 Secure Client/Server-Interaction

In the following, we show how the introduced technologies can be employed to provide secure interaction between clients and service providers. We distinguish between point-to-point and end-to-end security.

13.4.1 Point-to-Point Security SSL (Secure Sockets Layer) and TLS (Transport Level Security) are the most widely used

protocols for secure messaging over the Internet (Garfinkel 2002). The latest version, SSL 3.0,

13.4 Secure Client/Server-Interaction 273 was released in 1996 by Netscape Communications. It is recommended to use version 3.0, as the

predecessor SSL 2.0 has some weaknesses. SSL is the predecessor of TLS 1.0 (Dierks and Allen 1999), which is also known as SSL 3.1. SSL is assigned to the application layer of the TCP/IP protocol stack. SSL/TSL establishes a secure connection between two communicating partners, one server and one client, through an interplay of symmetric and asymmetric cryptography.

The SSL Handshake Protocol An SSL session is initiated through the SSL handshake protocol that allows a server to

authenticate to the client, to negotiate a symmetric encryption algorithm, and to build up an encrypted tunnel for communication. The SSL handshake supporting server authentication proceeds as follows (Freier et al. 1996):

1. The client sends a request to the server in order to establish a secure connection containing information about its cryptographic settings.

2. The server replies with its cipher settings and its certificate for authentication.

3. The client checks the server’s certificate validity (as described below).

4. The client generates a so-called pre-master secret based on the data exchanged so far, encrypts it using the server’s public key, and sends it to the server.

5. Client and server generate the master secret based on the pre-master secret.

6. Using the master secret, both client and server generate the symmetric session key.

7. The client informs the server that future messages will be encrypted. An additional, already encrypted message is sent to the server stating that the client’s part of the SSL handshake is completed.

8. The server informs the client that future messages will be encrypted. Analogously to the client, it sends an additional encrypted message stating that the server part of the SSL handshake is completed.

SSL also supports mutual certificate exchange which requires some additional actions within the handshake protocol. Due to the necessary overhead (and costs) for issuing a certificate, certificates for end users are not yet widely adopted, so that typically only the server’s certificate is validated.

Server Certificate Validation During the SSL handshake, the client authenticates the server’s identity. For this purpose, the

server’s certificate is evaluated as follows:

1. First, the client checks whether the issuing CA is trusted. Each client maintains a list of trusted CAs. The issuing CA is trusted if it is part of the list, or if a certificate chain can

be determined that ends up in a CA which is contained in the client’s list.

2. Next, the digital signature of the certificate is evaluated using the issuing CA’s public key.

3. Subsequently, the validity period is examined, i.e., it is ascertained whether the current date is within the certificate’s validity period.

274 Security for Web Applications

4. Then, the domain name listed in the certificate is compared with the server’s domain name for equality.

5. So far, the certificate’s validity is determined. Now the certificate revocation list is checked to see if the certificate has been revoked.

If steps 1 to 5 are performed without any conflict, the server’s certificate is successfully validated and the SSL handshake proceeds as described above. The presented negotiation allows the client to authenticate the server’s identity: in step 4 of the handshake protocol the client encrypts the pre-master secret using the public key contained in the provided certificate. Only if the server is the legitimate owner of the certificate does it possess the private key to decrypt the pre-master secret, which is required for the generation of the master secret and, thus, the symmetric key. That is, by forcing the server to use its private key, SSL enables server authentication.

SSL-secured sessions are very common for e-commerce applications like order transactions or online banking. Users can check SSL connections by clicking on the SSL-keylock symbol of their browsers to obtain information about the employed cipher algorithms and the service provider’s certificate. If the provider’s certificate is not trusted, e.g., because it has expired or has been revoked, the user receives a warning.

13.4.2 End-to-End Security Online transactions can involve more than two communicating entities. This can be seen in our

small example of Alice buying a book from the online shop, with the amount being charged from her ChiefCard credit card account. In the payment transaction, the bookstore plays an intermediary role when it forwards Alice’s credit card data to ChiefCard, and does not require seeing Alice’s credit card data in plain text. The communication between Alice and the bookstore can be secured by the previously introduced transport level security. What is required in addition is end-to-end security between Alice and ChiefCard. This is also known as message level security, denoting that the security information is contained within the message. This allows parts of a message to be transported without intermediary parties seeing or modifying it.

End-to-end security is of crucial importance for Web service interactions. Complex busi- ness processes can be realized through so-called Web service choreographies. To give an example, let’s assume that the book ordering proceeds via a Web service invocation. For the debit process the bookstore Web service invokes a Web service provided by ChiefCard. As described in section 6.6.2, Web services interact through the exchange of SOAP messages. Figure 13-7 illustrates the SOAP message for the invocation of book.store.com’s Web service. The SOAP-body of the request contains Alice’s shopping cart, her contact data, and her credit card information.

First we illustrate how Alice’s credit card data is secured. This information must be readable by ChiefCard, but not by book.store.com, which is achieved by XML Encryp- tion (W3C, 2002d). XML Encryption does not introduce any new cryptographic methods. Instead, it specifies the syntax for including encrypted content into XML documents. It supports a wide range of granularity levels, ranging from the encryption of single XML element nodes to complete documents. In plain text, Alice’s credit card data would look like this:

13.4 Secure Client/Server-Interaction 275

<?xmlversion="1.0"encoding="utf-8"?> <soap:Envelope

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext" xmlns:bs="http://www.book.store.com/B-WS.wsdl"> <soap:Header>

SOAP Header

<wsse:BinarySecurityToken

WS-Security Tokens

ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"

>MIIHdjCCB...</wsse:BinarySecurityToken> </soap:Header>

<soap:Body>

SOAP Body

<bs:Bookorder> <ds:Signature>

Signed Contact Information

<ds:SignedInfo> <ds:SignatureMethod Algorithm="xmldsig#rsa-sha1"/> <ds:ReferenceURI="#cust">...</ds:Reference>

</ds:SignedInfo> <ds:SignatureValue>InmSS251sfd5cliT...</ds:SignatureValue> <ds:ObjectID="order">

<bs:ShoppingCart date="01/01/05"> <bs:booktitle="Web Engineering"/> </bs:ShoppingCart> <bs:Customer>

<bs:name>Alice</bs:name> <bs:address>123 Cooper Blvd</bs:address> <bs:city zip="10036">New York</bs:city>

</bs:Customer> </ds:Object> </ds:Signature>

<bs:CreditCard

Encrypted Credit Card Information

Issuer="www.chiefcard.com"> <xenc:EncryptedData> <xenc:EncryptionMethod Algorithm="xmlenc#rsa-1_5"/> <xenc:CipherData> <xenc:CipherValue>InmSSXqnPpZYMg==...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </bs:CreditCard> </bs:Bookorder> </soap:Body> </soap:Envelope>

Figure 13-7 Secure SOAP-message exchange (XML content is abbreviated for clarity).

276 Security for Web Applications <bs:CreditCard Issuer="www.chiefcard.com">

<bs:Number>0123 4567 8901 2345 </bs:Number> <bs:Expires>01/10</bs:Expires> <bs:Owner>Alice</bs:Owner>

</bs:CreditCard>

Alice’s credit card information is encrypted with ChiefCard’s public key, e.g., using RSA encryption. The cipher data is included in the SOAP body within an EncryptedData element as illustrated in Figure 13-7.

Without going too much into the details of XML Encryption, which is beyond the scope of this chapter, the EncryptedData element may declare the applied encryption algorithm, information about the key used to encrypt the data, the cipher data itself or a reference if it is stored elsewhere and data type and data format of the plain text.

With the exception of the cipher data, the information items of EncryptedData are optional. If not present, the recipient must know how to handle the encrypted information, e.g., which algorithm to use for deciphering. When using symmetric cryptography, the respective shared key can be contained in the key information section of the EncryptedData – of course not in plain text but as an encrypted value itself, e.g., using asymmetric encryption.

Figure 13-7 also illustrates the usage of XML Signature (W3C, 2002c) to include digital signatures into XML documents. In the example, XML Signature is employed to ensure the integrity of Alice’s order. A Signature element includes the value of the signature, information about the signature generation (i.e., the employed algorithms), and optional information for recipients on how to obtain the key required for signature validation (this can include names, keys itself or certificates). The Signature elements can be enveloping, i.e., contain the signed data as depicted in the figure, or refer to detached data, just like EncryptedData elements.

If not taken into consideration, digital signatures do not prevent replay attacks, i.e., the repeated sending of the same message (or message part, in case the signature does not depend on the complete message). For instance, when a malicious third party intercepts the transaction and sends the original request repeatedly, the book order request may be processed several times. Therefore, it is suggested that the signature is different for each message, e.g., by depending on timestamps so that replay attacks can be detected.

To summarize, encryption at the message layer is used for Web based transactions that require end-to-end security. The primary objective of signing (parts of) messages is to ensure message integrity and non-repudiation, but it also allows authenticating the signer’s identity.

13.4.3 User Authentication and Authorization Authentication Authentication is concerned with the verification of a user’s identity. A widespread authentication

method is the well-known login/password-mechanism. Clients provide their username and a password to be authenticated. It is good practice not to transmit login information in plain text but to use SSL-secured connections instead. Another way to authenticate a user’s identity is to employ digital certificates. Since most end users do not possess certificates, this authentication method is not yet very widespread for B2C (business-to-consumer) applications today. But

13.4 Secure Client/Server-Interaction 277 it is recommended and more usual for B2B (business-to-business) applications, or for the

authentication of employees within a company’s Intranet. In order to avoid repeated authentication, dedicated authentication systems like Kerberos (Kohl and Neuman 1993) can be used. Clients receive encrypted security credentials (tickets) from authentication servers. These tickets can be used to be authenticated at application servers. Usability is enhanced, when single sign-on is offered to clients. Once registered within the federation, authentication is performed by the underlying security system. Former versions of Kerberos were designed to perform centralized authentication within closed trust domains. With Kerberos 5, distributed authentication among systems that are protected by distinct Kerberos systems is possible. Thus, users can comfortably access resources of service providers participating in a collaboration network. Systems enabling single sign-on on the Internet are Microsoft’s Passport and the Liberty Alliance. 1

Authorization Authorization policies specify what authenticated users are allowed to do. Different access

control models exist for administering authorization, e.g., see (De Capitani di Vimercati et al. 2005, Rabitti et al. 1991, Jajodia et al. 2001). We will focus on discretionary access control (DAC) according to which privileges or prohibitions are explicitly assigned to subjects (users). Thereby, a privilege states that a certain resource, for example a file or a Web service method, can be accessed in a certain way, e.g., read or executed. Prohibitions, on the contrary, state that a certain kind of access is explicitly not allowed. Access control lists (ACL), which are very popular with file systems, follow the DAC principles by declaring access permissions like read/write access on files and directories for individual users or groups of users. If the number of users is potentially very large, which applies to many Web applications, it is recommended to use role based access control (RBAC, Ferraiolo et al. 2001) to improve scalability by reducing the administrative effort. Instead of directly assigning access rights to individual users, privileges and prohibitions are assigned to roles. Considering our example, book.store.com might introduce

a role Standard that grants the right to buy books by credit card. Every registered user is granted this role by default. If customers have proven to be reliable, e.g., by having bought several articles and by having good credit ratings, they are granted the Gold-role that implies the Standard-role and additionally allows buying books on invoice.

This small example shows that the access rights a user is granted do not only depend on the user’s identity, i.e., who he or she is, but also on his/her attributes that determine the level of trustworthiness. Thus, access rules might depend on a user’s context like age or consumer behavior and can change dynamically.

Regarding security and software engineering principles it is best practice to separate the software component for enforcing authorization – also called the policy enforcement point (PEP) – from policy evaluation, i.e., the policy decision point (PDP). To give an example, a Web service acts as a PEP when it enforces that only authorized users are allowed to invoke certain service methods. The underlying Web service platform provides the respective PDP functionality for evaluating authorization policies. Thereby, it is recommended to store these policies separately from the PEP, e.g., behind firewalls and, thus, inaccessible to the outside.

1 http://www.projectliberty.org/

278 Security for Web Applications Authorization can take place in a distributed manner (Tolone et al. 2005). Let’s assume that

book.store.com cooperates with music.store.com and dvd.store.com. They want to improve their business by offering a joint portal called media.store.com, where customers can buy multimedia products using a single shopping cart. Apart from realizing a federated identity management, e.g., by employing Liberty Alliance, access control has to be consolidated. Figure 13-8 shows two basic concepts of how to realize access control within the federation. If a tightly coupled architecture is chosen, as shown in the left part of the figure, access control is shifted to media.store.com, i.e., one central PDP is realized with all relevant access control rules directly being enforced at media.store.com. Alternatively, as illustrated in the right part, all three stores maintain their authorization autonomy by enforcing access control on their own, thus realizing

a loosely coupled federation. What are the pros and cons of the respective architectures? When deciding how to design authorization for federated systems, two counteracting objectives have to

be considered, namely performance and preservation of autonomy. By choosing the cooperation to be tightly coupled, the federating organizations transfer all relevant authorization policies to a central authority (media.store.com in the example). Access control then proceeds by a (media.store.com-)local policy evaluation and no communication with any of the federating service providers is required. But the service providers give up at least part of their authorization autonomy by disclosing policy settings to the central authority. The opposite applies to loosely coupled systems: the service providers remain independent but authorization at media.store.com requires a more time-consuming distributed policy evaluation. The most significant advantage of loosely coupled federations is that they do not rely on permanent trust relationships. Thus, co-operations can be established and revoked as required without running the risk of transferring security relevant information to a central authority that won’t be trusted any longer. As described in (Wimmer et al. 2005) performance of access control in loosely coupled federations can be improved through adequate caching techniques.

Access Rules

music.store.com

Access Rules

music.store.com

Access Rules Authorization

media.store.com Rules media.store.com

Access

Request

Access Rules Access Rules Authorization Authorization Access

Request Rules

Access Rules

dvd.store.com Figure 13-8 Tightly coupled (on the left) and loosely coupled (on the right) federations.

book.store.com

dvd.store.com

book.store.com

13.4.4 Electronic Payment Systems For e-commerce, cashless payment systems are required (Garfinkel 2002, Manninger et al. 2003).

At present, credit cards are a very widespread payment system used for Internet transactions. Customers transmit their name, credit card number, and expiration date to the vendor or a trusted intermediary payment service. In order to reduce the risk of fraud and identity theft, SSL-secured channels are used for transmission. Such a payment constitutes a card-not-present transaction,

13.5 Client Security Issues 279 as the vendor does not actually hold the customers credit card in hand and, thus, cannot verify

its validity, e.g., based on the customer’s signature. Therefore, additional validation steps can be performed, e.g., a check whether the billing address provided by the client is correct. Obviously, there is a trade-off regarding the quality of the provided information and ease of use, that is, whether typos are tolerable or not, which can either reduce evaluation quality or hinder trade. Another often used technique is the validation of additional digits that are typically printed on the signature strip on the back of the credit card.

Apart from well-known credit card payment systems, various Internet-based payment systems have been developed, like Virtual PIN, DigiCash, CyberCash/CyberCoin, SET or PayPal. The first three systems suffer from limited acceptance by customers, financial organizations and/or vendors. SET stands for Secure Electronic Transaction and is an initiative powered by MasterCard, Visa and software companies like Microsoft and others. When paying online, the customer’s credit card number is encrypted and sent to the vendor where the payment information is digitally signed and forwarded to the processing bank. There, the message is decrypted and the credit charge is processed. Thus, the credit card information remains private and is not available to the vendor in plain text.

PayPal belongs to the eBay company and is an electronic payment system easing payment trans- actions between arbitrary users. Thus, it is not only applicable to the standard vendor–customer scenario but particularly applicable to online auctions. Its popularity comes from its ease of use. The only prerequisites for sending money to a contracting partner are the possession of a valid e-mail address and a PayPal account. New Web-based payment systems like PayPal are very popular in particular in countries like the USA. In Europe, for example, online banking offers a reliable and approved alternative. Regarding e-commerce, it is quite usual that trust between customers and vendors is not prevalent at an initial stage. Thus, refund and charge-back capabilities of the newly arising electronic payment systems are of high relevance with regard to conflict resolution, e.g., in cases when order transactions have to be rolled back because of goods having been rejected or not having been delivered.