Ajax programming is one of the most exciting new technologies in recent history. Ajax (Asynchronous Javascript and XML) allows a Web page to refresh a small portion of its data from a Web server, rather than being forced to reload and redraw the entire page as in traditional Web programming. Since they can make frequent, small updates, Web applications written with Ajax programming can present user interfaces that are more like desktop applications, which are more natural and intuitive interfaces for most users, but which are also prime targets for malicious users and hackers performing SQL injection and similar attacks.

The flexibility and creativity that Ajax programming affords the developer also places a burden on him to ensure that his code is secure against these new threats. Also, since delivering a secure application is part of delivering a quality application, the burden is probably felt even greater by the Quality Assurance (QA) team. The QA team will now need to develop an entirely new set of functional, performance and security testing methods in order to thoroughly test the quality of applications using Ajax programming against SQL injection attacks and other security concerns.

It's in the Code

As an example, consider a hypothetical gourmet food e-commerce Web site. This site displays a map of the world to the user, and as the user navigates the mouse pointer over each country, the page uses Ajax programming to connect back to the Web server and retrieve a list of goods originating in that country. The following C# code snippet shows the Web method in which the database is queried:

[System.Web.Services.WebMethod]
public System.Collections.IEnumerable GetProducts(string country)
{
  // update the select command to use the country parameter
  this.SqlDataSource1.SelectCommand = "SELECT * FROM [Product] WHERE Country = '" + country + "'";
  // query the database and return the results
  return this.SqlDataSource1.Select(DataSourceSelectArguments.Empty);
}

Some readers may notice a glaring security hole in this code. The database query is being constructed on the fly with un-validated user input being sent directly to the database. This insecure programming technique creates a vulnerability to SQL injection attacks, which are potentially devastating to the Web application and its users. SQL injection vulnerabilities allow attackers to execute their own SQL queries and commands against the database, rather than those that the developers of the Web site intended. The entire database, including customer names, addresses, and credit card numbers, could be downloaded by such a command. The prices of the products could be modified. The entire database itself could be permanently deleted. Clearly, this is a very serious issue. If the developer fails to notice the problem, the next line of defense is the QA team.

The average developer will probably do a cursory test of the application before passing it to the QA department, without checking thoroughly for SQL injection vulnerabilities or other important problems. Instead, he will mouse over a few countries on the map, check that the displayed results match those in the database, and then pass the code off. The average QA engineer typically

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine