1. SQL INJECTION COUNTERMEASURES &
-SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. It is, perhaps, one of the most common application layer attack techniques used today.
&
COUNTERMEASURES

2. Outline Introduce SQL Injection SQL Injection Attack Types
Prevention of SQL Injection Attack (Countermeasures)

3. What is SQL injection?
A class of code-injection attacks, in which data provided by the user is included in an SQL query in such a way that part of the user’s input is treated as SQL code
-Code-injection attacks: LDAP injection for LDAP directory and XPath injection for XML documents, ASP, PHP, HTML injection

4. Example of SQL injection
-Đây là 1 dạng đơn giản của SQLIA, ngoài ra người ta còn có thể nhập data thông qua nhiều cách khác nhau.

5. How does it happen?
-The user fires up his Web browser and connects to / The Web server that resides in the logic tier loads the script from the file system and passes it through its scripting engine where it is parsed and executed. The script calls an exposed API from the application server that resides in the application tier. The application server opens a connection to the storage tier using a database connector and executes an SQL statement against the database. The database returns the data to the database connector and the application server then implements any application or business logic rules before returning the data to the Web server. The Web server then implements any final logic before presenting the data in HTML format to the user’s Web browser within the presentation tier. The user’s Web browser renders the HTML and presents the user with a graphical representation of the code. All of this happens in a matter of seconds and is transparent to the user.

6. How dangerous is it?
The most critical Web application security risk (OWASP)
-Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers
can help attackers find them

7. SQL injection Two important characteristics: Injection mechanism
Attack intent

8. Injection Mechanism Injection through user input
Injection through cookies
Injection through server variables
Second-order injection
First-order injection
-User input typically comes from form submissions that are sent to Web application via HTTP GET or POST requests.
-Cookies are stored on the client machine. If a Web application uses the cookie’s contents to build SQL queries, an attacker could easily submit an attack by embedding it in the cookie
-Server variables are the collection of variables that contain HTTP, network headers, & environmental variables. Web applications use these server variables in variety of ways, such as logging usage statistics & identifying browsing trends => attackers can forge these values

9. Injection Mechanism First-order injection Second-order injection
The application processes the input, causing the attacker’s injected SQL query to execute.
The application stores that input for future use (usually in the database), and responds to the request.
The attacker submits a second (different) request.
To handle the second request, the application retrieves the stored input and processes it, causing the attacker’s injected SQL query to execute.

10. Second-order injection
Example

11. Attack Intent Identifying injectable parameters
Performing database finger-printing
Determining database schema
Extracting data
Adding or modifying data

12. Attack Intent Performing denial of service Evading detection
Bypassing authentication
Executing remote commands
Performing privilege escalation
-Authentication: to prove that sth is genuine, real or true.
-Bypassing authentication: allow attacker to assume the rights & privileges associated with another application user
-Performing privilege escalation: take advantage of implementation errors or logical flaws in the database to escalate the privileges of the attacker

13. Example application SELECT accounts FROM users
WHERE login = ? AND pass = ? AND pin = ?

14. SQLIA Types Present the different kinds of SQLIAs known to date
Many of them are used together or sequentially, depending on the specific goals of the attacker

15. Tautologies
Inject code in one or more conditional statements so that they always evaluate to true
SELECT accounts
FROM users
WHERE login = ‘’ or 1=1 --’ AND pass = ‘’
AND pin =
-The most common usages are to bypass authentication pages & extract data

16. Illegal/Logically Incorrect Queries
Inject statements that cause a syntax, type conversion, or logical error into the database
SELECT accounts
FROM users
WHERE login = ‘’ AND pass = ‘’
AND pin = convert(int, (select name
from sysobjects where xtype = ‘u’))
-Attack intent: identifying injectable parameters, performing database finger-printing, extracting data
-The attack is considered a preliminary, information gathering step for other attacks
”Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ’CreditCards’ to a column of data type int.”

17. Union Query Inject a statement of the form:
UNION SELECT <rest of injected query>
SELECT accounts FROM users WHERE login = ‘’ UNION
SELECT cardNo from CreditCards where
acctNo = ‘ AND pass = ‘’ AND pin =
-Attack intent: bypassing authentication, extracting data
-The result of this attack is that the database returns a dataset that is the union of the results of the original query & results of the injected second query

18. Piggy-Backed Queries
Include new and distinct queries that “piggy-back” on the original query
SELECT accounts FROM users WHERE login = ‘doe’
AND pass = ‘’; drop table users --’ AND pin =
-The database receives multiple SQL queries
-Vulnerability to this type of attack is often dependent on having a database configuration that allows multiple statements to be contained in a single string

19. Stored Procedures
Try to execute stored procedures present in the database
-It is common misconception that using stored procedures to write Web applications renders them invulnerable to SQLIAs
-Additionally, buffer overflows

20. Stored Procedures SELECT accounts FROM users WHERE login = ‘doe’
-Stored procedures can be vulnerable to the same range of attacks as traditional application code
SELECT accounts FROM users WHERE login = ‘doe’
AND pass = ‘’; shutdown;--’ AND pin =

21. Inference
Inject commands into the site and then observe how the function/response of the website changes
Blind injection
Timing attacks

22. Blind SQL injection
The information must be inferred from the behavior of the page by asking the server true/false questions

23. Timing Attacks
Gain information by observing timing delays in the response of the database

24. Alternate Encoding Employ alternate methods of encoding attack strings
SELECT accounts FROM users
WHERE login = ‘doe’; exec(char(0x f776e)) --’
AND pass = ‘’ AND pin =
-Avoid detection by defensive coding practices & also many automated prevention techniques
-Attackers have employed alternate methods of encoding their attack strings. Common scanning & detection techniques do not try to evaluate all specially encoded strings, thus allowing these attacks to go undetected
-Different layers in an application have different ways of handling alternate encodings
-An effective code-based defense against alternate encodings is difficult to implement in practice

25. Prevention of SQLIAs
The root cause of SQL injection vulnerabilities is insufficient input validation
Solution:
Defensive coding practices
Detection & Prevention techniques
-Defensive coding practices: straightforward solution for eliminating these vulnerabilities
-Detection & prevention techniques: assist developer & compensate for the shortcomings in the application of defensive coding

26. Defensive coding practices
Input type checking
Encoding of inputs
Positive pattern matching
Identification of all input sources
-Encoding of inputs: use functions that encode a string in such a way that all meta-characters are specially encoded & interpreted by the database as normal characters, not SQL tokens
-Positive pattern matching: establish input validation routines that identify good input as opposed to bad input

27. Defensive coding practices
Prone to human error
Not as rigorously & completely applied as automated techniques
Weakened by the widespread promotion of so-called “pseudo-remedies”
-Developers were making an effort to detect & prevent SQLIAs, but failed to do so adequately and in every needed location
-We discuss two of the most commonly-proposed pseudo-remedies.
+The first of such remedies consists of checking user input for SQL keywords, such as “FROM,” “WHERE,” and “SELECT,” and SQL operators, such as the single quote or comment operator. The rationale behind this suggestion is that the presence of such keywords and operators may indicate an attempted SQLIA. This approach clearly results in a high rate of false positives because, in many applications, SQL keywords can be part of a normal text entry, and SQL operators can be used to express formulas or even names (e.g., O’Brian).
+The second commonly suggested pseudo-remedy is to use stored procedures or prepared statements to prevent SQLIAs. Unfortunately, stored procedures and prepared statements can also be vulnerable to SQLIAs unless developers rigorously apply defensive coding guidelines

28. Detection & Prevention techniques
Web Application SQL Injection Preventer (WASP)
AMNESIA
SQLrand ….

29. Web Application SQL Injection Preventer (WASP)
Basic idea: allow only developer-trusted strings to form sensitive parts of a query
Solution:
Positive tainting
Syntax-aware evaluation

30. Positive tainting
Identify & mark trusted data instead of untrusted data
Some features:
Use a white-list, rather than black-list
Incompleteness -> false positives
Straightforward & less error prone
WASP provides developers with a mechanism for specifying sources of external data that should be trusted
-Traditional dynamic tainting: mark certain untrusted data as tainted, track the flow of tainted data at runtime
-Help address problems caused by incompleteness in the identification of relevant data to be marked -> false positive
-After a false positive is reported, developers would add the omitted items to the list of trusted sources
-The identification of most trusted data relatively straightforward. It is difficult to guarantee that all potentially harmful data sources have been considered
-In most case, strings hard-coded in the application by developers represent the complete set of trusted data for a Web application

31. Syntax-aware evaluation
Cannot simply forbid the use of untrusted data in queries
Some features:
Consider the context in which trusted & untrusted data is used: permit untrusted data to be only in string and numeric literals
Performed right before the query is sent to the database
-Our approach must be able to use the taint markings to distinguish legitimate from malicious queries
-Not rely on any (potentially unsafe) assumptions about the effectiveness of sanitizing functions used by developers.
-It also allows for the use of untrusted input data in a SQL query as long as the use of such data does not cause an SQLIA
-To evaluate the query string, the technique first uses a SQL parser to break the string into a sequence of tokens that correspond to SQL keywords, operators, and literals. The technique then iterates through the tokens and checks whether tokens (that is, substrings) other than literals contain only trusted data

32. Implementation
-Java
-The MetaStrings library provides functionality for assigning trustmarkings to strings and
precisely propagating the markings at runtime.
-Module STRING INITIALIZER AND INSTRUMENTER instruments Web applications to enable the use of the MetaStrings library and adds calls to the STRING CHECKER module. -Module STRING CHECKER performs syntax-aware evaluation of query strings right before the strings are sent to the database

33. Empirical Evaluation Testing for false negatives
Testing for false positives
Overhead measurements

34. Testing for false negatives

35. Testing for false positives

36. Overhead measurements
-use LEGIT
-overhead was relatively low, low enough that it would be dominated by the cost of network & database access

37. AMNESIA Analysis and Monitoring for NEutralizing SQL-Injection Attacks
Basic insights:
Code contains enough information to accurately model all legitimate queries
A SQLIA will violate the predicted model
-model-based approach

38. AMNESIA
Solution: uses a combination of static analysis & runtime monitoring
4 main steps:
Identify hotspots
Build SQL-query models
Instrument application
Runtime monitoring
-It uses static analysis to analyze the Web-application code and automatically build a model of the legitimate queries that the application can generate.
-At runtime, the technique monitors all dynamically-generated queries and checks them for compliance with the statically-generated model.
-Hotspots points in the application code that issue SQL queries to the underlying database.

39. Identify hotspots

40. Build SQL query model
Use Java String Analysis to construct character-level automata
Parse automata to group characters into SQL tokens
-build the SQL-query model for each hotspot, we first compute all of the possible values for the hotspot's query string
-The JSA library produces a non-deterministic finite automaton (NDFA) that expresses, at the character level, all the possible values the considered string can assume.
-To produce the final SQL-query model, we perform an analysis of the NDFA and transform it into a model in which all of the transitions represent semantically meaningful tokens in the SQL language.

41. Instrument application
For each hotspot, we insert a call to the monitor before the call to the database
-The monitor is invoked with two parameter: the query string that is about to be submitted and a unique identifier for the hotspot. The monitor uses the identifier to
retrieve the SQL-query model for that hotspot.

42. Runtime monitoring Check queries against SQL query model Normal user
-At runtime, the application executes normally until it reaches a hotspot. At this point, the query string is sent to the runtime monitor. The monitor parses the query string
into a sequence of tokens according to the specific SQL dialect considered
Normal user

43. Runtime monitoring Check queries against SQL query model
Malicious user

44. Implementation
-Analysis module. This module implements Steps 1 and 2 of our technique. It inputs a Java Web application and outputs a list of hotspots and a SQL-query model for
each hotspot. For the implementation of this module, we leveraged the Java String Analysis library [3]. The analysis module is able to analyze Java Servlets and
JSP pages.
-Instrumentation module. This module implements Step 3 of our technique. It inputs a Java Web application and a list of hotspots and instruments each hotspot with a call to the runtime monitor. We implemented this module using InsECTJ, a generic instrumentation and monitoring framework for Java [19].
-Runtime-monitoring module. This module implements Step 4 of our technique. The module takes as input a query string and the ID of the hotspot that generated the query, retrieves the SQL-query model for that hotspot, and checks the query against the model.

45. SQLrand
Extends the application of Instruction-Set Randomization to the SQL: appending a random integer to SQL standard keywords
Example:
-An attacker that does not know the key to the randomization algorithm will inject code that is invalid for that randomized processor (and process), causing a runtime exception

46. SQLrand system architecture
-Our design consists of a proxy that sits between the client and database server. Note that the proxy may be on a separate machine, unlike the figure’s depiction
-The proxy’s primary obligation is to decipher the random SQL query and then forward the SQL command with the standard set of keywords to the database for computation.
-Another benefit of the proxy is the concealment of database errors which may unveil the random SQL keyword extension to the user. By stripping away the randomization tags in the proxy, we need not worry about the DBMS inadvertently exposing such information through error messages; the DBMS itself never sees the randomization tags

47. Implementation Two primary components: De-randomization element
Communication protocol between the client & database system

48. De-randomization element
Required a modified SQL parser that expected the suffix of integers applied to all keywords
Utilized two popular tools for writing compilers and parsers: flex & yacc
-Capturing the encoded tokens required regular expressions that matched each SQL keyword (case-insensitive) followed by zero or more digits. (Technically, it did not require a key; practically, it needs one.)
-If properly encoded, the lexical analyzer strips the token’s extension and returns it to the grammar for reassembly with the rest of the query. Otherwise, the token remains unaltered and is labeled as an identifier.
-By default, flex reads a source file, but our design required an array of characters as input. To override this behavior, the YY INPUTmacro was re-defined to retrieve tokens from a character string introduced by the proxy.
-During the parsing phase, any syntax error signals the improper construction of an SQL query using the pre-selected random key. Either the developer’s SQL template is incorrect or the user’s input includes unexpected data, whether good or bad. On encountering this, the parser returns NULL; otherwise, in the case of a successful parse, the de-randomized SQL string is returned.The parser was designed as a C library.

49. Communication protocol
As a “middle man”, the proxy had to conceal its identity by masquerading as the database to the client & vice versa
-Since the proxy will act as a client to the database, the C API library was suitable.
-Proxy  DBMS: 3 primary packets: the query, the error, and the disconnect packets.
+The query packet carries the actual request to the database.
+The quit message is necessary in cases where the client is abruptly disconnected from the proxy or sends an invalid query to the proxy. In either case the proxy gains the responsibility of discretely disconnecting from the database by issuing the quit command on behalf of the client.
+the error packet is only sent to the client when an improper query generates a syntax error, thus indicating a possible injection attack.
-Client changes the port number of the database to the port where the proxy is listening. After receiving a connection, the proxy in turn establishes a connection with the database and hands off all messages it receives from the client
CLIENT
PROXY
DBMS
Using API the DBMS provides
Simply change port number

50. Evaluation Evaluation with respect to attack types
-Two attack types, stored procedures and alternate encodings, caused problems for most techniques.
-With stored procedures, the code that generates the query is stored and executed on the database. Most of the techniques considered focused only on queries generated within the application. Expanding the techniques to also encompass the queries generated and executed on the database is not straightforward and would, in general, require substantial effort.
-Attacks based on alternate encoding are also difficult to handle. Only three techniques, AMNESIA, SQLCheck, and SQLGuard explicitly address these types of attacks. The reason why these techniques are successful against such attacks is that they use the database lexer or parser to interpret a query string in the same way that the database would.

51. The end.