CHAPTER

7

Ajax Challenges and Best Practices

Chapter Objectives

• Investigate technical challenges of Ajax applications

• Introduce best practices of Ajax development

• Present open-source tools for quality assurance

• Discuss security problems of Ajax applications

7.1 Overview

 

Although Ajax has quickly gained the favor of users, it nevertheless increases the complexity of web application development. Ajax developers face several new challenges, e.g., testing callback functions, debugging asynchronous calls, examining the frequently changing DOM structures, and avoiding racing conditions between concurrent asynchronous calls. Security is another serious concern because of Ajax worms. This chapter exposes you to the tricky issues and challenges that you should pay attention to when developing Ajax applications. It presents to you several useful tools for debugging and testing Ajax applications.

7.2 Diagnosis of Ajax Web Applications

 

Diagnosis and debugging of programs has been an indispensable part of software development since the birth of computers. Compared with traditional programming, Ajax web applications have raised several new challenges to software developers. First of all, Ajax web applications involve both servers and client-side programming. To troubleshoot a problem, one must explore both sides of the interaction. Second, debugging JavaScript is harder than that of traditional programming languages because JavaScript is a scripting language and lacks strong typing support. Third, Ajax web applications communicate with the server asynchronously. Compared with traditional web applications that adopt a simple request-response model, Ajax applications can have multiple XMLHttpRequest sessions going on, and concurrency can lead to errors that cannot be easily reproduced. This section discusses the diagnosis and debugging techniques that can be used to tackle these challenges.

7.2.1 Diagnosis of HTML

HTML files are often generated by server scripts (e.g., JSP and ASP.Net). When a dynamically generated HTML file has syntax problems, correct rendering of the page depends solely on the tolerance of the client browsers. As discussed earlier, this could easily lead to incompatibility of web pages. Inspection of HTML syntax can be accomplished via several tools.

W3C provides an online XHTML validation service called W3C Markup Validation Service (W3C, n.d.). Users can either submit the URL or directly paste the contents of an HTML file into the validator. The Web Design Group (WDG) also provides similar online HTML syntax validation services (WDG, n.d.). One problem with online validation services is that they can deal with only one page at a time. A better way is to verify the syntax of HTML pages generated by dynamic server scripts at run time. This can be accomplished by taking advantage of offline HTML syntax validation programs such as the WDG offline HTML validator (WDG, n.d.b). The offline validator can be called whenever the server-side script generates the HTML response at run time.

7.2.2 Diagnosis of JavaScript

Among the many program analysis approaches available to programmers, logging and debugging are probably the oldest and most frequently used ways to troubleshoot a program.

The basic idea of logging is to insert printing statements at various important places in a program. Reading the logs printed out by the program allows developers to read values of important data variables and identify the bugs present in a program. The logging technique can not only help in debugging Ajax web applications but also benefit from the Ajax technique.

One popular framework for logging JavaScript actions is the log4JavaScript framework (Down, n.d.). Log4JavaScript provides a set of JavaScript functions for logging. Users can call logger functions and log messages in six categories (trace, info, debug, warn, error, and fatal).

Listing 7.2.1 presents a sample JavaScript snippet that uses log4JavaScript. Line 1 imports the log4JavaScript.js file, which defines all assisting functions of the framework. Line 3 creates a logger object. Line 4 creates a popup window that displays the logged messages. Line 5 attaches the pop-up window to the logger object so that all messages logged will be sent to the pop-up window. You can also do remote logging by creating an AjaxAppender object (line 6). When any logging function of the logger object is called, the message being logged is sent to the remote server for recording. Line 8 writes a sample debugging level message, “Hello World!” The complete sample code of Listing 7.2.1 can be found on this book's website. The file is located in folder /Ch7/CodeExamples/log4JavaScriptExample.

Listing 7.2.1

Sample Logging Statements

Although JavaScript logging provides a convenient way of tracking what happens at the client side, debuggers can usually provide many more powerful tools such as breakpoint, single-step execution, inspection of variables at run time, and display of calling stack. Many JavaScript debugging tools have been made available, e.g., the Venkman JavaScript Debugger (Mozilla.org, n.d.) and the Microsoft Script Debugger (Microsoft, n.d.). Both tools provide debugging of JavaScript at the client side. Microsoft Script Debugger also allows debugging ASP.Net scripts at the server side and can be triggered by including a statement in the code to start execution of the debugger. Figure 7.2.1 shows one application scenario of Microsoft Script Debugger. It illustrates how easy it is to use breakpoint to debug a JavaScript snippet. The complete source code required by this example can be found in the following folder on this book's website: /Ch7/CodeExam-ples/MicrosoftScriptDebugger/. To run this example, you must install the Microsoft Script Debugger in Internet Explorer. The installation procedure might vary depending on the operating system and the version of the web browser on your computer. However, in general, the installation process is straightforward.

The sample HTML page shown in Figure 7.2.1 consists of one hyperlink, whose onMouseOver event is handled by a JavaScript function called showAlertBox(). To illustrate the breakpoint function provided by Microsoft Script Debugger, you will set a breakpoint at the highlighted alert statement in Figure 7.2.1. Open the file with Internet Explorer and then enable the debugger by clicking the View menu, Script Debugger item, and then Open Command. (The Script Debugger menu is available only after the Microsoft JavaScript Debugger has been successfully installed.) In the script debugger window, you can set a breakpoint on the target line. Go back to the Internet

Figure 7.2.1

Example of Using the Microsoft Script Debugger

Explorer window and move the mouse over the link; the breakpoint in the debugger is hit. Then you can start the command window to watch variable values and examine the calling stack.

Microsoft Script Debugger provides another useful breakpoint function called Stop at Next Statement. It allows determining the JavaScript function that handles a certain event, without the need to examine the source code of a web page. The stepping functions provided by Microsoft Script Debugger enable you to execute control flow step by step. The Venkman debugger on Mozilla browsers provides a similar function.

7.2.3 The Challenge of Asynchronous Call in Debugging

The challenge of debugging Ajax applications, different from other web applications, is that Ajax applications can send requests to the server side asynchronously via XMLHttpRequest. This concept raises interest in intercepting data exchanged between client and server, for analyzing the correctness of the client-side script.

As pointed out by Mahemoff (2006), there are generally three approaches for tracking the data passed by XMLHttpRequest: (1) Use wrappers of XMLHttpRequest to record data submitted by XMLHttpRequest. (2) Set up a proxy for the client side so that all data transmitted to the server is recorded by the HTTP proxy. (3) Use a generic network traffic sniffer such as Ethereal (www.ethereal.com, n.d.).

Approach 1 is usually the most convenient. However, it is effective only when all asynchronous calls are placed using the wrapper function. Approach 3 is usually overkill because normally you will not be interested in data payload at network layers other than HTTP. Approach 2 is the most effective and enjoys the support of many tools. For example, the XML-HTTPDebugging (Couvreur, n.d.) allows tracking, filtering, and displaying XMLHttpRequest-related data.

7.2.4 Profiling

Another important part of diagnosing Ajax applications is analyzing and profiling performance. Many factors could dampen the performance of an Ajax application, e.g., network bandwidth, availability and performance of server-side scripts, and efficiency of JavaScript functions at the client side. There are usually two different approaches for analyzing performance. One way is to record the starting and ending time of JavaScript functions with the aid of JavaScript loggers. The other way is to rely on integrated profiling tools.

On Firefox browsers, a tool called Firebug (Hewitt, n.d.) can provide powerful support for profiling. Firebug is installed as a third-party add-on in the Firefox browser. The installation process is straightforward. Once the tool is installed, by clicking the Firebug logo at the lower-right corner of the browser, a developer can conveniently start the Firebug console. As shown in Figure 7.2.2, the Firebug console has a list of buttons such as Console, HTML, CSS, Script, DOM, and Net. Click the Console button. You will notice that the tool starts to tick and records each activity (e.g., execution of JavaScript function and firing of XHR calls) of the page. If you are interested in network transmission only, you can click the Net button. Firebug will then display information related to each HTTP request. You can examine the response time and data payload contents of each packet. You can also inspect the dynamic DOM structure (the attributes of each HTML element of the page, including those created and modified by JavaScript at run time) by clicking the DOM button.

Figure 7.2.2

Profiling Using Firebug

7.3 Testing Ajax Web Applications

 

Unlike debugging, which is used for troubleshooting known problems, the objective of software testing is to discover unknown problems of a software system. Usually, a testing engineer must evaluate not only the logical correctness but also the security, reliability, robustness, and many other quality attributes of a program. The birth of Ajax has raised several new challenges:

1. How do testers ensure the logical correctness of an Ajax application at both the client and server sides?

2. How do testers evaluate an Ajax application in a complex client environment? For example, the use of different browsers and different versions could greatly affect the behaviors of an Ajax application at the client side. The bandwidth of the network could influence the performance and even the logical correctness of an Ajax application.

3. How do testers thoroughly test an Ajax application with multiple concurrent asynchronous call sessions? Concurrency is usually a central cause of many tricky problems (such as the racing condition) that cannot be reproduced easily.

This section introduces several techniques and tools for meeting the aforementioned challenges. In general, you will follow best practices when testing an Ajax application. In the software engineering cycle, your testing activities can be divided into the following categories:

1. Unit testing: involves testing and evaluation of units and modules of a system.

2. Integration testing: can expose problems when different components are integrated into the system.

3. System testing: evaluates whether the whole system meets both the functional and nonfunctional requirements.

7.3.1 Unit Testing

A unit refers to the minimal testable part of a program. For example, in structured programs, a unit can be a function or procedure. In object-oriented programming, a unit can be a class or a method of a class. Testing units from bottom to top has many benefits. First, it allows developers to better understand the definition of units. The unit testing design of each unit is usually an important part of documentation. Second, it allows better organization of a program. When all units are clearly defined and implemented, they can be easily reorganized when software requirements change. Most importantly, unit testing can greatly reduce the cost of software development. The earlier a bug is discovered, the lower the cost. A complete examination of various unit testing techniques and the general guidance of unit testing activities can be found in the IEEE unit testing standard (IEEE Standards Board, 1986).

Unit testing can usually be automated because the functions and the pre-and post conditions of a unit can often be well defined. In automated unit testing, a test case is expressed using a test script, and then the script can be executed multiple times as needed. Clearly, automated unit testing can significantly reduce the cost of regression testing, which is conducted frequently when part of the system is modified.

To cater to the needs of automated unit testing, many unit testing frameworks have emerged since the 1990s. Typical examples include the JUnit framework (JUnit.org, n.d.) for the Java language and the NUnit framework (NUnit.org, n.d.) for the Microsoft .Net platform. In the area of unit testing of web applications, several supporting tools are available. JSUnit (Hieatt, 2001) can be used for unit testing of JavaScript, and JSCoverage (siliconforks.com, 2007) is a profiling tool that evaluates and reports statement coverage of tests.

In the following, you will use JSUnit via a simple example. JSUnit follows the design idea of JUnit. It supports many testing entities in JUnit, e.g., the test case and test suite. JSUnit has a test runner program that executes test cases and displays results.

A unit in JSUnit is a JavaScript function. The test suite of a unit is a collection of test functions. All test functions should be contained in an HTML page that includes a JavaScript file called jsUnitcore.js. The file comes with the JSUnit framework. It defines all assisting functions provided by the framework. To set up and tear down test suites, JSUnit provides two functions, setup() and teardown(). The setup() function is called when a test function is executed, and the teardown() function can contain operations that need to be performed whenever a test function is completed. The JSUnit TestRunner page can be used to run test case pages.

Now you will use the JSUnit framework to test a simple JavaScript function named sort(). The source code of sort() is presented in Listing 7.3.1. It is an implementation of the bubble sort algorithm. Given the name of an HTML select control (drop-down list), the sort() function rearranges the contents of the select control in alphabetical order. The current implementation in Listing 7.3.1 has several bugs.

Listing 7.3.1

JavaScript sort() Function

The first step of your unit testing is to design a test page that consists of two test cases. The source code of the test page is shown in Listing 7.3.2.

1. testText. The first test case verifies that after the sort() function is completed, all the items in the HTML Select control should be in ascending alphabetical order.

2. testRobustness. The second test case verifies that sort() can handle the exception that the input parameter (the HTML select control) of sort() does not exist.

As shown in Listing 7.3.2, the body of the HTML page contains two select controls and several JavaScript functions. The setup() function initializes the first select control with two options and leaves the second select control empty. The teardown() function clears the contents of the first select control. These two functions are called by the JSUnit framework before and after executing a test function, respectively. There are two test functions: testText() and testRobustness(). Both functions use an assisting function named testTextOf(controlName), which verifies that all items in the HTML control named controlName are in alphabetical order. At the beginning of the file, several JavaScript files are included. The first is jsUnitCore.js, which is part of the JSUnit framework, and the second is bubbleSort.js, which contains the sort() function to be tested.

Launch a browser and open a file called TestRunner.html. The TestRun-ner.html file comes with the JSUnit framework. Using the file, you can specify and load the HTML test case file. Click the Run button, and all the test functions contained in your test case file will be executed. The details of the test results for each test case are displayed (as shown at the bottom of Figure 7.3.1). A tester can select different tracing information levels. Detailed tracing information can be provided to substitute for the use of JavaScript debugger.

As shown in Figure 7.3.1, the current implementation of the sort() function in Listing 7.3.1 fails the second test function. It cannot handle the exception that the given HTML select control does not exist. Actually, the implementation has more bugs. Designing more test cases for sort() is left as an assignment for you.

To repeat the simple experiment of JSUnit, you can find all related source files in folder /Ch7/CodeExamples/JSUnitExperiment/. First, go to a subfolder called jsunit2.2alpha11/jsunit and open the file named testRunner.html. Then click the Browse button and select testBubbleSort.html located in the /Ch7/CodeExamples/JSUnitExperiment/folder. Click the Run button and you will see two errors listed. Clicking any error in the list will bring up a detailed report for you.

Listing 7.3.2

Test Cases for sort()

Figure 7.3.1

Running JSUnit

Ajax developers would also need to develop unit tests for server-side programs. This can be achieved by using unit testing frameworks such as JUnit and NUnit, depending on the computing platforms used at the server side.

7.3.2 Integration Testing

Integration testing refers to the testing performed after unit testing. It takes the modules as input and verifies that all modules can interact with each other successfully. In general, there are two methods of integration testing: top down and bottom up. The top-down approach refers to the case that once all modules are unit tested, they are put together and run until problems are found and debugged. The bottom-up approach refers to the procedure that units are composed from the bottom up and tested at each level. The benefit of the top-down approach is fast evaluation of the whole system if all units are carefully composed. The benefit of the bottom-up approach is saving overall development cost because bugs can be discovered in the early stages of integration. For both approaches, JavaScript mock libraries such as JSMock (DeWind, 2006) can be helpful.

7.3.3 System Testing

System testing can be generally divided into functional testing and nonfunctional testing. Functional testing refers to testing activities that verify that a software system successfully accomplishes the functional requirements. Some years ago, verifying the functionality of a web application was a challenging task for testers. Because of the difficulty of testing in a graphical user interface (GUI), testers must manually interact with browsers. However, progress in automated testing has allowed developing scripts to describe test cases conveniently. In the following you will have a brief introduction to a web testing tool called Watir (Pettichord, Rogers, et al., n.d.).

Watir stands for “Web Application Testing in Ruby”. It is a functional testing tool for automating regression testing of web applications. In Watir, testing scripts are written using a scripting language called Ruby (Matsumoto, 1993). The basic idea of Watir is to drive Internet Explorer and programmatically simulate the human tester's actions. Using Watir, a tester can specify a sequence of operations on a web page, for example, redirecting to a page, clicking a button, simulating mouse-over actions, entering values into textboxes, and clicking radio buttons. Watir provides many powerful and rich access methods for locating HTML elements in a web page, e.g., by its name, identifier, URL, and even the text around it. These functions make Watir an ideal tool for verifying the functionality of web pages, and the Watir testing scripts can be reused in regression testing. In the following, you will study a simple code snippet of Watir script, which tests a system like Google Suggest.

Google Suggest is a typical Ajax application, which given a partial phrase in its textbox, provides a list of hints for completing that phrase. The snippet in Listing 7.3.3 executes a simple test case on the application. As shown in Listing 7.3.3, the first line of the script includes the Watir package required for testing. Then the second line starts an instance of Internet Explorer and then visits the site. It then enters a string, testing, into the textbox and waits for 2 seconds. Then it verifies that the resulting page (after the XHR request) contains test driven development in its hint list.

Listing 7.3.3

Simple Watir Example

There are extensions of Watir and many similar tools available for testing web applications. For example, if testers would like to use the C# language for its extended library support and more powerful language features, a package called WatiN (van Menen, 2005) is available for use. For another example, HtmlUnit (Bowler, n.d.) simulates a browser and directly manipulates DOM trees of web page document. The downside of the browser simulator is its compatibility problem with browsers and W3C standards.

7.4 Ajax Security

 

Since the 1990s, security has been a major concern of web application developers. Belonging to the web application family, Ajax applications might suffer from the vulnerabilities of a traditional web application. Ajax developers also face new challenges. This section exposes you to some of the typical security problems that an Ajax application might have.

7.4.1 SQL Injection Attack

SQL injection attack is probably one of the most frequently used attacks on web applications. The basic idea of SQL injection is to take advantage of weak input validation of web applications. When carefully crafted, a snippet of SQL code provided by an attacker can be embedded in a dynamically constructed SQL statement at the server side. Such a snippet can be used to accomplish malicious goals such as bypassing password check and destroying the back-end database.

Consider one simple Ajax application that checks out a user's shopping cart. Assume that there is one textbox that allows the user to type the product name. At the client side, whenever there is a keyboard event, the phrase contained in the textbox is submitted to the server. At the server side, a servlet is used for searching the complete product name given the partial phrase submitted via the XHR calls. To achieve the automatic completion function, the server-side script generates a SQL statement on the fly. The statement for constructing the SQL statement is shown in Listing 7.4.1.

As shown in Listing 7.4.1, the statement in essence concatenates several strings to form a SELECT statement. The SELECT statement retrieves the information of a product if its product name contains the string in txtPartialName as a substring. For example, if txtPartialName has the value ipod, then the SQL statement constructed is shown as follows.

Listing 7.4.1

Vulnerable SQL Statement

If the value of txtPartialName is not inspected and validated by the server code carefully, attackers might be able to exploit the string concatenation operation. For example, if a user types the following in the textbox, the background database can be destroyed.

When the preceding string is entered, the following SQL statement would be constructed on the fly. In the WHERE clause, the 1=1 makes it a tautology, then the drop table products destroys the table named products, and finally the -- comments out the last apostrophe to make the whole statement correct in SQL syntax.

Anley (2002) gave a complete examination of SQL injection attack and its variations. In practice, many SQL injection attack variations can be thwarted by strengthening user input validation. For example, when SQL statements are generated, SQL keywords such as DROP and -- can be filtered out. Restricting the length of user input can also be effective. If the structure of the SQL statement is not complex, programmers should avoid dynamic SQL statement construction via string concatenation. Many platforms such as .Net and JDBC provide a mechanism for passing dynamic values as SQL statement parameters. Many other interesting defense approaches have been proposed by researchers, e.g., detecting and blocking SQL injection attack via string analysis and instrumentation of web application programs (Halfond and Orso, 2005), tainted data tracing (Nguyen-Tuong, Guarnieri, Greene, Shirley, and Evans, 2005), and SQL keyword randomization (Boyd and Keromytis, 2004).

7.4.2 Cross-site Scripting and Cross-site Remote Forgery Attacks

Cross-site Scripting (XSS) attack is another typical form of code injection attack on web applications. It takes advantage of a user's trust in a website and can be used to steal user cookies. There are many variations of XSS attack.

Example 1. Assume that GardenMail.com is a web-based email system. It uses cookies to maintain session status after users log in. In this example, the victim, Venice, and the attacker, Alice, are both users of GardenMail.com.

GardenMail.com provides a special service called virtual flower that is not available in similar webmail systems. The service allows users to embed flower pictures in their emails. To do so, on the compose email page of GardenMail.com, there is a search box that allows the user to search for the picture of a flower by typing its name or the intended use. Once the search button is clicked, a request is sent to the server via XHR. The server will respond with a snippet of HTML, which is embedded in the email body. For example, if a user tries to search for flowers suitable as a birthday gift, the following HTML snippet will be generated and inserted into the user's email. At the server side, there is another servlet named getFlower. The servlet takes a query (in the form of GET parameter q) and displays the flower image retrieved from server database.

To defend against XSS attack, at the server side of GardenMail.com, each web email exchanged on the server must undergo inspection. The security inspection will remove any hyperlinks in the email, other than the one generated by GardenMail.com (i.e., the hyperlink that accesses the getFlower servlet). However, Alice can still trick Venice into an XSS trap. For example, Alice can type the following string as a query for flower:

The preceding query results in the following snippet to be embedded in Alice's email to Venice, which passes the security inspection. The code is the result of string concatenation executed at the server side.

Once Venice clicks the link, her current cookie is sent to getCookie.jsp located on hacker Alice's website. Alice could use the cookie to log in to Venice's account.

Example 2. Cross-site Remote Forgery Attack (XSRF) is a command injection attack similar to XSS. However, unlike XSS attack, which exploits a user's trust in a website, XSRF exploits a website's trust in the user.

Assume that superstockbroker.com is an online stock brokerage firm that provides online securities exchange to its customers. Once logged in, a customer can click the Buy and Sell buttons to submit transaction requests. At the client side, JavaScript functions handle the request of buy and sell and usually use XHR to invoke servlets at the server side. For example, a request to buy stocks can be achieved using the GET method, as shown in the following.

At the server side, there is a servlet named buystock that takes two parameters: stockid and amount. The parameters do not include the identifier of the user, because the site uses a cookie to identify each session.

Like many other stock brokerage firms, superstockbroker also provides financial research tools to customers. The financial research tool provides a collection of market analysis articles to users every day. It also allows experienced users to post articles and discussions of the market. However, access to these articles is limited to registered users and can be accessed only once they log in.

Alice, the attacker, decides to trick Venice into buying 1000 shares of AAA.COM. She posts an article that will be read by Venice. Inside the article, she embeds an invisible image as the following.

Once Venice tries to view the article, when her browser renders the image, the src attribute of the image will be immediately executed. Superstockbro-ker trusts the user because the user needs to log in to view the article and the cookie number is still valid. Thus, the request is executed and Venice is tricked into buying 1000 shares without being warned.

Strengthening input validation is required to defend against XSS and XSRF attack. Typical approaches include forbidding users to post JavaScript code. Requiring submission of data via POST instead of GET will also increase the difficulty of attack because a request cannot be constructed simply by appending parameter values to the URL. Another effective approach to defend against XSRF is to associate a random session ID (note: not a cookie) at the beginning of the session. Assign that session ID to a hidden HTML control at the client side and then have the client browser submit the same session ID in each subsequent action to post data. Such an approach can defend against the exploits of trust that are based solely on cookies.

7.4.3 Summary of Ajax Security

Does the use of Ajax worsen the security of web applications? What might be best practices for increasing the security of Ajax applications? There are many arguments on these issues, e.g., by Grossman (2006).

One common opinion on Ajax security is that the use of Ajax increases the attack surface of an application. Attack surface refers to the open, accessible parts of a system that are vulnerable to attacks. Because one page equipped with Ajax capability might have one or more server access points to handle the asynchronous requests, Ajax web applications do have more complex client-server interactions and potentially larger attack surface. Because at the client side JavaScript is used to submit Ajax requests, the signature of the access points at the server can be obtained by attackers via analyzing the JavaScript snippet embedded in HTML. Also, compared with the request-response mode adopted by traditional web applications, the interaction between client and Ajax applications is hidden from the user. Unless sniffers are used to monitor the network traffic, attacks on Ajax applications can be applied without being noticed by clients. Ajax might open new doors for many existing attacking approaches. You can find more information in the article by Stamos and Lackey (2006) that discusses various new attacks on Ajax applications.

7.5 Summary

This section discusses various challenges faced by Ajax developers, e.g., the challenges of diagnosing and testing Ajax applications, as well as security concerns. Fortunately, many advanced diagnosis tools are emerging. They can help Ajax developers in troubleshooting and analyzing Ajax applications. However, there is no simple cure for all problems. It is your responsibility to identify proper tools and use them effectively for meeting the challenges.

7.6 Self-Review Questions

1. Log4JavaScript allows recording client-side actions and sending logs to the server. This function relies on the use of the asynchronous call.

a. True

b. False

2. Log4JavaScript allows developers to set breakpoints in JavaScript functions.

a. True

b. False

3. Firebug is a unit testing tool for JavaScript.

a. True

b. False

4. When using JSUnit for unit testing, you must write testing functions. JSUnit cannot generate testing functions automatically for you.

a. True

b. False

5. Watir cannot be used to test Flash objects or Java Applets embedded in a web page.

a. True

b. False

6. Watir can access only HTML controls that are statically specified in an HTML file. Watir cannot manipulate HTML elements created dynamically by JavaScript at run time.

a. True

b. False

7. SQL injection could potentially cause the following damage.

a. Malicious login bypassing password check

b. Dropping data tables

c. Execution of arbitrary commands in the operating system

d. All of the above

8. XSS attack exploits a website's trust in the user.

a. True

b. False

Keys to the Self-Review Questions

1.a 2.b 3.b 4. a 5. a 6. b 7. d 8. b

7.7 Exercises

1. Think of a systematic way of using an offline HTML validator when authoring Java Servlets.

2. Think of a systematic approach for unit testing of server side script. Your approach must be platform independent. For example, it should be able to handle Java Servlets as well as ASP.Net pages.

3. Name three other web application testing tools other than the Watir package and its derivatives. Compare and contrast these tools.

4. Explain why using the POST method can increase the difficulty of executing an XSRF attack. Also explain why it cannot completely defend against XSRF attack.

5. Find another vulnerability of Ajax, other than SQL injection, XSS, and XSRF attacks. List possible counterapproaches.

7.8 Design Exercises

1. From Listing 7.2.1, design a server-side logger so that you can receive the logs remotely sent by Log4JavaScript (line 6 of Listing 7.2.1).

2. Provide two more testing functions for Listing 7.3.2 and find out potential bugs resident in the sort() function in Listing 7.3.1. Correct the bug and rerun the test by using JSUnit.

3. Use Firebug to analyze the latency of your network connection when you access the Google Maps service.

4. Write a Ruby script based on Watir that, given the ISBN of a book, extracts and returns the price of the book on an online bookstore such as Amazon.com.

7.9 References

Anley, C. 2002. Advanced SQL Injection In SQL Server Applications. Next Generation Security Software LTD. White Paper, 2002.

Bowler, M. (n.d.). HtmlUnit. Available at http://htmlunit.sourceforge.net/index.html.

Boyd, SW. and Keromytis, A.D. 2004. SQLrand: Preventing SQL injection attacks. In Proceedings of the 2nd Applied Cryptography and Network Security (ACNS) Conference, volume 3089 of Lecture Notes in ComputerScience, pages 292-304. Springer, 2004.

Couvreur, J. (n.d.). Ajax Debugging with Greasemonkey Available at http://www.blog.monstuff.com/archives/000252.html (accessed December 1,2007).

Cross Browser.COM. (n.d.). The X Library. Available at www.http://www.cross-browser.com/x/docs/x_quickstart.php (accessed December1,2007).

Dahm, T. (n.d.). Browser Compatibility Tutorial. Available at http://www.netmechanic.com/products/Browser-Tutorial.shtml(accessedDecember1,2007).

DeWind, J. 2006. JSMock. Available at http://jsmock.sourceforge.net/(accessedDecember1,2007).

Dojo Foundation (n.d.). Dojo toolkit. Available at http://dojotoolkit.org(accessedDecember1,2007).

Down, T. (n.d.). log4JavaScript framework. Available at http://www.tim-down.co.uk/log4JavaScript/(accessedDecember1,2007).

Grossman, J. 2006. Myth-Busting Ajax (In)security. WhiteHat Security Publication. Available at http://www.whitehatsec.com/home/resources/articles/files/myth_busting_ajax_insecurity.html (accessed December 1,2007).

Halfond, W. and Orso, A. 2005. AMNESIA: Analysis and Monitoring for Neutralizing SQL-Injection Attacks. In Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering, pages 174-183,2005.

Hewitt, J. (n.d.). Firebug. Available at https://addons.mozilla.org/en-US/firefox/addon/1843 (accessed December 1,2007).

Hieatt, E. 2001. JSUnit. Available at http://www.jsunit.net/ (accessed December 1,2007).

Hildebrand, J. Automatic HTML Validation. Available at http://wiki.w4py.org/automatic-html-validation.html

IEEE Standards Board. 1986. IEEE Standard for Software Unit Testing, Approved December 11,1986, and reaffirmed December 2,1993.

JUnit.org. (n.d.). JUnit framework. Available at http://www.junit.org/index.htm (accessed December 1,2007).

Keynote NetMechanic. (n.d.). Browser Compatibility Testing with Browser Photo. Available at http://www.netmechanic.com/products/browser-index.shtml?from=Gbc (accessed December 1,2007).

Koch, P.P. (n.d.). W3C DOM Compatibility Tables. Available at http://www.quirksmode.org/dom/compatibility.html (accessed December 1, 2007).

Mahemoff, M. 2006, Ajax Design Patterns, ISBN-13: 978-0596101800, O'Reilly Media, 2006.

Matsumoto, Y. 1993. Ruby Programming Language. Available at http://www.ruby-lang.org/en/.

Microsoft. (n.d.). Microsoft JavaScript Debugger. Available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdbug/Html/sdbug_1asp (accessed December 1,2007).

Mozilla.org. (n.d.). Venkman JavaScript Debugger. Available athttp://www.mozilla.org/projects/venkman/ (accessed December 1,2007).

Nguyen-Tuong, A., Guarnieri, S., Greene, D., Shirley, J., and Evans, D. 2005. Automatically hardening web applications using precise tainting. In Proceedings of the 20th IFIP International Information Security Conference, 2005.

NUnit.org. (n.d.). NUnit framework. Available at http://www.nunit.org/ (accessed December 1,2007).

Pettichord B., Rogers, P., et al. (n.d.). Web Application Testing in Ruby. Available at http://wtr.rubyforge.org/ (accessed December 1,2007).

siliconforks.com. 2007. JSCoverage. Available at http://siliconforks.com/jscoverage/ (accessed December 1,2007).

Stamos, A. and Lackey, Z. 2006. Attacking Ajax web Applications. Black Hat USA 2006. August 3,2006.

The Frontside, Inc. (n.d.). CrossCheck. Available at http://thefrontside.net/crosscheck(accessedDecember1,2007).

van Menen, J. 2005. WatiN (Web Application Testing .Net). Available at http://watin.sourceforge.net/ (accessed December 1,2007).

W3C 2007. The XMLHttpRequest Object W3C Working Draft. Available at http://www.w3.org/TR/XMLHttpRequest/, February 2007.

W3C (n.d.) W3C Markup Validation Service. Available at http://valida-tor.w3.org/ (accessed December 1,2007).

Web Design Group (WDG). (n.d.). Offline WDG HTML Validator. Available at http://htmlhelp.com/tools/validator/offline/index.html.en(accessed December 1,2007).

Web Design Group (WDG). (n.d.b). Online WDG HTML validator. Available at http://htmlhelp.com/tools/validator/ (accessed December 1,2007).

Wikipedia. XMLHttpRequest Object. Available at http://en.wikipedia.org/wiki/XMLHttpRequest#_note-Dutta(accessedDecember1,2007).

www.ethereal.com. (n.d.). Ethereal, a network protocol analyzer. Available at http://www.ethereal.com/(accessed_December_1,2007).