AJAX In Action [131]
7.3.1 The man in the middle
Let’s suppose you’ve just written an Ajax application that sends financial details, such as bank account numbers and credit card details, across the Internet. A wellbehaved router transmits the packet unchanged without looking at anything other than the routing information in the packet headers, but a malicious router (figure 7.6) may read the contents of the transmission (say, looking for credit card numbers in the content or valid email addresses to add to a spam list), modify routing information (for example, to redirect the user to a fake site that mimics the one she is visiting), or even modify the content of the data (to divert funds from an intended recipient to his own account, for instance).
Ajax uses HTTP both for transmitting the client code and for submitting data requests to the server. All of the communication methods we’ve looked at—
Licensed to jonathan zheng 264 CHAPTER 7 Security and Ajax Web browser Server Password Password Password Password Routing node Routing node Password Figure 7.6 Password Routing node In an ordinary HTTP transmission, data is transmitted across the Internet in plain text, allowing it to be read or modified at intermediate The Internet nodes by the man in the black hat. hidden IFrames, HTML forms, XMLHttpRequest objects—are identical in this respect. As with any web-based application, a malicious entity looking to interfere with your service has several points of leverage. Exploiting these weak points are known as “man-in-the-middle” attacks. Let’s look at the measures we can take to protect ourselves from them. 7.3.2 Using secure HTTP If you are concerned about protecting the traffic between your Ajax client and the server, the most obvious measure you can take is to encrypt the traffic using a secure connection. The Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) provides a wrapper around plain-text HTTP, using public-private key pairs to encrypt data going in both directions. The man in the middle still sees the data packets, but because the content is encrypted, there is nothing much that he can do with them (figure 7.7). HTTPS requires native code support on both the browser and the server. Modern browsers have good support for HTTPS built in, and most web-hosting firms now offer secure connections at a reasonable price. HTTPS is computationally expensive, and transfers binary data. JavaScript is not a natural choice here; just as we wouldn’t try to reimplement the DOM, CSS, or HTTP using JavaScript, HTTPS is best viewed as a service that we use, rather than something we can override and replace for ourselves. Licensed to jonathan zheng Protecting confidential data 265 Web browser Server Password Password Encryption Encryption xxxxxxxxx xxxxxxxxx Routing node ? Routing node xxxxxxxxx xxxxxxxxx Routing node Figure 7.7 Using a secure HTTP connection, data is encrypted in both directions. Intermediate nodes still see the encrypted data but lack The Internet the necessary key to decrypt it. Let us introduce a few caveats about HTTPS. First, the encryption and decryption do introduce a computational overhead. At the client end, this is not a significant problem, as a single client need only process one stream of traffic. On the server, however, the additional load can be significant on a large website. In a classic web application, it is common practice to transmit only key resources over HTTPS and send mundane content such as images and boilerplate markup over plain HTTP. In an Ajax application, you need to be aware of the impact that this may have on the JavaScript security model, which will recognize http:// and https:// as distinct protocols. Second, using HTTPS secures only the transmission of data; it is not a complete security solution in itself. If you securely transmit your users’ credit card details using 128-bit SSL encryption