AJAX In Action [133]
The random string is the public key. It is visible to all, and disposable. Our password is the private key. It is long-lived, and is never made visible. A JavaScript implementation
Implementing this solution requires an MD5 generator at both the client and the server. On the client, Paul Johnston has written a freely available generator library in JavaScript (see the Resources section). Using his code is just a matter of including the library and invoking a simple function:
On the server tier, MD5 algorithms are available for most popular languages. PHP
has had a built-in md5() function since version 3. The java.security.MessageDigest class provides a base implementation for Java encryption algorithms and implementations of a number of common algorithms, including MD5. The .NET
Framework provides a System.Security.Cryptography.MD5 class.
This technique has limited usefulness, since the server must already know the data being encrypted in order to facilitate a comparison. It is ideal as a means of providing secure login capabilities without recourse to HTTPS, although it can’t substitute for HTTPS as an all-around secure transmission system.
Let’s review where are now. The server of origin policy is safeguarding our users’ computers from malicious code. Data exchanged between the client and the server is protected from man-in-the-middle attacks by HTTPS. In the final section, let’s look at a third point of attack, the server itself. You’ll learn how to secure your own web services from unwanted visitors.
Licensed to jonathan zheng 268 CHAPTER 7 Security and Ajax 7.4 Policing access to Ajax data streams Let’s begin by reviewing the standard Ajax architecture, in order to identify the vulnerability that we’ll discuss in this section. The client, once it is running in the user’s browser, makes requests to the server using HTTP. These requests are serviced by web server processes (servlets, dynamic pages, or whatever) that return streams of data to the client, which it parses. Figure 7.8 summarizes the situation. The web services or pages are accessible by external entities, without any additional work on our part—that’s just how the Internet works. It may be that we encourage outsiders to use our web services in this way, and we may even publish an API, as eBay, Amazon, and Google, among others, have done. Even in this case, though, we need to keep security in mind. There are two things we can do, which we discuss in the following two sections. First, we can design our web services interface, or API, in such a way that external entities cannot subvert the purpose of our web application—say, by ordering goods without paying for them. Second, we look at techniques to restrict access to the web services to particular parties. 7.4.1 Designing a secure web tier When we design a web application, we typically have an end-to-end workflow in mind. In a shopping site, for example, the users will browse the store, adding items to their baskets, and then proceed to checkout. The checkout process itself will Web browser Ajax client Data stream Server Figure 7.8 In an Ajax architecture, the server exposes web services to the Data stream Internet over a standard protocol, typically HTTP. The Ajax client The Internet fetches streams of data from the Web services server. Because of the public nature of the web services, external entities may request the data External entity directly, bypassing the client. Licensed to jonathan zheng Policing access to Ajax data streams 269 have a well-defined workflow, with choice of delivery address, shipping options, payment methods, and confirmation of order. As long as our application is calling the shots, we can trust that the workflow is being used correctly. If an external entity starts to call our web services