Secure Web Applications

12.4.1 Authentication

For Online Photo Shop, we must store each customer's profile to speed checkout and avoid recurring typing mistakes. However, before displaying any kind of previously collected payment or shipping information, we must determine who the customer is, a process known as authentication. The identity of a customer is usually authenticated by a login process, in which the customer is asked to enter a unique identifier together with a secret password (also referred to as credentials). This information is then compared against storage or a database, and the customer is authenticated if the information entered matches the information stored.

The requirement key F:customer_login defines the identifier as the customer's e-mail address. This not only is convenient for the customer but also simplifies the implementation. The application does not need to worry about the uniqueness of identifiers chosen by the customers. Instead, it can handle duplicate e-mail addresses as invalid inputs.

ASP.NET supports three very different mechanisms for authentication. Windows Authentication is an authentication service provided by Microsoft's Internet Information Services, in which IIS filters all requests and checks the user permissions even before ASP.NET is invoked to render a page. However, this mechanism can authenticate users only against Windows 2000 domain credential stores. Therefore, Windows Authentication can be recommended only for corporate intranets or similar applications. It also gives us no control over the user interface in which the credentials are entered. It therefore does not allow a custom design of a login form such as the one shown in Figure 12.1.

ASP.NET also provides an infrastructure called Forms Authentication. This product overcomes the limitations of Windows Authentication, but it requires the developer to design a login page and write code for registering new users and validating credentials of existing users. When a request for a page is made, ASP.NET automatically checks for an authentication ticket. If this ticket is not present, the request is redirected to the specified login page. The code behind the login page must then verify the user credentials, generate a new authentication ticket, and redirect the request back to the initially requested page. Because ASP.NET stores the authentication information in cookies, this method requires the user to enable cookies.

The third authentication method is called Passport. Here, Microsoft provides a centralized Internet authentication service, thereby eliminating the need for online shoppers to create a unique identifier and a password for each online store where they shop. Furthermore, users do not have to reenter their shipping and payment information because this information is also kept centralized. Without a doubt, Passport overcomes some inconveniences for online shoppers. However, a centralized service offering personal information such as home addresses, phone numbers, and credit card numbers becomes a likely target for hackers. Similarly, many people have legitimate concerns about their privacy when their authentication at all online stores is done through one company. On the other hand, people might feel more comfortable storing a personal profile at a service provided by a company that has a lot of expertise in the field of Internet security, rather than entering this information repeatedly at online stores that might not have the latest security patches installed or do not care very much about privacy.

After evaluating the advantages and limitations of all three mechanisms, we decide to implement the checkout process based on Forms Authentication. Open the project's Web.config file, change the authentication mode to Forms, and set the URL for the login page to Login.aspx:

12.4.2 Authorization

After a user has been authenticated, authorization controls access to certain areas or files. In Online Photo Shop, any anonymous Internet user can browse the catalog and place items in the shopping cart. However, to proceed to the checkout, all customers must identify themselves in order to retrieve personal information stored during previous visits. Therefore, access to the checkout area is restricted to registered customers only; in other words, only registered customers are authorized to enter the checkout area.

To define a new area where different authorization attributes apply, we add a new folder to the project and name it checkout. To this folder we will later add the checkout and order confirmation forms. After creating the folder, open the Web.config file and add a new section to the configuration:

...

This section dictates that access to all pages under the checkout folder is restricted to authenticated users whose role is Customer. All others will be denied access to this folder.

12.4.3 Encryption

When a Web application exchanges data between the client and the Web server over the Internet, the data potentially could be hijacked by unauthorized parties. Remember that the Internet is a network of connected computers that can be operated by anyonesomeone from a company or organization, from a university, or from the government, including computer hobbyists or even criminals. You have no influence on how and via which nodes data packets are routed, and at any point someone could scan the packets for sensitive information such as credit card numbers.

Data is exchanged as-is using Transmission Control Protocol/Internet Protocol (TCP/IP) and is accessible to any computer through which it is routed. But you can make the data unreadable for others by encrypting it. Secure Socket Layer (SSL) does exactly that. All data transferred between the client and the server is encrypted using a secret key. The longer the key, the harder it is for an outsider to crack the encryption.

SSL runs between TCP/IP and higher-level protocols such as Hypertext Transport Protocol (HTTP). TCP/IP is used by SSL on behalf of the higher-level protocol, but it also allows two computers on the Internet to authenticate each other and establish an encrypted connection. Authentication is important to users if they are sending their credit card information to a server and want to check the server's identity. SSL uses standard public key cryptography techniques to validate a server's certificate and public ID. For this, the client checks a number of conditions:

• Has the certificate been issued by a certificate authority (CA) that is on the client's list of trusted CAs?
• Is today's date within the validity period of the certificate?
• Does the domain name specified in the certificate match the actual server's domain name?
• Does the issuing CA's public key validate the issuer's digital signature?

Only when all these questions can be answered yes is the server authenticated. After the authentication, an encrypted connection is established, and it requires the encryption of all sent information on the sender's side and decryption (translation of the encrypted data back into the original) by the receiver, thus making it unreadable by any third party in between. In addition, all data is secured using a mechanism for detecting whether the data has been tampered with during transmission.

The secure connection is established in a number of steps. First, the client creates a pre-master secret and encrypts it using the server's public key. After the server receives the pre-master secret, both client and server independently perform a series of steps to create a common master secret, starting with the same pre-master secret. This master secret is then used to generate symmetric session keys that are used to encrypt and decrypt information exchanged during an SSL session.

To be considered a secure application, Online Photo Shop must encrypt the customer authentication before storing it in a cookie. Furthermore, all forms under the checkout directory must be transferred between the Web server and the client using SSL to fulfill the requirement R:checkout_payment_secure. Using SSL requires no extra implementation but only a configuration effort. Because a cost is associated with obtaining secure server certificates, we will not focus on SSL configuration in this chapter. Instead, in the references section you will find references on obtaining a server certificate and setting up a secure connection via SSL.