We can now construct a valid SQL statement that will execute gracefully and retrieve information that we have no rights to retrieve.

Bypassing Authentication

We know we are dealing with a string column because of the quotes being applied to our input, so we can either the 1=1 or ‘a’=’a clause that were introduced earlier in previous articles.

Here is the exact syntax to use the a=a clause where the appended quotes are used against the application. One of them will be at very beginning and one will be at the very end, which results in a balanced query. Type this in the User ID: textbox.

Re11k’ or ‘a’=’a

This query successfully executes and produces some useful results retrieved from the database shown below.

Vulnerability: SQL Injection

Although most of the results are just first name and last name (surname) for each user, the first result shows admin for both the first name and the surname.

We can be somewhat assured this is the username of the administrator of the web application, but we need to make sure before attempting to bypass authentication.

It is also suggested that you become familiar with performing SQL injection attack via a web proxy so you can see the various ways that an application processes user input.

You can use Burp Proxy to perform this same attack by enabling intercepts and reviewing the params tab under the intercept tab as part of the proxy tool.

Burp Repeater, another tool in Burp Suite, is also a very handy  utility to leverage during injection attacks because it lets you manually refine a specific request and resend to the application.

You can use this functionality to make very specific changes to your attack string (such as an encoded value of a single character) and resend it without having to completely rebuild that request from scratch. It’s extremely helpful as it not only saves time, but also ensures you are only changing the portion of the request that you intended.

Burp Suite

Out last input of Re11k or ‘a’a=’a has a much different representation once it is caught by Burp Intercept as Shown Above.

Notice the values of the id parameter when it is captured in the intercept tool.

The string we entered is now represented by a mix of identifiable string characters, some URL-encoded values, and some additional encoding performed by the browser.

Obviously, the Re11k and the two single a values that we entered are still string character. The %27 is the URL-encoded version of the single quote and the %3D is the equal sign.

Read More: – SQL for Hackers: Learn How Useful SQL

The plus sign are one way that the browser encodes a literal space; you will often see a space URL encoded as %20.

All of these measures are in place so that the user’s input can be used in the URL of the application to be passed to the server for processing.

A literal space is not allowed anywhere in the URL (including any parameter values in the query string) as it would break the acceptable request format supported by the HTTP protocol.

Read More: – The SQL Interpreter

Once you forward the request to the application and the results are rendered, you will see these encoded parameter values in the URL of DVWA.

http://127.0.0.1/vulnerabilities/sqli/?id=Re11k%27+or+%27%3D%27a&Submit=Submit#

You can use either the actual HTML form on the SQL injection page in DVWA or the params tab in Burp Intercept to conduct the rest of the steps.

If you choose to use the proxy, remember that you will have to encode your input accordingly.

The Encoder tool in Burp Suite provides encoding and decoding functionality for several encoding schemes;

Read More: – SQL INJECTION ATTACKS: Finding the Vulnerability

This is the tool that you will use a great deal in your day-to-day work.

To begin with, it is recommended that you use the HTML form so you can learn how the characters you enter in the form are encoded by the application.

After a couple of injections, you will be able to solely use the params tab.

If you have any question regarding SQL: Bypassing Authentication Ask your Question Here.