Now we will study an SQLi in a different file, on a different page, and see a few different things that we can do to exploit that vulnerability. So, first, go to the login page, which is in OWASP Top 10 | A1-Injection | SQL-Extract Data | User Info:

In the previous section, we went to the login page by clicking on the Login/Register option on the page; this time we're going to go through the User Info page, so the page will show us information about the user, provided we give the Name and Password. Enter all the credentials, such as username and password, and the page will show us all the username and password details and our signature, as shown:

The statement that's been executed here is similar to what was executed when we logged in. As we can see in the following code, select * from accounts where $USERNAME is what we put in the username field, and $PASSWORD is what we put in the password field:

select * from accounts where username = '$USERNAME' and password='$PASSWORD'

Now we're going to see a different way of exploiting this kind of vulnerability. In the previous section, we were doing it using a POST textbox, so whatever you put in the textbox was being posted to the web application using a POST method. Now, these vulnerabilities can exist in the GET method too, and what we mean by GET is that, when something is sent using GET, we will see it in the URL. So, if we look at the following URL, we see it's being sent as username=zaid&password= 123456:

Copy the URL and we will start playing with it from the URL instead of on the web page. We just want to show a different example, because in many places there might not even be textboxes. It could be something such as news.php. In our example, it's index.php, and in our pen testing, you might see something such as news.php and id=2, and then we can try to inject it in there. So, we're going to be injecting things into the username field, and we will enter information in the URL. When we are doing our pen test, any time we see parameters such as username and password, we should try to inject them; any time we see something.php and then we have a parameter that equals something, always try to inject it in there and see if it works for us.

We've also seen a way of discovering the injection using a quotation mark and an and statement. So we do a false and, and a true and, and 1=1, and then and 1=2, and if the server executes what we want, we're going to know there's an SQLi. We are going to see another way of discovering these exploits, by using the order by statement. The order by statement is used to limit the amount or the number of records that are going to be displayed onscreen. Our injection is going to do order by 1. If the injection exists, this should work because order by 1. There should be at least one record being selected in the page because we know this page is communicating with the database. So, order by 1 should always work and return true or something we expect. We also need to add the comment and execute a code, so it's exactly as before. Basically what's going to happen on the database is that the code that will be executed on it will look as follows:

select * from accounts where username = 'zaid' order by 1#' password='$PASSWORD'

The command for the URL will be as follows:

index.php?page=user-info.php&username=zaid' order by 1#&password=123456&user-info-php-submit-button=View+Account+Details

For this example, it's going to be select * from accounts where username = 'zaid', and note how a single quote (') ends the statement; we're going to do order by 1. The comment will tell the SQL interpreter to ignore anything that comes in after it, which is all of commands after hashtag (#). Copy the preceding code and paste it in the Name textbox of the login page. This will work, but we are just looking at a different way of doing it by injecting it through the browser. Another thing to note is that, when we are injecting stuff into the browser, the code should be encoded so, for example, the hashtag (#) sign should be written as %23. Spaces, for example, get converted to %20, and %23 is the comment that we're using, so we are going to copy that and replace our comment sign with it in the URL space. So, the URL changes to the following:

index.php?page=user-info.php&username=zaid' order by 1%23&password=123456&user-info-php-submit-button=View+Account+Details

Paste the URL in the address bar and hit Enter, and we will something that's acceptable. Then it will show us the information about zaid, 123456, and and also the Signature, so it is ignoring the password, so the injection worked—it's ordering by 1, so it's not showing any error:

Let's try to make 1 a very large number, for example, we can put 10000 or 100000 in the URL section. It will show us 1000000 records on the login page. The chances are the page will not display 1000000 records and there aren't 1000000 records in the database, so when we execute it, we will see that there is an error. The error is in the order clause and there is an Unknown column for 1000000:

So, there aren't 1000000 columns in the database, and this is great because now we know that the database is executing what we want. So, when we told it to show 1 record, it show us one record, and when we told it to showed us a very large number of records, it complained about that, so it's obviously vulnerable to SQL injections.