Fault-injection attacks have been around as long as the Web itself. They allow malicious access into a network or computer system through a Web application. With the explosive growth of applications, and as more applications are migrated to the Web, injection attacks have become a growing concern. In this piece, we'll review what fault-injection attacks do, different varieties of such attacks and some development best practices to ensure your financial organization's systems aren't victimized.
Some fault injections are script-based, using languages like JavaScript and PHP. With new Web 2.0 technologies relying on scripting languages, injection attacks have become more frequent and more sophisticated. The range of Web 2.0 technologies includes XML, RSS and AJAX, all of which can hide malicious injection code.
Because injection attacks come wrapped with Web applications in the form of embedded malicious code, they aren't intrusive like traditional network attacks, and they fly unnoticed under the radar of traditional IDS and IPS systems. This adds a degree of complexity to the detection process.
Types of fault-injection attacks
There are two types of injection attacks according to the Open Web Application Security Project (OWASP), which educates developers on secure Web coding practices. Injection flaws and cross-site scripting (XSS) are among OWASP's top 10 vulnerabilities. Both involve insertion of malicious code into a Web application, usually through a Web browser.
The most common and most vicious attack of the two OWASP categories is XSS. This is usually done with JavaScript but can also be any other scripting language. XSS can enable malicious access into a computer system by stealing authentication credentials from a legitimate user of a Web application.
Of the other OWASP category, injection flaws, SQL injection is by far the most common. SQL injection involves inserting SQL commands into a Web browser form field to kick off malicious access to the database running the Web application. Unlike XSS, SQL injection tries to get at an application's underlying data, rather than trying to steal user IDs and passwords.
Fault-injection defense
There are two main defensive approaches against injection attacks. One is safe coding and project management practices, as advocated by OWASP, and the other is a more hardware-based strategy with application-level firewalls.
The first basic rule of coding to prevent injection attacks is to filter all input to the Web application. That includes anything submitted from a Web page through a form, a hidden field or even attached to a URL. The culprits are common non-alphanumeric characters, like "!", "#", "<" and ">", which can kick off back-end processes on Web or application servers and allow unauthorized access.
For SQL injection, the lonely apostrophe (') is actually part of a SQL statement. When inserted with the right characters into a form field on a Web page, if not filtered properly, it can initiate a SQL query to a back-end database and return data. If the database contains account information or sensitive customer data, it can be a gold mine for malicious attackers.
For XSS, the main culprit is the "<script>" tag, which brackets malicious JavaScript or other script code the attacker is trying to inject or insert into the website. Filtering out the brackets is a start for defeating these attacks.
The OWASP top 10 vulnerabilities guide has detailed explanations with code examples for the common major coding languages, like Java, .NET and PHP. It also offers coding best practices, such as input validation, use of stored procedures when possible, specific output encoding and white list validation, to name a few.
Security testing in the software development lifecycle
Secure coding practices should be built into the application development lifecycle. Technical specifications should detail input-validation procedures for integration into coding, and applications should undergo security testing at various benchmarks in the development lifecycle.
Two popular penetration-testing tools that check for both XSS and SQL injection are WebInspect from SPI Dynamics (recently purchased by Hewlett-Packard Co.), and AppScan from Watchfire (recently purchased but by IBM). Both scan Web applications for injection flaws and provide detailed reporting useful for developers tracking down bugs.
Another approach is static code analysis tools, like those offered by Fortify Software. The two approaches are different: one is a scanner, and the other is a code analyzer. The choice of tool should be based on the available development needs and resources.
For a hardware-based approach, Web application firewalls can filter out attempting malicious injection attacks. Unlike traditional firewalls that inspect packet headers and accept or deny traffic based on the type and origin of a packet, application-level firewalls inspect the contents of packets for patterns common to malicious code, including those of injection attacks. This is an emerging market though, so it should be approached with caution. As with other network-based appliances and firewalls, they should be tested thoroughly before installation. Some well-known products come from vendors like NetContinuum Inc., Mi5 Inc. and Aladdin Knowledge Systems Inc.
Keep in mind that not all fault-injection protection products are created equal. Some are geared more toward protection from IM and email threats, and don't provide protection against injection attacks. Others scan URLs for blocking access to inappropriate sites. But this is an exciting and growing market, and as injection attacks become more sophisticated, expect defenses to follow suit.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security available from Amazon. He also has a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
