Cyber Security Institute

§ Current Worries

Top 3 Worries

  • Regulations
  • Old Firewall Configurations
  • Security Awareness

§ Listening

For the best information

  • The underground
  • Audible
  • Executive Excellence
  • Music (to keep me sane)

§ Watching

For early warnings

  • 150 Security Websites
  • AP Newsfeeds
  • Vendors

Thursday, September 28, 2006

Testing for Security in the Age of Ajax Programming

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. 
The flexibility and creativity that Ajax programming affords the developer also places a corresponding burden on him to ensure that his code is secure against these new threats.  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.

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.  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 average QA engineer typically will be much more thorough.  He might even set up an automated test script that will mouse over every single pixel on the screen, and he will check to see if there are any errors in the Ajax programming or underlying page code.  But, even this extreme level of thoroughness won’t be enough to find the SQL injection vulnerability.  By using a web browser (or automated script recorded from a web browser) as his test tool, the tester has limited his potential requests to only those which the browser can send, and the browser is itself limited by the source code of the web page.

In order to successfully defend against the hacker using SQL injection or some other attack, the QA engineer has to think like the hacker.  They use tools that operate at a much lower level, tools that are capable of sending raw HTTP requests to an address and displaying the raw HTTP response.  Like programming in standard hyperlink navigation or form submission, Ajax programming actions always have an HTTP request and response.  So, armed with his low-level HTTP requestor tool, the hacker is now free to make attacks on the application that could never be possible with a browser alone.

In order to successfully defend against the hacker using SQL injection or some other attack, the QA engineer has to think like the hacker.  An even better approach is to use an automated security analysis tool that performs these tests.

Posted on 09/28