Introduction Of Sql Injection Attack Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

In recent years, SQL injection attacks pose a common and serious security threat to web applications: the attackers are given rights to obtain unrestricted access to the database underlying the applications and to the confidential information these database contain, and it is becoming more popular and prevalent amongst hackers. According to recent data, between Q1 2012 and Q2 2012, there has been an estimated 69 percent increase of this attack type. [1][2]

As we can imagine, a hacker gaining administrator access to the server means that all of the data of the website would have been leaked to the invader. What's worse, behind your firewall, there is now a beachhead on which attacks on other server and services can now be made. By doing so, all company or personal data are allowed to be accessed through SQL injection.

In current web environment, one of the most controversial legal issues is the end -user privacy, therefore, all types of SQL injections which are dangerous for the components of the web application must be prevented.

This article introduces the SQL injection in the first section then provides some techniques for defecting and preventing this kind of attack in the second section.

Section 1: Introduction of SQL injection attack

SQL injection is an attack technique that the attacker uses to exploit the web application, resulting in the attacker gaining unauthorized access to a database or retrieving information directly from the database. Even without any database or application authentication, an attacker can exploit SQL injection vulnerabilities remotely. The attacker can steal sensitive information just by passing malicious string as an input to the application.

There are four main kinds of SQL Injection attacks: SQL manipulation, Code injection, Function call injection and Buffer overflows. [3]

Through altering the WHERE clause, SQL manipulating usually can be achieved by modifying the SQL query. In this kind of attack, attacker changes the WHERE clause of the statement and makes the WHERE clause constantly equals to TRUE [4].

For code injection, instead of valid input, the attacker introduces additional SQL statements into the input field. To make SQL statement vulnerable, the typical method is to append a SQL server command. Code injection can only work when single database supports multiple SQL statements or the database supports keywords like AND, OR, etc.

As an addition to database functions or user defined functions, function call injection is a vulnerable SQL query. By making internal calls or modifying data in database, the function calls can be very dangerous to the customers.

As a subset of function call injection, buffer overflows is another type of SQL injection. In lots of commercial and open-source databases, vulnerabilities are detected in a few database functions that may lead to a buffer overflow.

Once an attacker notices that a system is possible to be attacked by SQL injection, then he can execute any SQL command even including DROP TABLE to the database. From above devastating damage, we know the SQL injection attack must be prevented.

Section 2: Protection Methods for SQL Injection attacks

Because a single unprotected query could be very harmful for the application, data, and database server, in order to build secure applications, we must carefully consider security and privacy. Confidentiality, Integrity and availability are the main goals of information security.

We can protect applications from SQL injection attacks by making some simples changes in server site programming and client side programming. Developers must be aware of all types of attacks and fight against all possible attacks. We need to authenticate user input against rules; make sure users are allowed to access the database with the least privileges; also do not conceal all critical info in error logs.

Taking user input from predefined choices:

In this way the web application can be secured from malicious attacks. The attacker cannot insert custom queries or any type of harmful script which can disturb the integrity of the database. This is a simple yet effective way to curb web application attacks. This can be established by making simple changes into the server site code.

Bind variables mechanism:

Bind variable is another technique to control SQL injection attacks. Using bind variables helps in improving web application performance. The web application developer should use bind variables in all SQL statements. In Java language there is a mechanism called prepared statement, this implements the concept of bind variables mechanism.

Input validation:

This is the simplest method for defense against SQL injection attacks. User input should always be treated with care and there a number of reasons to validate all of the user input before further processing. Every passed string parameter ought to be validated. Many web applications use hidden fields and other techniques, which also must be validated. If a bind variable is not being used, special database characters must be removed or escaped. In most databases the single quote character and other special characters are a big issue, the simplest method to avoid them is to escape all single quotes. This can be established by using client side scripting language.

Validation code can help to avoid wasting server resources by restricting requests that would not return useful results and they can provide much more helpful messages to the user than a SQL error message or empty result set would likely provide. Also, they can help stop SQL injection by rejecting, outright, any forms of input that could be used to perform a SQL injection. With the benefits that validation can bring, it is generally wise to validate all user input, even when fully parameterized database calls and uses and uses an account with limited permissions.

Use automated test tools:

Even if developers follow the coding rules and do their best to avoid dynamic queries with unsafe user input, we still need to have a procedure to confirm this compliance. There are automated test tools to check for SQL injections and there is no excuse for not using them to check all the code of your database applications.

Code review:

Sometimes, code review may be very difficult to conduct, particularly in a team of old-timers who are not used to it. But code review will definitely decrease the number of defects in source code, and also will increase the collaboration and help team building. Code review would propagate best practices and improve the coding skills among team members.

Use only stored procedures:

The greatest value for using stored procedures in preventing SQL injection is that the DBA can set permissions for the application account so that its only way to interact with the SQL server is through stored procedures. This would mean that most SQL injection attacks would fail due to lack of permissions even if the calling program did not parameterize. This of course still leaves open the possibility of SQL injection working through dynamic SQL inside the stored procedures, but the stored procedures can be given an "execute as" clause which limits their permission to only those needed by the procedure. It is generally easier to verify that all stored procedures are written to guard against SQL injection then it is to check every place where the application interacts with SQL server.

Limit permission:

The most important thing is that we should never user admin rights for web based application. The safe way is to give the user as little rights as possible in other word user rights should allow him to do only what is necessary and nothing more. If the account does not have permission to drop a table, then it will not be dropped even if the command is slipped to SQL server. Similarly, if the account has only read access, although the attack my have right to gain some information, he/she will be not able to modify or destroy the data, which is frequently worse. Even the read permission should be strictly limited by database, to limit which tables can be viewed. And if the application only needs selected columns from a table, then read permission on the view can be granted rather than the full table.

Conceal error messages:

Injection attacks often depend on the attacker at least some information about the database schema. [4] One common way for hackers to spot code vulnerable to SQL injection is by using the developer's own tools against them. For example, to simplify debugging of failed SQL queries, many developers echo the failed query and the database error to the log files and terminate the script. In this case, error messages are useful to an attacker because they give additional information about the database that might not otherwise be available.

It is often thought of as being helpful for the application to return an error message to the user if something goes wrong so that if the problem persists they have some useful information to tell the technical support team. Hence, the generated error becomes a literal guideline to devising more tricky queries.

For example, applications will often have some code that looks like this:




catch (Exception exception)


MessageBox.Show("log on failed", exception.Message);


A better solution that does not compromise security would be to display a generic error message that simply states an error has occurred with a unique ID. The unique ID means nothing to the user, but it will be logged along with the actual error diagnostics on the server which the technical support team has access to.

The code above would change to something like this instead:




catch (Exception exception)


int id = GetIdFromException(exception);

MessageBox.Show("log on failed", id.ToString());