Home General Security 2017 OWASP A1 Update: Injection

2017 OWASP A1 Update: Injection

76
0
SHARE

Injection is a type of security flaw that has topped the OWASP Top Ten since around 2010. This means it is not a new vulnerability, and despite information on how to prevent it, it continues to be a problem. Any application that allows user input is potentially vulnerable to injection. There are ways to prevent injection, but deterring injection flaws depends highly on the needs of the application.

What Is an Injection Vulnerability?

An injection happens when a bad actor sends some type of malicious data through an application. That malicious data can be relayed through the application into an external system. This relay could happen via system calls, shell commands or calls to a backend database (normally by using SQL). Injection is partly made possible when applications allow users to input data without some type of input validation, sanitation or filtering. Poorly designed applications can allow entire scripts to be injected via user input.

Any application that uses an interpreter is at risk for injection. When dynamic queries with no context-aware escaping are allowed to directly communicate with an interpreter, this also creates an injection vulnerability. Legacy code is highly susceptible to injection as well. Legacy code is often left unsecured (potentially due to outdated patches or lapse in vendor support), minimally scanned, or located on systems with out-of-date operating systems and minimal security implementations.

The most common injection types are:

  • Expression Language (EL)
  • Object Graph Navigation Library (OGNL)
  • LDAP
  • Object Relational Mapping (ORM)
  • OS command
  • NoSQL
  • SQL

SQL is possibly the most common and widespread injection type. Instead of a Python, Pearl, or other script type, malicious SQL commands are embedded into the content of the user input. These commands convince a database to divulge all types of information because it explicitly trusts the query that was generated from the web application.

How Can I Detect Injection Vulnerabilities?

Now we’ve identified how injection works, it is easier to understand how to detect the potential flaw. The best way to detect injection flaws is by performing a source code review or using a static code analyzer to scan code automatically or by using a dynamic application test tool (DAST). Fuzzing is another way to detect injection vulnerabilities. Fuzzing, much like using scanning tools, detects bugs in programs.

How Can I Prevent Injection Vulnerabilities?

Performing source code reviews, using static coder analyzers or DASTs are not only the best ways to detect injection flaw vulnerabilities, but also the best ways to prevent them making their way into the production environment. If the vulnerability is detected while in the test environment, proper mediation and secure coding practices can then be implemented and retested to ensure a better configuration.

If data is separated from commands and queries, injection can be prevented. This is the most surefire way to avoid a potential injection vulnerability.

Whitelisting is another option to prevent injection. Creating a whitelist of the server-side input validation could slow down the potential of an injection attack. However, many mobile application APIs or text areas still require special characters, so in some cases this could be difficult to implement without some level of application degradation or loss of functionality.

To avoid SQL injection, use controls like LIMIT in order to prevent mass disclosure.

What Do Injection Attacks Look Like?

Here are a few examples of injection attacks from OWASP.

Scenario 1

The first example illustrates an SQL injection attack. An application that allows the use of untrusted data in the construction of a vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario 2

Most applications have a potentially debilitating level of blind trust in frameworks. This may result in vulnerable queries. This example is of Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

These examples illustrate an attacker modifying the “id” parameter value to send:

 ‘ or ‘1’=’1.

These examples create queries that will return all available records from the accounts table. This information, is of course, very dangerous in the hands of cyber criminals.

Conclusion

Injection flaws still remain high on the list of OWASP vulnerabilities year after year. It is important for organizations to limit, validate and sanitize user input data to reduce dependencies on outdated legacy code, and to scan or fuzz development code to detect injection vulnerabilities. The best step in injection prevention is staying educated in the latest security trends and mitigations.

LEAVE A REPLY

Please enter your comment!
Please enter your name here