Summary 277

var key="password"; function getEncryptedKey(){

return b64_md5(key);

}

This solution still requires us to initially communicate the variable key to the Ajax client. We might send the key for the session over HTTPS when the user logs into the application. In reality, the key would be something random, not a string as simple as “password” of course.

The strength of this particular solution is that the HTTP header information can’t be modified from a standard hyperlink or HTML form. Requiring the hacker to use a programmatic HTTP client will stop the less determined ones, at least. Of course, as the use of XMLHttpRequest becomes more prevalent, the knowledge of how to craft HTTP headers within web page requests will spread. Programmatic HTTP clients such as Apache’s HTTPClient and Perl LWP::UserAgent have been able to do this for a long time.

Ultimately, filters and similar mechanisms can’t make it impossible for external agents to get into your site, but they can make it more difficult. Like any other developer, evil hackers have limited resources and time on their hands, and by securing your application in the various ways we have outlined above, you certainly discourage casual interference with your data services.

This concludes our discussion of security for Ajax applications. There are several aspects to securing an Ajax application that we haven’t covered here, because they are largely the same as for a classic web application. A good authentication and authorization mechanism helps to control access to services based on roles and responsibilities. Standard HTTP headers can be used to verify the origin of callers, making it harder (but not impossible) to invoke the services outside the official channels. We recommend consulting the literature on web-based security for those of you with a deeper interest in securing your Ajax applications.

Finally, remember that security isn’t an absolute state. Nothing is ever completely secure. The best that you can hope for is to be one step ahead of any intruders. Using HTTPS where relevant, minimizing exposure of your webbased API, and judiciously using HTTP request checking are all good steps in that direction.

7.5 Summary

In this chapter, we discussed security implications of using Ajax. We concentrated on security issues that were different for Ajax than for conventional web

278CHAPTER 7

Security and Ajax

applications. First, we looked at the sandbox governing the use of JavaScript within the web browser and the rules that prevent code from different sources from interacting with each other. We saw how to relax the server of origin policy, with the user’s consent, in order to access third-party Internet services such as the Google API.

Second, we looked at ways of protecting data as it passes between the client and the server. HTTPS is the recommended industry-strength solution here, but we also presented a simple Ajax-based way of transmitting passwords securely over plain-text HTTP. Finally, we saw how Ajax has a specific vulnerability owing to the way raw data is provided for consumption from the server. Having evaluated this as a serious threat in some cases, we looked at ways of designing the server architecture to minimize exposure to such risks. We also described ways of programming the server to make external access to data more difficult.

The issues that we’ve tackled in this chapter should help you to tighten up your Ajax applications for use in the real world. In the next chapter, we continue the theme of grim realities with a look at performance issues.

7.6 Resources

Keys for the Google web service APIs may be obtained at http://www.google.com/ apis/.

The JavaScript MD5 libraries of Paul Johnston can be found at http:// pajhome.org.uk/crypt/md5/md5src.html. For those wanting a quick taste of MD5, visit the online checksum generator at www.fileformat.info/tool/hash.htm?text= ajax+in+action.

The Apache Commons Codec library for Java, which we used to generate our Base64-MD5 on the server, can be downloaded at http://jakarta.apache.org/commons/codec/.

In section 7.1, we looked at signing JAR files to create secure applications for Mozilla browsers. The official word on that can be found at www.mozilla.org/ projects/security/components/signed-scripts.html. You’ll find some background information on the Battleship game at http://gamesmuseum.uwaterloo.ca/vexhibit/Whitehill/Battleship/.