The number one security vulnerability on the Open Web Application Security Project (OWASP) top 10 list for 2013 continues to be injection. This generalized term refers to the capability of a system to be manipulated, via input, such that the output of the system has been subverted to display unintended information (information leakage) or command the system into performing a malice-based task.
OWASP outlines injection as follows:
While there are many forms of injection (LDAP, XPATH, Command Line, etc.) the most prevalent one is SQL injection. SQL injection typically takes the form of a manipulated URL that will execute SQL commands outside of the developer’s intent.
This security risk is of the highest level, as the prevalence is widespread and the impact to business can be catastrophic. Just how widespread is it? This is a matter of debate among security researchers with WhiteHat security claiming a 7 percent exposure rate among websites, and Veracode claiming a much higher rate at about one-third of sites. The reality is that as worldwide application development needs increase and without the promulgation of application security as a first class component of development, we will continue to see injection flaws.
Public Example & Detection
To find a company that has been a victim of injection, you typically don’t have to look far. One example is Sony, who in 2011 had their Pictures and Music website hacked via a SQL injection flaw. For the amusement of a group called LulzSec, who hacks for the fun of it, they hacked the Sony database and then publicly distributed the usernames, email addresses, passwords, and home addresses of end users. To add to the hit, Sony took an immediate financial blow with the leakage of music download codes and coupons.
To find out just how common and easy injection can be, let’s use my favorite hacking tool, Google Search. Using Google, we can search for sites based on PHP that take in an integer parameter via the URL. I chose PHP as it seems to be the most common with unvalidated input and a consistent URL parameter notation. A search we can use would look like:
With over half a million records returned for this search, we know there could be potential flaws on these sites as they meet the structure of an easily exploitable site and may be attacked if they are not explicitly preventing injection.
Within a given site, one way to test for actual SQL injection is to begin to alter the parameter for, in this case, “row.” Adding some simple SQL to the integer input such as the following would change the query that is run on the server to something that was unexpected and could force unintended output:
.php?row=1’ OR ‘1’=’1
If this particular change seems to affect the server, you might take it a step further and use a more descript SQL statement. One possible outcome of this may be like the following:
Red flags should be flying at this point, as not only has the system executed the SQL that was injected, but it displayed the full query along with table structures. For a hacker seeking their lulz, it would only be a short window before they were able to take ownership of the content of the site or view any and all information within the database.
There are also tools developed specifically for the purpose of finding external SQL injection flaws on websites, such as SQLMap, which will scan your site for flaws. From a code perspective, tools exist to scan the source as well such as SQL plugins for Sonar.
It is critical that you consider your entire application within scope, as the smallest hole could allow for a complete exposure of your systems and data. It is common to think that internal systems would not need to be as secure, and to let it slide a little since it is firewalled, but these systems are just the next link in a chain of events leading to an exposure if the access to internal systems are compromised.
Prevention
Securing systems and preventing injection is not a difficult task and may even be required under compliance regulations. As an example, PCI (payment card industry) has data compliance standards, which in DSS 3.0, require prevention. If you accept Visa or MasterCard online, you likely fall under this measure.
The strategy for prevention can be multi-tiered, and I would always recommend starting at the application level and working your way up.
At the application level, all commands and SQL statements should be executed in a manner such that the statement is “prepared.” What this means is that the given input has a strict and predictable execution strategy with the input of a required format that alleviates injection concerns. Many database access frameworks such as Hibernate have this built in and simplify database access, which leaves little reason not to use them.
Input validation is additionally a must at the application tier. For any parameter taken in on the website, it is best practice to validate that input against a set of expectations. In our previous example, the site was expecting an integer value, yet we were able to send it a long string of characters. If the site had used input validation, this exploit could not have occurred. For more complex inputs, OWASP provides a set of whitelists, which can aide in input validation.
Output validation should be seriously considered. In our previous example, one additional thing we noted was that the website displayed the SQL query that it had run and failed. While this may be an aide to developers programming the website, it should be a simple setting that is disabled when in production. Validating your output may not prevent an attack, but may push an attacker toward an easier target.
Moving up the tier toward the network level, a web application firewall (WAF) may be utilized. These devices intercept traffic before hitting the application and can deny requests deemed unsafe against known patterns. While this offers a great level of protection, these devices must be kept up to date and are not always able to identify an attacker’s pattern. In our own controlled security environment, we have been able to bypass WAFs operated by large Internet providers such as Akamai.
Summary
Injection is again at the top of the list when it comes to security concerns. This is because even the smallest injection hole can lead to the compromise of an entire database system and publicly expose all data.
The detection of SQL injection is not any more complex than other flaws and its prevention should take a layered approach. In terms of priority, injection should be a starting point, as you need to know your security holes before attackers find them.
Credera has a security team that is well versed in the detection and prevention of security holes and application vulnerabilities. If you would like to discuss any of the materials you have read or have a particular need for testing or secure application development, please email us at SecurityTeam@credera.com.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
