Structured Query Language Injection Attack (SQLIA) is the most exposed to attack on the Internet. From this attack, the attacker can take control of the database therefore be able to interpolate the data from the database server for the website. Hence, the big challenge became to secure such website against attack via the Internet. We have presented different types of attack methods and prevention techniques of SQLIA which were used to aid the design and implementation of our model. In the paper, work is separated into two parts. The first aims to put SQLIA into perspective by outlining some of the materials and researches that have already been completed. The section suggesting methods of mitigating SQLIA aims to clarify some misconceptions about SQLIA prevention and provides some useful tips to software developers and database administrators. The second details the creation of a filtering proxy server used to prevent a SQL injection attack and analyses the performance impact of the filtering process on web application.
With the development of World Wide Web the organizations are beginning to get more sophisticated about how they employ their website. Nowadays, the web has become very essential need of our society. But with the wide spread uses of Internet, some malicious users begin the work in negative direction which harms the website of the organizations and these users are referred as cyber criminal or website attacker. SQL Injection Attacks (SQLIA) are one of the top threats for web application security, and SQL injections are one of the most serious vulnerability types. SQLIA are easy to learn and exploitable, so this method of attack is easily used by attackers. Also many major and traditional security systems having different security layers like firewall, encryption, intrusion detection systems, Antivirus and anti malware are not able to detect this type of attack. SQLIA techniques have become more common, more ambitious, easy to learn/implement, and increasingly sophisticated, so there is a need to find an effective and feasible solution for this problem in the computer security community.
SQL is a textual relational database language. There are many varieties of SQL; however, the differences among the various dialects are minor. SQL functions fit into two categories:
• Data definition language (DDL): used to create tables and define access rights.
• Data manipulation language (DML): SQL commands that allow one to insert, update, delete, and retrieve data within database tables.
The typical unit of execution of SQL is the query, which is a collection of statements that typically return a single result. SQL injection is a way to attack a database through a firewall by taking advantage of non-validated SQL vulnerabilities. It is a method by which the parameters of a Web based application are modified in order to change the SQL statements that are passed to a backend database. An attacker is able to insert a series of SQL statements into a query by manipulating the data input, for example, by adding a single quote (') to the parameters. It is possible to cause a second query to be executed with the first [
Programmers often chain SQL commands together with user-provided parameters, and can therefore embed SQL commands inside these parameters. This is known as dynamic SQL. It must be noted that dynamic SQL must be used in the application or SQL injection is not possible. SQL injection has been described as a “code hole” that is as serious as any IIS hole [
An attack against a database using SQL Injection could be motivated by three primary objectives:
1) To steal data from a database from which the data should not normally be available.
2) To obtain system configuration data that would allow an attack profile to be built. One example of this would obtain all of the database password hashes so that passwords can be brute-forced.
To gain access to an organization’s host computers via the machine hosting the database can be done using package procedures and 3GL language extensions that allow O/S access [
SQLIA occurs when an attacker causes the web application to generate SQL queries that are functionally different from what the user interface programmer intended.
For example, consider an application dealing with author details.
A typical SQL statement looks like this:
Select id, first name, last name from authors;
This statement will retrieve the “id”, “forename” and “surname” columns from the “authors” table, returning all rows in the table. The “result set” could be restricted to a specific “author” using “where” clause.
Select id, first name, last name from authors where first name = “James” and last name = “Baker”;
An important point to note here is that the string literals “James” and “Baker” are delimited with single quotes. Here the literals are given by the user and so they could be modified. They become the vulnerable area in the application. Now, to drop the table called “authors”, a vulnerable literal can be injected into the statement as given below.
First name: “Jam”; drop table authors—last name:
Now the statement becomes:
Select id, first name, last name from authors where first name = “Jam”; drop table authors—and last name = “ ”;
This is executed since the first name ends with delimiter and — is given at the end of the input, all other command following the — is neglected. The output of this command is the deletion of the table named “authors”, which is not the intended result from a server database.
There are four main categories of SQLIA against databases:
1) SQL Manipulation: manipulation is process of modifying the SQL statements by using various operations such as UNION. Another way for implementing SQL Injection using SQL Manipulation method is by changing the where clause of the SQL statement to get different results.
2) Code Injection: Code injection is process of inserting new SQL statements or database commands into the vulnerable SQL statement. One of the code injection attacks is to append a SQL Server EXECUTE command to the vulnerable SQL statement. This type of attack is only possible when multiple SQL statements per database request are supported.
3) Function Call Injection: Function call injection is process of inserting various database function calls into a vulnerable SQL statement. These function calls could be making operating system calls or manipulate data in the database.
4) Buffer Overflows: Buffer overflow is caused by using function call injection. For most of the commercial and open source databases, patches are available. This type of attack is possible when the server is un-patched.
After the text edit has been completed, the paper is ready for the template. Duplicate the template file by using the Save as command, and use the naming convention prescribed by your journal for the name of your paper. In this newly created file, highlight all of the contents and import your prepared text file. You are now ready to style your paper.
According to Huang [
1) Validate all user input before transmitting it to the server;
2) Permit only minimally privileged accounts to send user input to the server;
3) Run SQL Server itself with the least necessary privileges;
The presentation by [
• Redirecting and reshaping a query
• Error message based
• Blind SQL injection
[
[
[
[
[
This paper is an extension of a two-part paper on investigating the possibilities for an Oracle database administrator to detect SQL injection. This paper provides many scripts on SQL injection and extracting logs.
SQL injection is not a new problem. The date of its discovery is uncertain. However, in the last few years, SQLIA have been on the rise [
Some have been outlined below:
• Secure Sphere
Uses advanced anomaly detection, event correlation, and a broad set of signature dictionaries to protect web applications and databases. It also uses error responses from the same user to identify an attack [
• Mod Security
Is an open source intrusion detection engine for web applications, which may provide helpful tips on how to detect SQL injection. [
• Airlock
Combines secure reverse proxy with intrusion prevention, content filtering, user authentication enforcement, and application-level load balancing and failover (Seclutions’ Airlock was awarded the Swiss Technology Award 2003) [
• VIPER tool for penetration testing
According to Angelo Ciampa, Corrado Aaron Visaggio and Massimiliano Di Penta, they have suggested a tool called Viper to perform penetration testing of Web applications. This tool relies on a knowledge base of heuristics that guides the generation of the SQL queries. This tool first identifies the hyperlink structure and its input from [
• SQLr and Practical Protection mechanism
S. W. Boyd and A. D. Keromytis has suggested the practical protection mechanism for preventing SQLIA against web server. This tool uses SQL randomized query CGI application and detect and correct the queries injected into the code [
• Green SQL
Is a free Open Source database firewall that sits between the web server and the database server and is used to protect databases from SQL injection attacks. The logic is based on evaluation of SQL commands using a risk scoring matrix as well as blocking known database administrative commands (e.g., DROP, CREATE, etc.). Reports are generated on timestamp, query pattern, reason blocked (e.g., true expression, has “or” token). It has a white list of approved SQL patterns. However, only MySQL database is currently supported. [
• Dot Defender
It is a web application firewall that offers a SQL-Injection solution. Dot Defender is a multi-platform solution running on Apache and IIS web servers. Central management ensures a single point of control and reporting for all servers. There is an application layer firewall in front of web applications. It has a set of security rules that enable it to be a powerful solution. However, the cost is prohibitive [
• Code Scan Labs’ SQL-Injection detection product
It has the capability to scan web application source code that you selected for code syntax vulnerabilities. It subsequently generates a “debug style” report. The speed depends on how large the web application is and its complexity. The Code Scan software does not fix the code, however; it only points out the issues. The company offers a 21-day free trial, but normally it requires a yearly subscription to be maintained. The actual price is not advertised and one must contact sales representative to find out the cost. A separate activation key is required for different programming languages and additional capabilities [
• Web framework support
Web frameworks [
• Static analysis
Static analysis proposed an approach that uses a static analysis can detect and prevent SQLIA in compile time. This technique only focus on tautologies but it cannot detect illegal, union, piggyback, stored procedures SQL injections attacks.
• Dynamic analysis
Dynamic analysis is different from Static analysis. However, Static Analysis to detect the queries in compiled time. So the attacker passes advanced queries to web application and it is easily attacked. But Dynamic analysis [
• Combined static analysis and dynamic analysis
The advantage of combined static analysis and dynamic analysis method is to detect SQLIA. It is more complex compared to other techniques. It can solve the problem which cannot be solved by other methods. AMNESIA [
The current databases return the results of a statement to the client. The request and results are done by a link from the client to the database back again. The project aims to eliminate the possibility of SQL injection by the use of a filtering proxy server, which will be placed in between the two communicating devices, namely the web application or client and the database. This added layer of protection will allow for the filtering of possible SQL injection attempts and provide the database with a last means of defense. The main step is illustrated in
The main project goals are to:
• Analyze the structure of SQL query commands.
• Build a parser that will check allowable patterns of SQL statements.
• Construct a list of common SQL injection commands.
• Create a proxy server that will alert the database administrator of possible SQL injection commands.
• Prevent a SQL injection attack to a database using this proxy server.
• Prove that SQL injection can be prevented using the filter developed to work on the proxy server.
The current paper aims to eliminate the possibility of SQL-Injection by the use of a proxy server, which will be placed in between the two communicating devices. This will allow for the filtering of possible SQL-Injection attempts.
The information flow diagram shows the flow of information between a TDS Proxy server within the domain of this project and the other entities and abstractions with which it communicates. The diagram helps to discover the scope of the system and identify the system boundaries. The system under investigation (TDS Proxy) is represented as a single process interacting with various data and resource flow entities via an interface. As can
The main implementation step
be seen from the diagram, the web application provides the query to TDS Proxy which in turn provides safe queries to the database and attack reports to the Database Administrator.
The design and implementation steps made use of the Rational Unified Process (RUP) with the aid of Unified Mark-up Language (UML). This iterative process started off with a simple application and developed into a more complex system in subsequent iterations. The reason for using this methodology was to overcome problem areas in segments. Once the basic concept was conceived and implemented, more advanced featured were added to flesh out the software used for this proof of concept project. The web application is where the queries are formed from the input parameters. These queries are sent to the database through TDS Proxy. The bulk of the system operations take place at the TDS Proxy. When the TDS Proxy has filtered the query, the clean query is sent to the database server.
The diagram in
The flowchart in
TDS Proxy loads a configuration file at start-up. This file contains, filter settings and options as well as the settings required for the passing of data to the correct destination. Once the system has started, it is able to start receiving data from the client. When data is received from the client, the payload is analyzed. If the payload contains a SQL query, the query is logged and then filtered. If the filter process finds that there is a potential attack, the attack is logged. After logging the attack, the attack information is sent via UDP to the DBA. A false query is sent to the database and the response returned to the client. If the filter process did not pick up an attack, the query is sent to the database and the database response is returned to the client. If the payload does not contain a query, the data is simply passed on to the database.
The function of the proxy server
High level design view
Flowchart of the TDS proxy server
The ideal solution is to build a filter that checks for all cases of SQL injection possible. The problem with this is that a list of all possible injection strings is not possible to define [
The filtering application should sit as close to the database as possible. Ideally it should sit on the same machine as the database; however, this may have a performance impact due to the filtering process of the filtering proxy server. If the filtering application and the database are on different machines, there is a security risk as the network traffic passes from one machine to the other. With the filtering application sitting on the same machine as the database, there are several advantages.
• There is an additional security as network traffic is limited.
• Processing time is reduced as network latency has no additional effect on the transaction round trip time.
• The filtering application provides a last means of defense for the database.
There are some advantages to using SQL signature filtering as a preventative measure to SQL injection. These are:
• Real time analysis does not impact the database [
• Any flaws in the configuration of database privileges or coding of the application would not affect the database security.
However, there are also several disadvantages.
• False positives may also be filtered out in the filtering process [
• Packet filtering does not show internal dynamic SQL execution [
• This method will not work if the data is encrypted because the strings cannot be viewed in plain text without decryption [
• Filtering all incoming http packets may turn out to be resource intensive. A large amount of traffic may need to be handled at the web server [
To be a useful intrusion detection system, the filter should be able to find the attackers. Finding the user or attacker means logging login information for inspection. The filter would need a timestamp as well as the source and destination IP address [
Most of the suggestions above apply to future deploying of web applications. The (open web application security project) OWASP guide with its many precautions is now becoming an accepted standard [
There are many vulnerable applications whose code will not be reviewed or patched and it is common knowledge that programmers will continue to produce vulnerable applications. According to [
Auditing all of the source code and protecting dynamic input are not trivial. Neither of them is reducing the permissions of all applications users in the database itself. Checking through log files and relying on the least privileges principle do not seem sufficient. Passively detecting SQL injection is not as useful as preventing it in real time. The use of packet sniffers does not allow for the SQL injection prevention as the removal of malicious SQL query statements from the packets is not possible.
This paper has introduced SQL and SQL injection, outlined background research, discussed methods of protecting against SQL injection and presented existing software on the market today. Given the fact that there is a finite set of words in the SQL vocabulary, it seems possible to develop a filter to prevent SQL injection.