Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

66

High

SQL queries used by the application to store, retrieve or modify data.

User-controllable input that is not properly validated by the application as part of SQL queries.

Very High

• Injection

Low - It is fairly simple for someone with basic SQL knowledge to perform SQL injection, in general. In certain instances, however, specific knowledge of the database employed may be required.

None

The attacker tries to inject characters that can cause a SQL error, such as single-quote (') or keywords such as "UNION" and "OR". If the injection of such characters into the input causes a SQL error and the resulting error is displayed unfiltered, the attacker can begin to determine the nature of input validation and structure of SQL queries. A typical error resulting from such injection would look like: "You have an error in your SQL Syntax. Check your manual for the right syntax to use near ') FROM db_users.user_table"

With available design documentation and code, the attacker can determine whether all user-controllable inputs are being validated or not, and also the structure of SQL queries that such inputs feed into.

Too many false or invalid queries to the database, especially those caused by malformed input.

Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear.

Use of parameterized queries or stored procedures - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails. Note that SQL Injection is possible even in the presence of stored procedures if the eventual query is constructed dynamically.

Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application.

• Data Modification
• Information Leakage
• Run Arbitrary Code
• Privilege Escalation

SQL Injection results from a combination of factors. The primary cause is lack of appropriate input validation. In the absence of such validation, it becomes possible to inject arbitrary content, such as code, into the input. The second most important reason is use of dynamic SQL queries. It is a misconception that use of stored procedures makes the application immune to SQL Injection. It is important that input be parameterized to provide an additional line of defense, should input validation fail. Another factor that lets attackers discern information about the structure of queries and the application is use of default error pages and improper error handling. Descriptive error pages must be used only for debugging purposes. The motive of an attacker is to inject spurious content into input that does not get properly validated and is used as part of SQL queries. When the resulting error page is displayed, the attacker can determine the structure of queries as well as internal system information, leading to SQL Injection being successful.
      
      An important distinction needs to be made concerning first-order and second-order SQL Injection. With first-order injection, the results of injection are observed immediately in the form of an error message or a successful query resulting in attaining the attacker's motive. However, there are instances when the results of a successful injection are observed when a different query is executed or a different user accesses the application. For example, an attacker may enter
      ';DELETE recipes;--
      as input to a favorite recipe question. When the application is subsequently requested to retrieve details of the attacker's favorite recipe, a query such as:
      "SELECT descr FROM recipes WHERE recipe='"+rs.getString("Favorite")+"'";
      results in the following being executed:
      "SELECT descr FROM recipes WHERE recipe='';DELETE recipes;--
      which is valid SQL syntax and results in deletion of an entire table.
      This method of SQL Injection that involves subsequent access to injected data is known as second-order SQL Injection.
    

User-controllable input used as part of non-parameterized SQL queries: This may include input fields on web forms, data in user-accessible files or even command-line parameters.

SQL statements intended to reveal information or run malicious code

Back-end database

When malicious SQL content is executed by the database, it can lead to arbitrary queries being executed, causing disclosure of information, unauthorized access, privilege escalation and possibly system compromise.

Special characters in user-controllable input must be escaped before use by the application.

Only use parameterized stored procedures to query the database.

Input data must be revalidated in the parameterized stored procedures.

Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.

• Reluctance to Trust
• Failing Securely
• Defense in Depth

• Never Use Input as Part of a Directive to any Internal Component
• Handle All Errors Safely

Penetration

Exploitation

CWE - SQL Injection

CWE - Input Validation

CWE - Improper Error Handling