Application security: Testing for injection vulnerabilities

A top security vulnerability in Web applications is an injection attack -- one in which the Web application is tricked into treating input as if it were code, allowing a hacker to gain control of an application. In this tip, security expert John Overbaugh teaches security testers some key techniques on how to effectively test for injection vulnerabilities.

One of the most challenging responsibilities of a tester is ensuring the security of a Web application. In this tip, I’ll cover a few steps testers can take to be more effective in testing for OWASP’s top security vulnerability: injection.

According to the OWASP project:

Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.

The goal of an injection attack is to trick a Web application into treating input as if it were code, and thereby taking control of an application. The most common injection attacks include SQL injection, XPATH, and HTML injection. Injection attacks are often the basis for other attacks such as cross-site scripting attacks (attacks which inject Javascript code).

It is extremely difficult to test security into a project -- if not impossible. The key to fixing injection vulnerabilities is to not introduce them in the first place and/or to detect them in the build phase. Using static code analysis or similar automated tools will uncover a ton of these flaws. Still, no tool can replace a careful, experienced, methodical tester working her way through a Web application.

The first step in identifying injection flaws is to understand where user input is captured and used by the application. With injection attacks, it really doesn’t matter if the input is stored in a database or other file, or if it’s reflected back on the next page. The issue is to root out where unsanitized input is leveraged by the application. So it’s critical to understand the input and output of your application -- where is data brought into the application and where is it later output. This means that as a tester you will need to have a far better understanding of technical implementation of an application than if you were simply testing for conformance to requirements. By understanding the data flow, you can begin to probe how the application leverages data.

Another step in testing your application is to understand what technologies are leveraged. For example, does your application run in an LDAP environment? Will LDAP injection testing be important? Is a SQL backend involved? Is your application architected such that XPATH or XQUERY are potential attack vectors? By understanding your application, you can develop an accurate sense of the scope of the project and what technologies and attacks you need to probe.

Your patience will be challenged by the next task -- documenting and executing tests. Probing for SQL injection vulnerabilities in an application is fun and exciting the first few times – and in an unhealthy sense, discovering a valid defect is definitely rewarding. But these boundaries need to be probed control after control, page after page, POST parameter after POST parameter. It can become tedious. The good news is that this level of a “test everything” approach is generally a one-time process within legacy code. Once tested, always tested may not be an appropriate maxim, but it’s safe to say that a page which passed these tests last year and has not changed since is unlikely to have a new defect on it. There are a few commercial and open-source tools available to aid in your testing, but until a tester really knows an app, relying on an automated tool to probe every corner is insufficient.

A few additional notes to consider in your injection testing:

  • Many applications are developed with client-side input validation. This is a good thing; it prevents the benevolent user from uploading bad data. Unfortunately, it sometimes prevents the inexperienced tester from fully testing an application. In order to get beyond client-side input validation, you will need to learn how to use a proxying tool. Using this tool, you will begin to learn what data is input into the application (there is much more “input” than just the controls on a web page). You’ll also be able to bypass client-side validation, so you can run malicious input tests.
  • Even if a potential injection vulnerability is addressed, it doesn’t mean it has been fixed. A common response to an injection vulnerability is to “blacklist” various inputs (blacklisting means to explicitly deny any request for which the input matches a value in a list). Many hackers get around client- and server-side validation by encapsulating the text used in an attack.

The keys to succeeding at injection testing are 1) to be methodical, 2) to understand the technology underlying your application and 3) to use tools appropriately.

Additional Reading:

 

This was first published in April 2011
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close