Security Basics

By the very nature of this platform, your WAP applications are Internet applications. In order for a user to reach your application, he must connect through his local Internet service provider (ISP) to a WAP gateway before requesting data from your Web server. This request from the WML browser will travel between many different systems before it reaches your application code.

Any application on the Internet is subject to some basic security problems. This section will help you understand the risks involved to your user's trust by examining the basics of security, the system's architecture, and the potential threats.

Security Basics

Before I dive into the guts of security, you should be familiar with the fundamental jobs that a security system attempts to provide for you. To begin with, let's look at simple communication between a sender and receiver as shown in Figure 12.1.

The sender might be one of your users, while your application is the receiver. Internet security systems often provide confidentiality, authentication, integrity, and non-repudiation for data exchanged between the user and the application.

• Confidentiality. It should be difficult for an eavesdropper to understand the contents of a message between the sender and receiver. Systems often achieve this goal by encrypting the message so that it would take many resources (time, computing power, and so on) to retrieve the original.

• Authentication. Both the sender and receiver should be able to verify the identity of the other and reject impersonators. Systems often implement this using a trusted third party that vouches for the identity.

• Integrity. The receiver of a message requires assurance that the contents received are identical to the contents sent. A security system typically accomplishes this by providing a signature for each message, based on its contents, that is very hard to alter.

• Non-repudiation. Finally, either the sender or the receiver of the message must be permitted in the future to prove that the message was sent and received. This is often done by requiring each party to sign its message using a signature registered with a trusted third party.

Not every application security system addresses each of these issues; each will only provide the facilities that are practical and required for the environment. As an example, let's look at contemporary Web applications.

Today, most widely deployed Web applications use HTML browsers that employ a technology called the Secure Sockets Layer (SSL) that ensures confidentiality. This communication layer sits above the HTTP and TCP/IP layers and encrypts each request and response to and from the server. To accomplish this encryption, SSL uses public key cryptography, in which both parties map plain text into cipher text. The information sender encrypts using a private value, or key, and gives the receiver a key to reverse the operation.

The SSL also provides integrity by adding a mathematical hash value to each message. It calculates this value by examining each piece of the message; the calculation algorithm guarantees that it is very difficult to replace any or all of the message and still produce the same hash.

In addition to SSL, most secured Web sites use a digital certificate purchased from a third party that vouches for the identity of the site's owner. This allows the browsing user to verify that the site to which he is sending data is actually the site he intends. This provides authentication of the receiver. Most sites use a name and password to authenticate the sender because, although personal identification digital certificates are available, they are still not widely used.

In similar fashion to the authentication typically employed, most Web applications implement weak non-repudiation. In fact, most use only the authentication information they gather from the user to prove that he transmitted a message.

Threat Models

Now that you have an idea of what facilities a security system should provide your application, let's look at why it should provide them. Each piece of the security system exists to thwart a particular attack, or threat model. These models attempt to clarify how a foe might cause you and your users harm.

The first and probably most often cited threat is the eavesdropper attack. This threat is a passive attack in which the foe does not interfere with the exchange of information; she merely records the data for other, probably unauthorized, uses. The attacker simply watches the data travel from the sender to receiver and records a copy of it.

To prevent the eavesdropping attack, most security systems provide confidentiality using an encryption algorithm. Of course, no encryption is or ever will be perfectly secure; the eavesdropper, given enough time and energy, will be able to break through it. To be effective, a security system simply recognizes that and chooses a scheme that makes the price much higher than the value of the information exchanged.

Another threat model is the impersonation attack, sometimes known as the Trojan horse attack. This is a more active attack in which the attacker creates a harmful Web application that appears to the user to be legitimate. This rogue application can then ask the user for his authentication information or even sensitive data such as a credit card, social security number, and so on.

Effective Trojan horse applications will gather the desired data from the sender and pass her along to the legitimate application. To prevent this attack, the legitimate site contracts a trusted third party to vouch for its identity and provide a mechanism for clients to verify that identity when making requests. This, of course, requires the client to check these credentials before sending sensitive information.

The Man-in-the-Middle attack is an active attack similar to the Trojan horse; the attacker places himself between the sender and receiver as shown in Figure 12.2. This allows him to intercept all communication between the two parties and replace it with his own.

Since the attacker has interposed himself and both the sender and receiver think that he is the other party, he has both the opportunity to monitor all information exchanged and to alter that information. This is a potent threat that a security system can again counter with proper use of authentication.

A more direct threat to the security of your application lies in the Dictionary attack. In the direct variant of this attack, the foe takes a list of commonly used passwords and attempts to log in to your application as a known user. There are several ways to reduce the threat against this happening to your application: you can require passwords that are hard to guess (for example, [word][number][word] format) or you can prevent multiple successive attempts at authentication.

One final threat model with which you may find yourself faced while creating Web applications is the Replay attack. In this scenario, the attacker eavesdrops on a session between a user and your application. Once the user has stopped using the application, the attacker simulates another identical set of operations.

This threat is especially potent when, for example, the user is transferring funds. In order to prevent this, the security system will need to ensure that the authentication of the sender is time-sensitive and a later replay with the same data fails.