SQL Injection Attack

(1)

International Journal of All Research Education and Scientific Methods (IJARESM) ISSN: 2455-6211, Volume 5, Issue 3, March 2017, Impact Factor: 2.287

SQL Injection Attack

Monika Anand

1

, Pooja Nagpal

2

1,2

Asst. Professor, HIMT, Rohtak

ABSTRACT

SQL injection is a specialized form of input validation that attempts to manipulate the application’s database by issuing raw SQL statements. A SQLIA vulnerability is a type of security hole that is found in a multi-tiered application; it is where an attacker can trick a database server into running an arbitrary, unauthorized, unintended SQL query by piggybacking extra SQL elements on top of an existing, predefined query that was intended to be executed by the application. The application, which is generally, but not necessarily, a web application, accepts user input and embeds this input inside an SQL query. This query is sent to the application’s database server where it is executed. By providing certain malformed input, an attacker can manipulate the SQL query in such a way that its execution will have unintended consequences.

I SQL ATTACK MODEL

An SQL injection attack has a set of properties, such as assets under threat, vulnerabilities being exploited and attack techniques utilized by threat agents. model that represents properties associated with an attack and relationships between those properties.

The semantic representation of a SQL injection attack model is as following:

• Threat agents attempt to gain access to particular assets and impose particular threats by utilizing particular attacks techniques.

• The attack targets particular DBMS with particular intentions by exploiting particular vulnerabilities.

• The attack employs particular evasion techniques in order to evade detection.

• The owners of assets could deploy particular countermeasures to eliminate vulnerabilities.

(2)

II ATTACK INTENTION

When a threat agent utilizes a crafted malicious SQL input to launch an attack, the attack intention is the goal that the threat agent tries to achieve once the attack has been successfully executed.

• Identifying Injectable Parameters:

Injectable parameters are input data within a HTTP request which are directly used by server-side program logic to construct SQL statement without sufficient input validation. In order to launch an successful attack, a threat agent must first discover which parameters within a HTTP request of a specific URL are vulnerable to SQL injection attack.

• Identifying Database Finger-Print:

Database finger-print is the information that identifies a specific type and version of database system. Every database system employs a different proprietary SQL language dialect. For example, the SQL language employed by Microsoft SQL server is T-SQL. be succeeded, the attacker must first find out the type of and version of database deployed by a web application, and then craft malicious SQL input accordingly.

• Discovering Database Schema:

Database schema is the structure of a database system. The schema defines the tables, the fields in each table, and the relationships between fields and tables. Database schema is used by threat agents to compose a correct.

• Bypassing Authentication:

Authentication is a mechanism employed by web application to assert whether a user is who he/she claimed to be. Matching a user name and a password stored in the database is the most common authentication mechanism for web applications. Bypassing authentication enables an attacker to impersonate another application user to gain un-authorized access.

• Extracting Database Data:

Database data used by a web application could be sensitive and highly desirable to threat agents. Attacks with intention of extracting data are the most common type of SQL injection attacks.

• Modifying Database Data:

Database data modification provides a variety of gains for a threat agent. For instance, a hacker can pay much less for a online purchase by altering the price of a product in the database. Or, the threads in a online discussion forum can be modified by an attacker to launch subsequent Cross-Site-Scripting attacks.

• Downloading File:

Downloading files from a compromised database server enable an attacker to view file content stored on the server. If the target web application resides on the same host, sensitive data such as configuration information and source code will be disclosed too.

• Uploading File:

Uploading files to a compromised database server enable an attacker to store any malicious code onto the server. The malicious code could be a Trojan, a back door or a worm that can be used by an attacker to launch subsequence attack.

(3)

Remote commands are executable code resident on the compromised database server. Remote command execution allows an attacker to run arbitrary programs on the server. Attacks with this type of intention could cause entire internal networks being compromised.

• Escalating Privilege :

Privileges are described in a set of rights or permissions associated with users. Privilege escalation allows an attacker to gain un-authorized access to a particular asset by associating a higher privilege set of rights with a current user or impersonate a user who has higher privilege.

III ASSETS

Assets are information or data an unauthorized threat agent attempt to gain.

• Database Server Fingerprint:

The database server fingerprint contains information about the database system in use. It identifies the specific type and version of the database, as well as the corresponding SQL language dialect. A compromise of this asset may allow attackers to construct malicious code specifically for the SQL language dialect in question.

• Database Schema:

The database schema describes the server‟s internal architecture. Database structure information such as table names, size, and relationships are defined in the database schema. Keeping this asset private is essential in keeping the confidentiality and integrity of the database data. A compromise in the database schema may allow attackers to know the exact structure of the database, including table, row, and column headings.

• Database Data:

The database data is the most crucial asset in any database system. It contains the information in the tables described in the database schema, such as prices in an online store, personal information of clients, administrator passwords, etc. A compromise in the database data will usually result in failure of the system‟s intended functionality, thus, its confidentiality and integrity must be protected.

• Host:

A host is a discrete node in any network, usually uniquely defined with an IP address. It may have various privileges in a network and may be a database server or a regular computer terminal.

• Network:

A network interconnects numerous hosts together and allows communication between them. A compromise in a network will most likely compromise every host in the network. Some networks may also be interconnected with other networks, furthering the potential damage, should an attack be successful.

IV THREATS

Threats are potential violation of security. There are four types of threats: disclosure, deception, disruption and usurpation.

• Disclosure:

Unauthorized access to information.

(4)

Acceptance of false data. Examples of deception are modification of data, spoofing, repudiation of origin and denial of receipt.

• Disruption:

Interruption or prevention of correct operation. Examples of disruption are modification of data, and denial of service.

• Usurpation:

Unauthorized control of some or all parts of the system. Examples of usurpation are modification of data, spoofing, delay of service and denial of service.

V. VULNERABILITIES

• Insufficient Input Validation:

Input validation is an attempt to verify or filter any given input for malicious behavior. Insufficient input validation will allow code to be executed without proper verification of its intention. Attackers taking advantage of insufficient input validation can utilize malicious code to conduct attacks.

• Privileged Account:

A privileged account has a degree of freedom to do what normal accounts can not. Its actions may also be exempt from auditing and validation. This presents a vulnerability since a jeopardized privileged account, such as an administrator account, can compromise much more than what a jeopardized regular account can.

• Extra Functionality:

Extra functionalities meant to provide a broader range of usage may be a vulnerability since a combination of these functionality may result in unintended actions. For example, xp cmdshell is meant to provide users with a way of executing operating system commands, but is commonly used to added unauthorized users into the operating system.

VI. ATTACKS TECHNIQUES

Attack techniques are the specific means by which a threat agent carries out attacks using malicious code. Threat agents may use many different methods to achieve their goals, often combining several of these sequentially or employing them in different varieties.

• Tautology:

Attack Intent: Bypassing authentication, identifying inject able parameters, extracting data.

Description: This technique relies on injecting statements that are always true so that queries always return results upon evaluation of a WHERE conditional. A common example would to be inject a ”or 1=1” into the ”login” parameter. Login: ' OR ''='

Password: ' OR ''='

This will give SQL Query the following value:

SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''='' Instead of comparing the user-supplied data with that present in the Users table, the query compares '' (nothing) to '' (nothing), which, of course, will always return true.

• End of Line Comment:

(5)

Description: After injecting code into a particular field, legitimate code that follows are nullified through usage of end of line comments. An example would be to add ”- -” after inputs so that remaining queries are not treated as executable code, but comments. This is useful since threat agents may not always know the syntax or fields in the server. If a threat agent submitted a malicious URL

https://website/login.cgi?user_id=TAGENT‟;%20--

The parameter value would be more accurately submitted as “dcooper%27%3b%20--” but that obscures the important parts of the attack. The key to this malicious input is the double dash (--). Any subsequent SQL query that includes the double dash would ignore the password parameter because the double dash denotes a comment in SQL. In other words, any characters to the right of the double dash are ignored. The underlined portion represents the malicious input as it has been received by the application and passed as a query to the database:

SELECT name FROM userlist WHERE uid=‟dcooper‟; --‟ AND pwd=‟‟; Which will be treated as SELECT name FROM userlist WHERE uid=‟dcooper‟;

Due to the double dashes, the SQL query is equivalent to a statement that tests for only one column (theusername) instead of two (username and password):

The uid parameter‟s name is returned by the query, which causes the application to assume the user has supplied a correct password and marks the user as authenticated.

• Illegal/Logically Incorrect Query:

Attack Intent: Identifying injectable parameters, performing database finger-printing, extracting data.

Description: This technique is usually used by the threat agent during the information gathering stage of the attack. Through injecting illegal/logically incorrect requests, an attacker may gain knowledge that aids the attack, such as finding out the injectable parameters, data types of columns within the tables, names of tables, etc. The vulnerability leveraged by this attack is that the default error page returned by application servers is often overly descriptive. In fact, the simple fact that an error messages is generated can often reveal vulnerable/injectable parameters to an attacker. Additional error information, originally intended to help programmers debug their applications, further helps attackers gain information about the schema of the back-end database. When performing this attack, an attacker tries to inject statements that cause a syntax, type conversion, or logical error into the database. Syntax errors can be used to identify injectable parameters. Type errors can be used to deduce the data types of certain columns or to extract data. Logical errors often reveal the names of the tables and columns that caused the error. Example: This example attack‟s goal is to cause a type conversion error that can reveal relevant data. To do this, the attacker injects the following text into input field pin: “convert(int,(select top 1 name from sysobjects where xtype=‟u‟))”. The resulting query is:

SELECT accounts FROM users WHERE login=‟‟ AND pass=‟‟ AND pin= convert (int,(select top 1 name from sysobjects where xtype=‟u‟))

In the attack string, the injected select query attempts to extract the first user table (xtype=‟u‟) from the database‟s metadata table (assume the application is using Microsoft SQL Server, for which the metadata table is called sysobjects). The query then tries to convert this table name into an integer. Because this is not a legal type conversion, the database throws an error. For Microsoft SQL Server, the error would be: ”Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ‟CreditCards‟ to a column of data type int.”

There are two useful pieces of information in this message that aid an attacker. First, the attacker can see that the database is an SQL Server database, as the error message explicitly states this fact. Second, the error message reveals the value of the string that caused the type conversion to occur. In this case, this value is also the name of the first user-defined table in the database: “CreditCards.” Using this information about the schema of the database, an attacker can then create further attacks that target specific pieces of information.

(6)

Description: Threat agents use this technique to guide servers to return data that were not intended to be returned by the developers. A common example would be to add the statement ”UNION SELECT”, along with an additional target dataset so that queries return the union of the intended dataset with the target dataset. The UNION keyword enables threat agent to create queries that retrieve other fields from the same table or fields from a different table. This makes it possible to retrieve information that the application does not even normally supply, such as credit card numbers or merchant information. The basic SELECT statement is constructed to retrieve one or more rows from a single table. With UNION, threat agent can group multiple queries into a single result. The goal is to inject a query with this format:

SELECT value(s) FROM table WHERE clause_false UNION ALL SELECT value(s) FROM other_table WHERE clause_true

Often, threat agent will try to construct the query so that the first clause returns nothing and the second clause contains a truism such as „‟ = „‟ or 1=1. This lets threat agent to retrieve all rows from a particular table. Take a look at an example of SQL injection that tries to pull the user IDs and passwords from a table:

https://website/login.cgi?user_id=foo&password=‟+UNION+ALL+SELECT+uid,+pwd+FROM+userlist+W HERE+‟‟%3d‟

The parameter values in the HTTPS request result in a modified SQL query that lists everyone‟s user ID and password.

SELECT name FROM userlist WHERE uid=‟foo‟ AND pwd=‟‟ UNION ALL SELECT uid, pwd FROM userlist WHERE „‟=‟‟;

• Piggy Backed Queries:

Attack Intent: Extracting data, adding or modifying data, performing denial of service, executing remote commands.

Description: In this attack type, the threat agent tries to inject additional queries into the original query. We distinguish this type from others because, in this case, attackers are not trying to modify the original intended query; instead, they are trying to include new and distinct queries that “piggy-back” on the original query. As a result, the database receives multiple SQL queries. The first is the intended query which is executed as normal; the subsequent ones are the injected queries, which are executed in addition to the first. This type of attack can be extremely harmful. If successful, the threat agents can insert virtually any type of SQL command, including stored procedures, into the additional queries and have them executed along with the original query. 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.

If the attacker inputs “‟; drop table users - -” into the pass field, the application generates the query: SELECT accounts FROM users WHERE login=‟doe‟ AND pass=‟‟; drop table users -- ‟ AND pin=123

After completing the first query, the database would recognize the query delimiter (“;”) and execute the injected second query. The result of executing the second query would be to drop table users, which would likely destroy valuable information. Other types of queries could insert new users into the database or execute stored procedures. Many databases do not require a special character to separate distinct queries, so simply scanning for a query separator is not an effective way to prevent this type of attack.

• Stored Procedures:

Attack Intent: Performing privilege escalation, performing denial of service, executing remote commands.

(7)

are often written in special scripting languages, they can contain other types of vulnerabilities, such as buffer overflows, that allow attackers to run arbitrary code on the server or escalate their privileges .

CREATE PROCEDURE DBO.isAuthenticated @userName varchar2, @pass varchar2, @pin int AS

EXEC("SELECT accounts FROM users

WHERE login=‟" +@userName+ "‟ and pass=‟" +@password+ "‟ and pin=" +@pin);

GO

This example demonstrates how a parameterized stored procedure can be exploited via an SQLIA. In the example, we assume that the query string constructed at lines 5, 6 and 7 of our example has been replaced by a call to the stored procedure defined. The stored procedure returns a true/false value to indicate whether the user‟s credentials authenticated correctly. To launch an SQLIA, the attacker simply injects “ ‟ ; SHUTDOWN; --” into either the user Name or password fields. This injection causes the stored procedure to generate the following query:

SELECT accounts FROM users WHERE login=‟doe‟ AND pass=‟ ‟; SHUTDOWN; -- AND pin=

At this point, this attack works like a piggy-back attack. The first query is executed normally, and then the second, malicious query is executed, which results in a database shut down. This example shows that stored procedures can be vulnerable to the same range of attacks as traditional application code.

VII. EVASION TECHNIQUES

Evasion techniques are obscuring techniques employed in an attack to avoid detection by signature-based detection systems. In the context of SQL injection detection, a signature is the pattern of known attack strings. SQL injection attack occurs when input string alter the intended syntactical structure of SQL statement. Thus, an attack signature usually consist of one or more SQL keywords, deliminators and expressions. Signature-based detection systems build a database of attack signatures, and then examine input strings against the signature database at runtime in detection of attacks. Evasion techniques obscure input strings, making look different but yielding the same results when executed by a database server.

• Sophisticated Matches: One of the common signatures used by such mechanisms is some sort of variant on the famous OR 1=1 attack. Sophisticated matches evasion technique uses alternative expression of ”OR 1=1”. For example: OR ‟Unusual‟ = ‟Unusual‟ , OR ‟Simple‟ = ‟Sim‟+‟ple‟, OR 2 > 1 and OR ‟Simple‟ BETWEEN ‟R‟ AND ‟T‟ all have the same effect as ”OR 1=1”.

• Hex Encoding: Hex encoding evasion technique uses hexadecimal encoding to represent a string. For example, the string ‟SELECT‟ can be represented by the hexadecimal number 0x73656c656374, which most likely will not be detected by a signature protection mechanism.

• Char Encoding: Char encoding evasion technique uses build-in CHAR function to represent a character. For example, the string ‟SELECT‟ can be represented by the CHAR function as char(73)+char(65)+”LECT”, which make it very difficult for detection system to build a signature that match it.

• In-line Comment: In-line comment evasion technique obscures input strings by inserting in-line comments between SQL keywords. For instance, /**/UNION/**/SELECT/**/name can escape detection from signatures that expects white space between SQL keywords.

• Dropping White Space: Dropping white space evasion technique obscures input strings by dropping white space between SQL keyword and string or number literals. For example, OR‟Simple‟=‟Simple‟ works exactly the same way as OR ‟Simple‟ = ‟Simple‟, but has no spaces in it, make it capable of evading any spaces based signature.

(8)

VIII. PREVENTION OF SQLIAS

• Input type checking: SQLIAs can be performed by injecting commands into either a string or numeric parameter. Even a simple check of such inputs can prevent many attacks. For example, in the case of numeric inputs, the developer can simply reject any input that contains characters other than digits. Many developers omit this kind of check by accident because user input is almost always represented in the form of a string, regardless of its content or intended use.

• Encoding of inputs: Injection into a string parameter is often accomplished through the use of meta-characters that trick the SQL parser into interpreting user input as SQL tokens. While it is possible to prohibit any usage of these meta-characters, doing so would restrict a non-malicious user‟s ability to specify legal inputs that contain such characters. A better solution is to use functions that encode a string in such a way that all meta-characters are specially encoded and interpreted by the database as normal characters.

• Positive pattern matching: Developers should establish input validation routines that identify good input as opposed to bad input. This approach is generally called positive validation, as opposed to negative validation, which searches input for forbidden patterns or SQL tokens. Because developers might not be able to envision every type of attack that could be launched against their application, but should be able to specify all the forms of legal input, positive validation is a safer way to check inputs.

• Identification of all input sources: Developers must check all input to their application. As we outlined earlier, there are many possible sources of input to an application. If used to construct a query, these input sources can be a way for an attacker to introduce an SQLIA. Simply put, all input sources must be checked.

• Use strongly typed variables and database column definitions. Store and manipulate numbers (session IDs, zip codes, dates of birth) as integers or other appropriate numeric type. Strings (varchars) should only contain alpha numerics and reject punctuation and SQL formatting characters. This can prevent unexpected vectors, such as being able to enter “SELECT+*+…” into a field that is supposed to only accept a number.

• Assign query results to a strongly typed variable. For example, if the application is retrieving numeric values, such as zip codes, then assign the result to an integer. This prevents attackers from being able to pull arbitrary information. It would not be possible to retrieve and display a column name if the variable to be displayed in the browser only accepts integers. This technique severely restricts certain attacks. Consider this example that is susceptible to SQL injection, but uses strongly typed variables:

http://website/vote/analysis.asp?voteid=@@version Microsoft OLE DB Provider for SQL Server error '80040e57' Arithmetic overflow error converting nvarchar to data type numeric. /vote/analysis.asp, line 19 In this case, we were prevented from viewing the result of MS SQL‟s @@version because the application was expecting a different data type.

• Limit data lengths. All strings should be limited to a length that suits their purpose. A last name, for example, does not need to be stored or manipulated in a variable that uses 256 characters. This can effectively impede the success of a SQL injection attack by reducing the length of the malicious string. A corollary to this is that the data should be handled in a manner that limits buffer overflow attacks. While the programming language (ASP or java) may not have inherent potential for a buffer overflow, an underlying function may—such as operating system calls to modify files or a stored procedure within the database.

• Avoid creating queries via string concatenation. Create a function, view, or stored procedure that operates on variables passed from the application. String concatenation, where a query is formed raw from user-supplied data (“SELECT something FROM table WHERE” + variable…), is the most vulnerable to SQL injection attacks. A custom stored procedure or view, on the other hand, usually only leads to a database error if it receives invalid input. An error may still occur if a stored procedure receives invalid input, but it will not be possible for an attacker to manipulate the entire query.

(9)

CONCLUSION

Although defensive coding practices remain the best way to prevent SQL injection vulnerabilities, their application is problematic in practice. Defensive coding is prone to human error and is not as rigorously and completely applied as automated techniques. While most developers do make an effort to code safely, it is extremely difficult to apply defensive coding practices rigorously and correctly to all sources of input.

REFERENCES

[1]. http://en.wikipedia.org/wiki/SQL_injection

[2]. http://www.securiteam.com/securityreviews/5DP0N1P76E.html [3]. http://www.unixwiz.net/techtips/sql-injection.html

[4]. http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php [5]. http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ [6]. http://en.wikipedia.org/wiki/Nmap

[7]. http://nmap.org/book/man.html

[8]. http://en.wikipedia.org/wiki/Nikto_Web_Scanner [9]. http://cirt.net/nikto2

[10]. Web Security Portable Reference by Mike Shema [11]. Unofficial Guide to ethical Hacking by Ankit Fadia [12]. SQL injection whitepaper by SPI labs

[13]. Classification of SQL Injection Attacks by San-Tsai Sun, Ting Han Wei, Stephen Liu, Sheung Lau [14]. Analysis of SQL Injection Attack by Jayeeta Majumder & Gargi Saha