Basics of SQL Injection

Transcription

1 Basics of SQL Injection Sven Helmer April 11, 2018 Contents 1 Getting Started 2 2 Background Basics of SQL SQL Injection First Steps 4 4 Retrieving More Data 6 1

2 1 Getting Started All you need for this lab session is a web browser, all the software will be running on a web server (in the form of servlets). 2 Background This lab session will be about SQL injections, i.e. adding snippets of SQL code to web queries that will be executed in a way that was not intended. Many applications that run on a web server have a relational database as their backend. Usually this means that the web frontend communicates via SQL with this database to retrieve data from the database. If the frontend does not handle the entered data properly, it is possible to smuggle commands past it that will be executed in the database. 2.1 Basics of SQL This section will cover the basics of the Structured Query Language (SQL), which is a standard query language for relational database systems, needed for completing this lab session. We will restrict ourselves to a small subset of SQL. If you already know SQL, you can skip Section 2.1. One of the most important building blocks of SQL is a so-called select-from-where statement. In general it will look like this: select C1, C2, C3,... from T1, T2, T3,... where P In the above statement T1, T2, T3,... are names of tables in the database storing information. Relational databases are made up of tables containing several columns and (usually) a large number of rows. By using the from-clause with table names, you tell the system that you would like to retrieve data from these tables. The select-clause tells the system which columns to select from these tables, i.e. C1, C2, C3,... are names of columns. A short cut for selecting all columns of a table is using * instead of column names. The (optional) where-clause includes a predicate made up of Boolean operators. With this clause certain rows can be filtered out of the result. Let s have a look at a simple example. Assume that we have a table called students which stores information about students: studentno surname firstname course Smith John BSc ISM Miller Anne MSc CS Allen Thomas BSc ISC Carter Robin MSc AIS Walters Kim BSc ISM The following query returns the complete content of the table shown above: 2

3 If we are only interested in the names of the students, we could run the following query: select surname, firstname which would return this answer: surname Smith Miller Allen Carter Walters firstname John Anne Thomas Robin Kim If we want to have the student numbers and surnames of all the students studying on the BSc ISM course, then we would have to formulate the following query: select studentno, surname where course = BSc ISM giving us the following result: studentno surname Smith Walters What happens here is that for each row in the table students the database checks whether the predicate in the where-clause returns true. Only rows who have a value of BSc ISM in the column course will be returned, as for them course is indeed equal to BSc ISM. The rows that have a different value for course will be filtered out. Several conditions can be combined in the where-clause of a query with the Boolean operators and, or, and not. For example, if we are interested in the BSc ISM students with a student number lower than 50000, we would have to formulate the query in this way: select studentno, surname where course = BSc ISM and studentno < yielding the following result (note that strings are delimited by single quotes in a query): studentno surname Smith Here is an example of a query with a Boolean or operator, asking for all the MSc students: 3

4 select studentno, surname where course = MSc CS or course = MSc AIS which would return the following result: studentno surname firstname course Miller Anne MSc CS Carter Robin MSc AIS 2.2 SQL Injection You now have have sufficient knowledge of SQL to start injecting (unwanted) SQL into the processing of the database backend. There are several ways of doing this, in the first part of our lab session we are going to focus on the where-clause. 3 First Steps Start you favorite web browser and navigate to the following address: You will see a login screen that prompts you to enter a name and a password (the password field has not been shadowed so it is easier to see what you have typed). If you just enter some random name and password, your login will probably be rejected. In order for you to see what is actually going on at the backend, you can have a look at the following web page: This will show you which SQL query will actually be executed at the backend. If you take a look at the query, you will realize that the system is looking for the name and password you entered in a table called db2inst2.registered, i.e. the two strings are inserted into a query and if a result is returned, then you will be admitted and if no matching row is found, then you will be rejected. The goal is to trick the database into returning an answer for the query even though you do not know an account name or password. The way to do this is to add something to the data you enter that will result in adding SQL to the where-clause that will always make it true. For example, the following query will always return all the rows in the table students: where course = MSc CS and studentno = or 1=1 The reason for this is that 1=1 is true and true combined with a Boolean or operator with any other value will always yield true. Try adding the phrase or 1=1 after a random password you have typed in. As you will see, this is not successful, as the phrase or 1=1 ends up as part of the password string. (The database automatically delimits your entered string with single quotes.) However, you can trick the system by using single quotes in the string you enter as 4

5 your password, ending the string prematurely and causing the rest of the string to be executed as SQL! Try entering xxx or 1=1 (where xxx is a random password). This will delimit the string xxx, but the database will add a single quote at the end of your string, so it tries to execute the following query: where name = xxx and password = xxx or 1=1 which is syntactically incorrect, as the final single quote starts a new string. We can, however, make this syntactically correct by comparing two strings in the part of the where-clause after the or operator, so executing the following query would work: where name = xxx and password = xxx or 1 = 1 The single quote before xxx and after the final 1 are added automatically by the database, so all you have to enter in the password field is: xxx or 1 = 1 An alternative way to make this work is to add an SQL comment to the query (commenting out the rest of the query, more specifically getting rid of the trailing single quote): where name = xxx and password = xxx or 1=1; -- This ends the query after the ; and adds a comment that contains a single quote. In order to execute this query, you would have to enter xxx or 1=1; -- into the password field. You will get a warning, but the query is still executed successfully. Trying out different entries for the name field will not make any change to the account you log into. You will always be logged into the system as user Smith, as this is the first user returned by the SQL query. If you want to log into the system with a specific account, e.g. Administrator, you would have to comment out the part of the query checking the password but leaving in the part checking the name. There are comments in SQL spanning multiple lines, you have to use the symbols /* (to start a comment) and */ to end a comment. So you would like to execute a query that looks like this: where name = Administrator /* and password = */ and 1 = 1 You can achieve this by entering Administrator /* into the name field and */ and 1 = 1 into the password field. This will comment out the password check and retrieve the tuple containing the name Administrator. 5

6 You have just seen how it is possible to trick a sloppily programmed web application into executing additional SQL code bypassing a password check in our case. We will briefly discuss in the next lecture how this can be avoided when implementing an application on a web server. 4 Retrieving More Data For the second part of this lab session we will focus on parameter passing within a URL. For this purpose, navigate to the following web page: You can select some options in the drop-down boxes and just submit your query to see what happens. You will get some information on certain branches or all the branches. The interesting thing to look at is the URL in the browser after sending off your query, it will look similar to this: /dbaccess/servlet/DB2Servlet?table=branch&area=all One thing you can do now is fiddle with the parameters that are handed to the servlet DB2Servlet. For example, you could replace the table name branch in the above URL with some random string such as xxx. Although this will not lead to any sensible output, causing an error also gives you vital information. Replacing branch as above will lead to the following error message: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/LINUX] SQL0204N "TOMCAT.XXX" is an undefined name. SQLSTATE=42704 This tells you that the application is running on an IBM DB2 database (on a Linux machine). Knowing this you can try to poke around the database by, for example, accessing the table that contains a list of all table names in the database. For DB2 this information is stored in the table syscat.tables. Try replacing branch with this table name. Once you have accessed this list of tables, look at the content of other interesting tables to retrieve information you are not necessarily meant to see (e.g. passwords or the total sales of the Hammersmith branch). 6