Injection Attack

Injection attacks remain one of the most common application attack vectors. To help prevent these attacks, organizations can leverage runtime security to easily and effectively prevent exploitable vulnerabilities and safeguard applications in production.

What is an injection attack?

Injection vulnerabilities allow attackers to insert malicious inputs into an application or relay malicious code through an application to another system. During an injection attack, untrusted inputs or unauthorized code are “injected” into a program and interpreted as part of a query or command. The result: An attacker can alter the program, redirecting it so as to gain unauthorized command execution or unauthorized data access.

What are the injection attack types?

Injection attacks can include calls to the operating system via system calls, the use of external programs via shell commands or calls to backend databases using SQL. Whenever an application uses an interpreter, it risks introducing an injection vulnerability. Scripts written in Perl, Python and other languages can be injected into a poorly designed application and then executed, giving the attacker control over its behavior.

Key injection attack types to know:

• Code injection — Code injection is the term used to describe attacks that inject code into an application. That injected code is then interpreted by the application, changing the way a program executes. 
• CRLF injection — CRLF stands for carriage return line feeds. According to OWASP, “a CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.”
• Cross-site scripting — Verifies that no untrusted data is used in generated HTML pages. "Cross-site scripting (XSS)" originally referred to loading the attacked, third-party web application from an unrelated attack site, executing JavaScript in the security context of the targeted domain where cross-site data theft was the focus. These are also sometimes referred to as host header injection attacks.
• Email header injection — Also sometimes known as a mail header injection, email header injections function similarly to header injections but target emails and email-based forms to send spam or phishing emails.
• LDAP injection — Verifies that no untrusted data is used in dynamic LDAP queries.
• SQL injection — Verifies that no untrusted data is used in dynamic database queries. An SQL injection attack consists of an insertion or injection of a SQL query via the input data from the client to the application. 
• XPath injection — Verifies that no untrusted data is used in an XPath expression used to retrieve data from an XML database.
• Expression Language injection — Verifies that untrusted data is not used in the evaluation of JSP Expression Language. Expression Language Injection (aka EL Injection) enables an attacker to view server-side data and other configuration details and variables, including sensitive code and data (passwords, database queries, etc.).
• Hibernate injection — Verifies that no untrusted data is appended to dynamically constructed hibernate queries.
• JNDI injection — Verifies that no untrusted data is used in a Java Naming and Directory Interface (JNDI) lookup.
• Log injection — Verifies that no untrusted data is put into log files.
• NoSQL injection — Verifies that no untrusted data is used in dynamic database queries.
• NoSQL injection DynamoDB —mVerifies that no untrusted data is used in dynamic database queries.
• Command injection — With a command injection attack, the goal is to hijack a vulnerable application in order to execute arbitrary commands on the host operating system.
• OS command injection — Verifies that no untrusted data is used in commands sent to the operating system.
• Reflection injection — Verifies that untrusted data is not used in a reflection API.
• SMTP injection — Verifies that untrusted data is not used in sensitive parts of a SMTP message
• XML External Entity injection (XXE) — Verifies that external entities aren't processed during XML.
• OGNL injection — Object-Graph Navigation Language is an open-source Expression Language (EL) for Java objects. OGNL expression injection attacks enable evaluation of invalidated expressions against the value stack, allowing an attacker to modify system variables or execute arbitrary code.

What are the risks posed by injection attacks?

By identifying a critical vulnerability, attackers can insert malicious code in an application, gaining functionality and ultimately executing specific commands that infect the targeted user and system networks. As OWASP has noted, “[a]n attacker can use these techniques to obtain, corrupt, or destroy the contents of your database, compromise backend systems, or attack other users. Successful injection attacks may completely compromise or destroy a system. It is important to test for and protect against these types of attacks.”

How to avoid an injection attack

Frequently, organizations rely on web application firewalls (WAFs) and Application Security Testing (AST) tools such as Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) solutions to safeguard their applications against injection attacks and other potential issues.

A WAF is a network defense that filters, monitors and blocks HTTP traffic to and from a web application. Unlike a regular firewall that serves as a safety gate between servers, a WAF is able to watch application-level traffic and decide to allow or disallow based on the data that is visible over the network.

DAST tools generate thousands of requests and bombard your application with them to see if they can get anything through. DAST tools can find issues that show up in web pages but can't see anything internal to your application and don't exercise much of your code.

SAST tools, on the other hand, try to model the entire application by guessing how all the source code, libraries, frameworks, and components fit together and will operate when run. But they make a lot of mistakes and typically don't even attempt to model the whole application.

Since both of these approaches are difficult to set up and don't get very good results, Contrast Security is leading the way with the next generation of application security tools known as Interactive Application Security Testing (IAST).

Contrast takes the innovative approach of tagging and tracking untrusted data wherever it goes within the application. Contrast also tracks all the validation and escaping that happens to that data along the way.

A WAF can’t tell you the line of code that is being attacked, but Contrast Application Detection and Response (ADR) can. Unlike WAFs or external scanners, Contrast analyzes and protects applications from within by integrating security safeguards into the running application.