Based on Veracode’s bi-annual State of Software Security report [1], more than half of all applications submitted for security testing failed to meet acceptable levels of secure coding. And, more than 8 out of 10 web applications fail the OWASP Top 10 [2], an industry standard list of critical web application security errors. So what does this mean? Software security continues to be poor, despite the increasing threat space where application vulnerabilities are being used by attackers to penetrate into corporations to steal intellectual property and proprietary data.
Consider the common denominators across high-profile attacks just this year alone. In the beginning of 2011, SQL Injection was used in high-profile attacks such as those on the security company HBGary, the Night Dragon attacks on energy companies, and the certificate forging attack on Comodo. SQL Injection vulnerabilities in applications on organization perimeters were leveraged to get insider access to corporate secrets. Another major attack in early 2011 used a memory corruption flaw in a desktop application, Adobe Flash, to bridge the perimeter and install remote access software on an unwitting employee’s desktop as a way of penetrating further into RSA and stealing valuable corporate secrets.
These corporate breaches are examples of the two major threat space trends going on today:
- Attackers are discovering and exploiting common vulnerabilities on web applications to steal the data they manage or as stepping stones to penetrate deeper into organizations.
- Attackers are taking advantage of vulnerabilities found in common desktop software purchased by organizations in order to compromise employee workstations as pivot points to get deeper toward their goal.
These trends will continue until solutions are put in place to diminish the quantity of these software vulnerabilities or mitigate their exploitability. Traditional perimeter defense and detection software has been shown to be woefully inadequate against these major threat space trends. We don’t need more security software. We need more secure software.
The State of Software Security – And How to Improve It
This poor state of application security can be attributed to a few factors – security processes such as threat modeling or secure coding standards were not incorporated into the development lifecycle, or the security processes were incorporated, but failed to reduce flaws significantly. Another contributing factor is the lack of academic or professional training offered to development and QA professionals on secure coding practices.
In response, some organizations are stepping up to these enhanced attack trends and software security weaknesses by putting in place comprehensive application security programs. These programs seek to instill application security into the software development lifecycle as well as procurement processes that result in the acquisition of commercial or outsourced software.
This article takes a look at one aspect of an application security program – automated software security testing.First, let’s study how a security vulnerability can be used to an attacker’s advantage.
A Common Vulnerability Illustrated: How SQL Injection Works?
SQL Injection is one of the most commonly exploited vulnerabilities in web applications in particular. It was the culprit behind the recently publicized attacks against Sony’s PlayStation Network, for example. Yet, it remains a prevalent vulnerability in web applications being developed today.
Most web applications can really be considered containers to customer or proprietary data. They are designed to provide access to data by authorized users. This access is sought by way of SQL queries that the web application executes against the database. If attackers can influence the SQL that you use to communicate with your database, then they can gain access to data they should not have or escalate their privileges. Consider the following SQL statement, which depicts a typical query that a web application may carry out when a user is logging in to check their username and password:
select * from users where username = ‘cwysopal’ AND password=’r3ally53cur3!’
When this query is executed it does a search for the particular username and password in the user table and returns a record if a match is found. Note that the text in red, ‘cwysopal’ is the user name and ‘r3ally53cur3’is the passwordthat the user supplies by perhaps typing them into a web form. What happens if a user injects data that alters the SQL query in a meaningful way? They are able to do this when they are given free reign to supply any type of user data and relevant protections are not put into the application that restrict that freedom. So, without the relevant protections, a user could alter the SQL query to be the following:
select * from users where username = ‘admin’ AND password=’’ OR ‘a’ = ‘a’
They supply a username that could be used as the administrator username and supply characters that have special meaning in the SQL language for the password. As it happens the set of characters provided as the password always resolve to True. This has the net result of the user being able to log in as admin.
One traditional approach to preventing SQL Injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing SQL Injection attacks. For example, attackers can:
- Target fields that are not quoted
- Find ways to bypass the need for certain escaped meta-characters
- Use stored procedures to hide the injected meta-characters
Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL Injection attacks. Another solution commonly proposed for dealing with SQL Injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL Injection attacks, they fail to protect against many others.
Automated Security Testing
There are two automated security testing approaches that organizations can employ – static analysis and dynamic analysis. Both are discussed below.
Static Analysis
Static analysisrefers to the analysis of software that is performed without actually executing, or running, that software. Static analysis examines applications in a non-runtime environment. This method of testing has distinct advantages in that it can evaluate both web and non-web applications and can detect flaws in the software’s inputs and outputs that cannot be seen by observing the run-time behavior alone. Many tools that development and QA personnel already employ perform static analysis, in particular, compilers.Examples of static analysis used by compilers include analyses for correctness, such as type checking, and analyses for optimization, which identify valid performance-improving transformations. Static analysis can be performed by analyzing a program’s source code or machine code (oftentimes referred to as binary code or bytecode). Automated security testing technologies utilize static analysis for the purpose of discovering security vulnerabilities in software applications. Some security analysis tools operate on the source code while others operate on the binary code. Some examples of the classes of vulnerabilities discovered by static analysis include SQL Injection, Cross-Site Scripting and Buffer Overflows.
Figure 1 - Flow chart for binary static analysis
The advantage of static analysis is that it allows for complete code coverage because it is not dependent on discovering an execution path in order to test it as it is not operating against the application in run-time. Binary static analysis extends the code coverage to third-party components and libraries that are embedded in the final form of an application for which there is no source code available. In this manner it provides more thorough coverage than source code static analysis. However, static analysis cannot offer any insights into vulnerabilities in the underlying configuration or deployment environment of an application.
Dynamic Analysis
Dynamic analysis operates by executing a program and observing the executions. Testing and profiling are standard dynamic analyses. Dynamic analysis is precise because no approximation or abstraction need be done: the analysis can examine the actual, exact run-time behavior of the program. By virtue of operating against the running form of an application, dynamic analysis most closely mimics how a malicious user would attack the application. For the purpose of security testing,fully automated dynamic analysis is a technique that can be applied to web applications only. By directing a series of requests to the web application and evaluating the responses received, a determination can be made about the presence of commonly occurring vulnerabilities such as SQL Injection or Cross-Site scripting.
Dynamic analysis has the advantage of being able to expose vulnerabilities in the deployment environment. It also does not rely on the existence of source code. However, since it is difficult to discover all possible execution paths through an application it does not provide the complete coverage that static analysis does.
Summary
In summary, because of the threat space trends and new deployment platforms, including mobile,application security continues to be a dynamic arena. In the past, security testing was only contemplated for very high-risk systems such as online banking, but high-profile breaches in the news tell a different story. Attackers are going after any application that has data of seemingly little value to breach corporate networks and tarnish corporate brands. No matter what testing method, or combinations of methods you employ, organizations will need to be nimble and able to scale their programs to manage exponential new applications over many different platforms to keep pace with attackers in the coming years.
References
- Veracode http://www.veracode.com/reports/index.html
- Category:OWASP_Top_Ten_Project https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Find more videos like this on Software Testing Club – An Online Software Testing Community
Author Profile – Chris Wysopal
As co-founder, CTO and CISO of Veracode, Chris Wysopal is responsible for the security analysis capabilities of Veracode technology. He’s a recognized expert and well-known speaker in the information security field. Wysopal’s groundbreaking work while at the company @stake was instrumental in developing industry guidelines for responsibly disclosing software security vulnerabilities. He is a founder of Organization for Internet Safety (OIS), which established industry standards for the responsible disclosure of Internet security vulnerabilities. Wysopal is co-author of the award-winning password auditing and recovery application @stake LC (L0phtCrack), currently used by more than 6,000 government, military and corporate organizations worldwide. He is also the author of “The Art of Software Security Testing” published by Addison-Wesley.
No comments yet.