Code Injection Attacks Methods And Defence Mechanisms Computer Science

Add: 22-11-2017, 17:42   /   Views: 151

Introduction: - As the Internet is growing day by day, most of the people are not aware of security and privacy. Internet is a widespread information infrastructure; it is basically an insecure channel for exchanging information. Web security is the set of rules and measures taken against web security threats. Web privacy is the ability of hiding end user's information. Nowadays most of the applications have the vulnerability (weakness) that makes a threat possible. An attack may be possible due to poor design, configuration mistakes, or poor written code of the web application. A threat can be harmful for database, control of web application, and other components of web application, that are need to be protected from all types of threat. All types of code injection or SQL injection are very dangerous for these components of the web application.

To build secure applications, security and privacy must be considered, and developer must be aware about it. The main goals of information security are Confidentiality, Integrity and availability. Confidentiality means the information available on a system should be safe from unauthorized people; Integrity means the information available in an organization should be complete and whole. It shouldn't be altered by any unauthorized person. Availability is as important as Confidentiality and Integrity. It means the information requested or required by the authorized users should always be available.

CODE INJECTION ATTACKS: - Code Injection is a term used when malicious code/script is injected into a program/web application from an outside source, for example input field which is provided by the web application to take input from the end-user. This attack makes use of lack of accurate input/output data validation. The injected malicious code executes as a part of the application. If successful would result in either damage to an asset, or undesirable operation. Attack can be performed within software, web application etc in which the weakness is present. This term applies to mistakes regardless of whether occur in implementation, design, or other phases of the software development life cycle (SDLC). Weakness contribute to the introduction of vulnerabilities within that software or web applications, vulnerability can be used by the attacker to exploit the web applications to gain access unintended data, denial of services, or perform incorrect operations. HTML Injection Attack, Cross Site Scripting Attack, SQL Injection Attack, Shell Attack, Content Spoofing, HTTP Response Splitting, HTTP Request Splitting and XML Poisoning Attack are some examples of the code injection attack.

SQL Injection: - SQL injection is an attack technique used to exploit application either to gain unauthorized access to a database or to retrieve information directly from the database. [15 integrity]. Attacker can exploit SQL injection vulnerabilities remotely without any database or application authentication. SQL injection attacks are straightforward in nature - an attacker just passes malicious string as an input to an application for stealing confidential information. The complexity of the attack involves exploiting a SQL statement that may be unknown to the attacker. Open-source applications and commercial applications delivered with source code are more vulnerable since an attacker can find potentially vulnerable statements prior to an attack [www.net-security.org/dl/.../IntegrigyIntrotoSQLInjectionAttacks.pdf].

Structured Query Language (SQL) is a specialized programming language for sending queries to databases. Many database products support SQL because it is a standard language. Applications often use user-supplied data to create SQL statements. If an application fails to properly construct SQL statements it is possible for an attacker to alter the statement structure and execute unplanned and potentially hostile commands. When such commands are executed, they do so under the context of the user specified by the application executing the statement. This capability allows attackers to gain control of all database resources accessible by that user, up to and including the ability to execute commands on the hosting system [projects.webappsec.org/w/page/13246963/SQL-Injection].

SQL Injection using Dynamic Strings: -

Most of the web based application takes input from the end user for constructing dynamic SQL statement:

Query = "SELECT * FROM student WHERE sname = "studentname" ";

Example 1 - Dynamically built SQL command string

Consider a web application that takes input from the students and displays the result of the student, with the logic of the above SQL query, the result of the above query is as follows

Suppose an attacker submits a student name that looks like the following:

Student Name: nikita' OR '1'='1

The SQL command string built from this input would be as follows:

SELECT * FROM student WHERE sname = 'nikita' OR '1'='1'

This query will return all rows from the student's database, regardless of whether "nikita" is a real user name. This is due to the OR statement appended to the WHERE clause. The comparison '1'='1' will always return a "true" result, making the overall WHERE clause evaluate to true for all rows in the table. If this is used for authentication purposes, the attacker will often be logged in as the first or last user in the table.

Blind SQL injection: - Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application, rather than getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements [http://www.owasp.org/index.php/Blind_SQL_Injection].

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen.

SELECT sname FROM student WHERE sname = 'fahim' AND 1=1;

This statement will result in a normal page while

SELECT sname FROM student WHERE sname = 'fahim' AND 1=2;

This will likely give a different result if the page is vulnerable to a SQL injection. An injection like this may suggest to the attacker that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of another column or table outside of the SELECT statement's column list.

CATEGORIES OF SQL INJECTION ATTACKS

There are four main kind of SQL Injection

1. SQL Manipulation

2. Code Injection

3. Function Call Injection

4. Buffer Overflows

SQL manipulation 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 [www.integrigy.com/.../Integrigy_Oracle_SQL_Injection_Attacks].

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 insertion of database functions or custom functions into a vulnerable SQL statement. These function calls can be used to make operating system calls or manipulate data in the database.

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.

SQL INJECTION METHODS

There are four types of SQL Injection attacks,

SQL MANIPULATION

The most common type of SQL Injection attack is SQL manipulation. The attacker attempts to modify the existing SQL statement by adding elements to the WHERE clause or extending the SQL statement with set operators like UNION, INTERSECT, or MINUS. There are other possible variations, but these are the most significant examples.

The classic SQL manipulation is during the login authentication. A simplistic web application may check user authentication by executing the following query and checking to see if any rows were returned -

SELECT * FROM users

WHERE username = 'admin' and PASSWORD = 'adminpsw'

The attacker attempts to manipulate the SQL statement to execute as -

Figure 1 Inserting Malicious Script into Web PageSELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' or '1' = '1'

Based on operator superiority, the WHERE clause is true for every row and the attacker has gained access to the application.

Figure 2 Result Generated which lists out all the data in database

The set operator UNION is frequently used in SQL injection attacks. The goal is to manipulate a SQL statement into returning rows from another table. A web form may execute the following query to return a list of available products -

SELECT product_name FROM all_products WHERE product_name like '%Chairs%'

The attacker attempts to manipulate the SQL statement to execute as -

SELECT product_name FROM all_products WHERE product_name like '%Chairs' UNION

SELECT username FROM dba_users WHERE username like '%'

CODE INJECTION

Code injection attacks attempt to add additional SQL statements or commands to the existing SQL statement. This type of attack is frequently used against Microsoft SQL Server applications, but seldom works with an Oracle database. The EXECUTE statement in SQL Server is a frequent target of SQL injection attacks - there is no corresponding statement in Oracle.

In PL/SQL and Java, Oracle does not support multiple SQL statements per database request. Thus, the following common injection attack will not work against an Oracle database via a PL/SQL or Java application. This statement will result in an error -

SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword'; DELETE FROM users WHERE username = 'admin';

However, some programming languages or APIs may allow multiple SQL statements to be executed.

PL/SQL and Java applications can dynamically execute anonymous PL/SQL blocks, which are vulnerable to code injection. The following is an example of a PL/SQL block executed in a web application -

PROTECTING AGAINST SQL INJECTION

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. Each and Every dynamic SQL statement must be sanitized. A single unprotected query can be harmful for the application, data, or database server.

TAKING USER INPUT FROM PREDEFINED OPTIONSBIND VARIABLES

The most powerful protection against SQL injection attacks is the use of bind variables. Using bind variables will also improve application performance. Application coding standards should require the use of bind variables in all SQL statements. No SQL statement should be created by concatenating together strings and passed parameters.

Bind variables should be used for every SQL statement regardless of when or where the SQL statement is executed. A very complex SQL injection attack could possibly exploit an application by storing an attack string in the database, which would be later executed by a dynamic SQL statement (referred to as a second-order attack).

The previous chapters on PL/SQL and JDBC demonstrated how to effectively use bind variables to eliminate SQL injection vulnerabilities. The use of bind variables is simple, but does require at least one more line of code per variable. Since a typical SQL statement may be using 10-20 values, the additional coding effort may be substantial.

There are a few rare occasions when a developer must dynamically create a SQL statement - these exceptions are detailed in the next chapter.

Parameterized statements

To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, parameterized statements must be used (preferred), or user input must be carefully escaped or filtered.

With most development platforms, parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter. This can be done by using a predefined function present in PHP (mysql_real_escape_string($user_input)).

INPUT VALIDATION

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.

For Oracle databases, the only character at issue is a single quote. The simplest method is to escape all single quotes - Oracle interprets consecutive single quotes as a literal single quote.

The use of bind variables and escaping of single quotes should not be done for the same string. A bind variable will store the exact input string in the database and escaping any single quotes will result in double quotes being stored in the database.

FUNCTION SECURITY

Standard and custom database functions can be exploited in SQL injection attacks. Many of these functions can be used effectively in an attack. Oracle is delivered with hundreds of standard functions and by default may have grants to PUBLIC. The application may have additional functions which perform operations like changing passwords or creating users that could be exploited.

All functions that are not absolutely necessary to the application should be restricted.

DYNAMIC PROCEDURE AND FUNCTION CALLS

When generating a procedure or function call dynamically, a bind variable cannot be used for the procedure or function name. For most applications, valid database object names (procedure and function names) can contain only alphanumeric characters and the underscore (_), dollar sign ($), and pound sign (#). Period (.) and at sign (@) are used to specify package names and database links.

Single quotes and other special characters are not valid.

Any dynamically called procedure or function should be validated and all invalid characters should be stripped from the string.

Conclusion

Handling the SQL vulnerable code/script on the web application is still a major challenge for developer. These subjects should be considered seriously by the web developers involved in developing websites using databases. In this work the attack scenario is implemented to demonstrate how SQL Injection, is imposed to attract the end users of web application and make them victims by these types of attacks.

For this privacy policy should be enforced and end user should be aware of it.

This paper describes how an attacker can get confidential information from a database. This attack can be used to silently snoop private. The main contribution of our work is to prove the feasibility of SQL code injection into database. It does not prevent it completely.