SQLi Vulnerabilities: Lab 2: SQL injection vulnerability allowing login bypass

Lab 2: SQL injection vulnerability allowing login bypass:

This lab contains a SQL injection vulnerability in the login function.

To solve the lab, perform a SQL injection attack that logs in to the application as the administrator user.

Initial Reconnaissance/Discovery:

When we access the application we can see there is a “My account” page. If we click it we can see we can login.

Let’s enter some fake credentials to view the login process.

This looks like a standard response.

Finding SQLi Vulnerability In the Username Field:

If we send the request to repeater we can add a single quote ' after the username we have entered and send the request.

If we then add an additional single quote so it reads test'' we get a 200 OK response. This shows that our input is being interpretted as SQL syntax.

Inferring The SQL Query Being Run:

We can infer that the query being run on the database is something like:

SELECT * FROM users WHERE username = 'test' AND password = 'test'

However when we add our single quote it becomes which is syntactically incorrect in SQL as we have an open quotation mark.

SELECT * FROM users WHERE username = 'test'' AND password = 'test'

Then when we add our second single quote this closes our first single quote and the SQL is valid, although ugly.

SELECT * FROM users WHERE username = 'test''' AND password = 'test'

Working along these lines this means we could attempt to comment out the remainder of the SQL query by having a payload of [username]'-- effectively bypassing the password check and allowing us to login.

SELECT * FROM users WHERE username = 'username'--' AND password = ''

If we do this for the “administrator” user.

This works and we are no logged in.

This is due to our payload making the SQL query into the below, bypassing the password check.

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''