Are you at risk of an injection attack? These types of attacks are common, primarily because they affect ubiquitous SQL databases. If a user — internal or external — supplies information through a form, you may be at risk. Insufficient input validation may allow users to insert or inject their own parameters in your SQL call and gain access to some or all of your data.
Injection flaws occur primarily when an application uses untrusted data when constructing an SQL call or when an application relies on older, vulnerable frameworks. An attacker can simply modify the ‘id’ parameter in their browser to return all records. More savvy attackers can even, under the right circumstances, make changes to data.
In addition to impacting SQL databases, injection flaws can also be found in queries from LDAP, XPath or NoSQL as well as OS commands, SMTP headers, XML parsers and the like. Injection flaws are most common in legacy code, but they are tough to find and eradicate during testing. You need to examine the code manually to check for injection flaws.
Injection attacks can be devastating to your business, both from a technical aspect and from the business side. Once an injection attack takes place, you can no longer trust your data. It may be corrupted or denial of access may occur. In rare cases, injection attacks can take down your entire DBMS or issue commands to your operating system.
You lose the ability to guarantee confidentiality to your authorized users or customers, because sensitive information may have been made available to attackers. And if you’re holding authorization information in your SQL database, an attacker may be able to change this to limit access.
From a manager’s perspective, how does losing the data or having it stolen impact your day-to-day operations? Depending on the sensitivity of the data, such a worst-case breach could be devastating to your company’s ability to continue operations. It could also be terrible publicity for your company and cost you, customers, should the breach be made public.
Eliminating any opportunities for an attacker to take advantage of injection flaws should be a top consideration for your business because of the high impact a savvy attack could have on critical business data.
Injection flaws are common with applications written in PHP or ASP because these tend to have older functional interfaces. They are much less common with J2EE and ASP.NET applications, which don’t generally allow SQL injections. While you can’t assume that applications written in the latter will be fine, you should be more concerned about your legacy apps in PHP and ASP.
The first thing to do when investigating the vulnerability of your application to an injection attack is to make sure that any interpreter in use separates the query from any untrusted data. In SQL, you can simply avoid dynamic queries, or you can use bind variables in stored procedures and prepared statements so users are unable to insert text.
You can use a code analysis tool to find out if an interpreter is in place and to see the way data flows through the application. Some penetration testers can create scenarios such as would be used by an attacker, and this can tell you if you’re at risk. But in most cases, you’ll have to check the code for yourself — that’s the quickest and most accurate method for determining if the interpreter is present. Scanners can’t always tell whether an attack could be successfully carried out.
To keep an attacker from accessing your data, you need to ensure that untrusted data stays separated from commands and queries. That means that an attacker isn’t able to call records by modifying the ‘id’ parameter; the query will return nothing.
The easiest way to do this? Don’t use the interpreter at all. A safe API can avoid using the interpreter by creating a parameterized interface that only uses PreparedStatements instead of Statements. These stored procedures are compiled before the user adds any input, so it’s not possible to modify the SQL statement.
Even some stored procedures are vulnerable, so avoid dynamic queries and use parameterized queries. All your SQL statements should recognize user inputs as variables and validate them before passing data back to the user. In other words, statements should be precompiled before actual inputs are substituted for variables.
In some cases, there’s no API with a parameterized interface that is suitable for use. It is possible to escape special characters, but you must use specific escape syntax for whichever interpreter you are running. Check your code library for an escape routine that will work. This is the only way to make special characters safe if they need to be used in your application. While you can “white list” approved characters for use, that may not be a perfect solution if your users need to be able to input many different special characters.
You should also avoid disclosing any error information to the user. An uncaught SQL error may contain information like procedure names or table names and, in the hands of a knowledgeable attacker, can be used to access data.
Injection flaws are not uncommon and should be removed from legacy code. The good news is that most injection flaws are rather hard to exploit — they have to be set up in just the right way for a user to take advantage. However, if a vulnerability is exploited, it can be very damaging to your business. As part of an overall security review, it may be a good idea to re-examine your databases that allow user queries to ensure that queries or commands and unsecured data are completely separated.
For a more in-depth article regarding SQL Injection, have a look at https://www.kiuwan.com/blog/sql-injection-avoid/
