Sql Injection Attacks Pose Computer Science Essay

In recent years, SQL injection attacks pose a common and serious security threat to web applications: they allow attackers to obtain unrestricted access to the database underlying the applications and to the potentially sensitive information these database contain, and it is becoming significantly more popular 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 you can imagine, a hacker gaining administrator access to your server means that you will have effectively lost all of the data on that server to the invader. Worse yet there is now a beachhead behind your firewall from which attacks on other server and services can now be made. In this way SQL injection can provide access to all company or personal data.

In the web environment, end -user privacy is one of the most controversial legal issues, 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 which can be used by the attacker to exploit the web application; as a result the attacker may gain unauthorized access to a database or to retrieve information directly from the database. Attacker can exploit SQL injection vulnerabilities remotely without any database or application authentication. SQL injection attackers are straightforward in nature – an attacker just passes malicious string as an input to an application for stealing confidential information.

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

SQL manipulating usually involves modifying the SQL query through altering the WHERE clause. In this class of attack, amend the WHERE clause of the statement so the WHERE clause constantly results in TRUE [4].

In the case of code injection an attacker introduces new SQL statements into the input field instead of valid input. The classic code or statement appends a SQL server command to make SQL statement vulnerable. Code injection only works when multiple SQL statements per database request are supported or keywords like AND, OR are supported by the database.

Function call injection is the addition of database functions or user defined functions into a vulnerable SQL queries. These function calls can be used to make internal calls or modify data in the database that can be harmful to the users.

SQL injection of buffer overflows is a subset of function call injection. In several commercial and open-source databases, vulnerabilities exist in a few database functions that may result in a buffer overflow.

Once an attacker realizes that a system is vulnerable to SQL injection, he is able to execute any SQL command including DROP TABLE to the database; hence the attack must be prevented.

Protection Methods for SQL Injection attacks:

To build secure applications, security and privacy must be carefully considered, and developer must be aware about it. The main goals of information security are Confidentiality, Integrity and availability.

A single unprotected query can be harmful for the application, data, or database server; hence the SQL injection must be prevented.

SQL injection attacks can be protected with simple changes in server site programming as well as client side programming. Developers must be aware of all types of attacks and take care for all possible attacks. Developers should authenticate user input against rules; ensure users with the permission to access the database have the least privileges; also do not leak any critical info in error log files.

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 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:

try

{

}

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:

try

{

}

catch (Exception exception)

{

int id = GetIdFromException(exception);

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

}

Code review:

Code review can be incredibly difficult to implement, especially in a team of old-timers who are not used to it. But once done, it will not only decrease the number of defects in your code, it will also increase the collaboration and help team building, improve “brotherhood” amongst developers and will propagate best practices and improvement of skill across an entire team or department.

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.

To make a summary:

Encrypt sensitive data

Access the database using an account with the least privileges necessary

Install the database using an account with the least privileges necessary

Ensure that data is valid

Do a code review to check for the possibility of second-order attacks

Use parameterized queries

Use stored procedures

Re-validate data in stored procedures

Ensure that error messages give nothing away about the internal architecture of the application or the database

Conclusion

SQL injection is one of the more common and more effective forms of attack on a system. Controlling the malicious SQL code/script on the web application and maintaining the end privacy is still a key challenge for the web developer. These issues must be considered seriously by the web developers involved in developing websites using databases.