SQL Authentication Bypass

No credentials? No problem! …well, maybe. If a web application is vulnerable to SQL injection (SQLi), you may be able to bypass authentication.

A typical SQL query is like the following:

SELECT * FROM table WHERE username = ‘bob’ AND password = ‘Str0ngP@ssw0rd!’;

Usually you can start to test for the existence of this vulnerability by inputting a single quote in the website field you want to check. (i.e. set the username field to ‘)

If the vulnerability exists, you will likely get some type of error back which can give additional clues as to how you should proceed next. The message returned may show references to the query on the backend, reveal the version or type of database, as well as some other information. This could be more valuable for something like an error-based SQLi versus authentication bypass but will add to your enumeration nonetheless.

With a single quote as input, the SQL query will looks something like this:

SELECT * FROM table WHERE username = ”’ AND password = ‘Str0ngP@ssw0rd!’;

Strings are denoted by text between two single or double quotes. This input creates an odd number, therefore throwing an error as the query is not processed as expected.

What we can do with this is use an OR operator that satisfies the first check as TRUE. Then we have to negate everything that proceeds this.

Inputting the following will change the SQL query and allow unauthorized login as the first user in the database.
Input: ‘ OR 1 = 1;– –

What this does is resolve the username to a TRUE condition and comment out the remainder of the line. The query now looks like this:

SELECT * FROM table WHERE username = ” OR 1 = 1;– -‘ AND password = ‘Str0ngP@ssw0rd!’;

The semicolon terminates the query and the dashes comment out the rest of the line which we do not want processed.

Let’s say the first user in the database is admin, we are now logged in as them and have access to their resources within the context of that application.