OWASP Top Ten 2017 - A1:2017-Injection

Overview

This is the documentation of OWASP Top Ten 2017, specifically focusing on A1:2017-Injection. Injection vulnerabilities are a type of security weakness that occur when an attacker can send hostile data to an interpreter. They are prevalent in legacy code and can be found in various types of queries and commands, such as SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. Injection can result in data loss, corruption, disclosure to unauthorized parties, loss of accountability, or denial of access. This documentation provides information on how to prevent injection vulnerabilities and includes example attack scenarios.

Description

Injection vulnerabilities are a common security weakness in applications where an attacker can send malicious data to an interpreter. This can lead to data loss, corruption, unauthorized access, or denial of service. The OWASP Top Ten 2017 - A1:2017-Injection documentation provides an overview of injection vulnerabilities, their impacts, and how to prevent them. It also includes example attack scenarios to help readers understand the potential risks associated with injection attacks.

How to Prevent ?

Preventing injection vulnerabilities involves keeping data separate from commands and queries. This can be achieved by using safe APIs that avoid the use of interpreters or provide parameterized interfaces. Positive or 'whitelist' server-side input validation can also be used, along with escaping special characters in dynamic queries. Limiting and controlling SQL queries can prevent mass disclosure of records in case of SQL injection. Regular code review and thorough automated testing are essential to identify and fix injection vulnerabilities.

Example Attack Scenarios:

• Scenario #1: SQL Injection:  In this scenario, an application uses untrusted data in constructing a vulnerable SQL query. The attacker modifies the parameter value in their browser to inject SQL code, such as ' or '1'='1', resulting in the query returning all records from the accounts table.

• Scenario #2: Hibernate Injection:  Similarly, this scenario involves an application blindly trusting a framework and constructing a vulnerable Hibernate Query Language (HQL) query. The attacker modifies the parameter value to inject malicious code, potentially leading to data modification or deletion.