Web Application Security Testing

by Wyatt Ferreira

As the world continues to evolve into a more digital lifestyle, many consumers are heavily relying on the use of Web applications. A web application is any application that uses a web browser as a client. On any given day, an average person could use anything from Google’s Calendar application to custom Web applications for ordering items online. The use of Web Apps is entering a period nearing ubiquity. Microsoft has already begun offering its heavily used suite of Office applications as Web apps. With this rise in Web applications, many companies have also seen the effects of poor security as a risk to both users and developers. It is vital that companies developing Web applications conduct sufficient testing on their Web apps in order to minimize risk and maximize profits and safety. IT security firm McAfee determined a global estimate of around $1 trillion for the year 2010 and experts have asserted that cybercrime is on the rise.

The last few years have seen a rise in the number of Web application vulnerabilities.

Among the most popular are Cross-Site Scripting (XSS), SQL Injection (SQLi) attacks and Cross-Site Request Forgery (CSRF) vulnerabilities. Attackers are targeting both consumers and businesses with valuable information. According to the National Vulnerability Database and security research company nCircle VERT (Vulnerability and Exposure Reasearch Team), Web application vulnerabilities have increase from 1.9% of all published vulnerabilities in 2006 to over 52% in 2009 and, like most other areas of cybercrime, is on the rise.

General Web application testing should test the Functionality, Usability, Interface, Compatibility, Performance, and Security of the application. This write-up focuses primarily on the security aspect of Web application testing. While each aspect of testing provides its benefits, Security should be among the top concerns due to the possible consequences. It can easily be argued that a Web app that is slow and hard to use, yet secure and excellent at avoiding vulnerabilities is a much better application than one with a sleek user-interface and fast performance, but has glaring security holes. One of the most comprehensive guides to performing a sufficient security testing of a Web application is the Web app Security Checklist published by OWASP, The Open Web Application Security Project.

OWASP’s Web App Security Checklist includes 13 main areas:

  1. Information Gathering
  2. Configuration Management
  3. Secure Transmission
  4. Authentication
  5. Session Management
  6. Authorization
  7. Data Validation
  8. Denial of Service
  9. Business Logic
  10. Cryptography
  11. Risky Functionality - File Uploads
  12. Risky Functionality - Card Payment
  13. HTML 5

While there are more options and tools available, the OWASP Checklist provides a great list of topics that must be tested before a Web app is released. The following information is a summary of each area in the checklist, for a full, detailed account of each area, be sure to check out OWASP’s official website.

Beginning with the first item on the list, Information Gathering, a security researcher must first gather information about the Web app. This includes manually exploring the site, checking for files that expose content, and identifying everything from technologies used to all hostnames and ports.

Configuration Management concerns checking for commonly used application and administrative URLs and checking for old, backup, and unreferenced files. It also includes testing file extensions handling, security HTTP headers, and policies.

The next area is Secure Transmission. This includes checking SSL Version, Certificate validity, and HTTPS credentials if the app uses HTTPS.

The Authentication area tests for bruteforce protection, user enumeration, and the details regarding login credentials. This includes testing password reset/recovery features, autocomplete functions on password forms, password quality rules, etc.

Session Management identifies how session management is handled in the application (e.g. tokens in cookies, token in URL). It also checks how and when session termination occurs and confirms the proper use of tokens.

Authorization details tests for path traversal, bypassing authorization schema, Privilege Escalation (e.g. a user is allowed to access areas that they shouldn’t be able to at their privilege level), and missing authorization.

Data Validation tests some of the most commonly used methods for attacks. This includes testing for Cross-site scripting and SQL injection. This area of the checklist also requires testing for overflow, format string, and redirection. It is vital that this area of the checklist be scrutinized carefully because this concerns the majority of vulnerabilities in Web apps.

The next area is Denial of Service. This area tests for anti-automation, account lockout, and HTTP protocol Denial of Service.

Business Logic tests for the misuse of features, integrity of data, and segregation of duties.

Cryptography checks if data that should be encrypted is not as well as checking for weak algorithms and the proper use of salting.

The next two areas are considered “Risky Functionality” and include file uploads and card payments. Not every Web app includes these features, but if they do, one should test that file size limits, upload frequency, and total file counts are defined and enforced. The Web app should also test that uploaded files are not directly accessible within the web root. Testing for card payments includes testing for known vulnerabilities and configuration issues on the Web Server and Web app. It should also test for Authentication and Authorization issues and Cross-site request forgery.

The last item on the checklist regards HTML 5. Many newer Web apps are built using HTML 5. These tests include testing Web messaging, Web storage SQL injection, and the functionality of the Web app offline.

nCircle provided an example of real-world Web application vulnerabilities including Cross-site Request Forgery (CSRF) and SQL Injection (SQLi). CSRF allows an attacker to force you to perform tasks on authenticated websites that they have gained access to without your knowledge. A common, “minor” CSRF that is well-known is the Gmail logout issue in which an attacker can log anyone out of their Gmail session by having them visit a website.

Another example regarding online bank transfers works by: one (1) determining the criteria required to formulate a proper request to send money from your bank account, two (2) using input injection vulnerabilities to modify pages to contain an image (or similar website element) but it really points to the Attacker’s formulated request, and three (3) when the now infected page is visited, and the victim has their online banking open, they unknowingly send a request that transfers money to the Attacker.

The way to implement secure Web applications is primarily in the design phase. Developers must put an emphasis on incorporating common best-practices for each of the items on the checklist. Some common mistakes to avoid include unchecking input on screens and caching of sensitive information. Even simple things like forgetting to change default passwords on the database backend or not loading security patches are often missed by developers and can cause gaping security gaps. Users should always stay up-to-date with their browser and plug-ins. It is also important to stay alert and cautious of one’s browsing behavior. Users shouldn’t leave sensitive Web apps running in the background or in separate tabs unless it is necessary.

In an age when many users are monitoring credit reports, bank statements, and processing payments primarily through the internet, it is important for Web app developers to continually test the strength and integrity of their apps. The cost of poorly designed Web apps affects both the user and companies that create them.