CAPEC 66

Summary

Attack Execution Flow

1. Survey application:

   The attacker first takes an inventory of the functionality exposed by the application.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Spider web sites for all available links	env-Web
   2	Sniff network communications with application using a utility such as WireShark.	env-ClientServer env-Peer2Peer env-CommProtocol

   Outcomes

   ID	type	Outcome Description
   1	Success	At least one data input to application identified.
   2	Failure	No inputs to application identified. Note that just because no inputs are identified does not mean that the application will not accept any.

1. Determine user-controllable input susceptible to injection:

   Determine the user-controllable input susceptible to injection. For each user-controllable input that the attacker suspects is vulnerable to SQL injection, attempt to inject characters that have special meaning in SQL (such as a single quote character, a double quote character, two hyphens, a paranthesis, etc.). The goal is to create a SQL query with an invalid syntax.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Use web browser to inject input through text fields or through HTTP GET parameters.	env-Web
   2	Use a web application debugging tool such as Tamper Data, TamperIE, WebScarab,etc. to modify HTTP POST parameters, hidden fields, non-freeform fields, etc.	env-Web
   3	Use network-level packet injection tools such as netcat to inject input	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   4	Use modified client (modified by reverse engineering) to inject input.	env-ClientServer env-Peer2Peer env-CommProtocol

   Indicators

   ID	type	Indicator Description	Environments
   1	Negative	Attacker receives normal response from server.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   2	Positive	Attacker receives an error message from server indicating that there was a problem with the SQL query.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   3	Negative	Server sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)	env-Web env-ClientServer env-Peer2Peer env-CommProtocol

   Outcomes

   ID	type	Outcome Description
   1	Success	At least one user-controllable input susceptible to injection found.
   2	Failure	No user-controllable input susceptible to injection found.

   Security Controls

   ID	type	Security Control Description
   1	Detective	Search for and alert on unexpected SQL keywords in application logs (e.g. SELECT, DROP, etc.).
   2	Preventative	Input validation of user-controlled data before including it in a SQL query
   3	Preventative	Use parameterized queries (e.g. PreparedStatement in Java, and Command.Parameters.Add() to set query parameters in .NET)

2. Experiment and try to exploit SQL Injection vulnerability:

   After determining that a given input is vulnerable to SQL Injection, hypothesize what the underlying query looks like. Iteratively try to add logic to the query to extract information from the database, or to modify or delete information in the database.

   Attack Step Techniques

   ID	Attack Step Technique Description	Environments
   1	Use public resources such as "SQL Injection Cheat Sheet" at http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/, and try different approaches for adding logic to SQL queries.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   2	Add logic to query, and use detailed error messages from the server to debug the query. For example, if adding a single quote to a query causes an error message, try : "' OR 1=1; --", or something else that would syntactically complete a hypothesized query. Iteratively refine the query.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   3	Use "Blind SQL Injection" techniques to extract information about the database schema.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   4	If a denial of service attack is the goal, try stacking queries. This does not work on all platforms (most notably, it does not work on Oracle or MySQL). Examples of inputs to try include: "'; DROP TABLE SYSOBJECTS; --" and "'); DROP TABLE SYSOBJECTS; --". These particular queries will likely not work because the SYSOBJECTS table is generally protected.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol

   Indicators

   ID	type	Indicator Description	Environments
   1	Positive	Success outcome in previous step.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol
   2	Negative	Failure outcome in previous step.	env-Web env-ClientServer env-Peer2Peer env-CommProtocol

   Outcomes

   ID	type	Outcome Description
   1	Success	Attacker achieves goal of unauthorized system access, denial of service, etc.
   2	Failure	Attacker unable to exploit SQL Injection vulnerability.

Likelihood: Very High

Description

Related Vulnerabilities

Skill or Knowledge Level: 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.

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:

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.

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.

CWE - SQL Injection

CWE - Input Validation

CWE - Improper Error Handling