Home / IT Security / SQL Injection / SQL INJECTION ATTACKS: Finding the Vulnerability
SQL INJECTION ATTACKS: Finding the Vulnerability
SQL INJECTION ATTACKS: Finding the Vulnerability

SQL INJECTION ATTACKS: Finding the Vulnerability

SQL Injection Attacks: Now that we have the basics of SQL injection down, let’s use our DVWA environment to try it out on a vulnerable page. We have a couple of goals for this section:

  1. Crash the application to prove that our input dictates the applications behavior.
  2. Retrieve usernames from the database for a targeted attack to bypass authentication.
  3. Extract out useful information from the database (we will be gathering password hashes).
  4. Crack the password hashes so we know the username and password of each of the application users.

 

The DVWA exercise that we will be working through for this vulnerability is SQL Injection,

which can be accessed by clicking on the link in the menu on the left side of DVWA once you have logged in with the admin | password credentials.

 

SQL INJECTION ATTACKS: Finding the Vulnerability

 

Finding the Vulnerability: The first task is to find the SQL injection vulnerability in this page. 10-15 years ago, when SQL injection was first being exploited,

it was commonplace to simply put a single quote in a search box and watch the application blow up.

Accessing the SQL injection lesson in DVWA
Accessing the SQL injection lesson in DVWA

 

This one single quote would throw out of a balance and the application would error out.

We can attempt to identify the DVWA vulnerability by using this exact method of inserting a single quote in the user ID textbox.

Instead of a single quote, we are going to use a string with an extra single quote as our User ID entry as introduced here:

Re11k’

This input throws the following SQL error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’Re11k’’’ at line 1

In this application, all user input is enclosed in two sets of single quotes (not double quotes).

 

READ MORE: SQL for Hackers

 

We don’t know the exact table or columns names yet, but it’s safe to assume that our input created a query very similar to this:

SELECT * FROM users WHERE user_ID = “Re11k”’

This query, and subsequent crash of the application, proves we are in total control of the SQL statement.

It is critical that you become a connoisseur of web application error messages because they are often times the keys to the kingdom!

Resist the temptation to simply dismiss error messages as a failed exploitation attempt and instead realize they provide a vast amount of information on how the application is processing your input.

Think critically about parameters that you provide that may be included in queries that are sent to the database.

 

READ MORE: The SQL Interpreter

 

These are the type of parameters that you should test for SQL injection.

Items such as numeric ID parameters such as UID=81, text search term parameters such as the shoe search covered earlier, and parameters that contain string ID parameters such as sort=ASC or sort=DESC

 

If you have any question regarding SQL INJECTION ATTACKS: Finding the Vulnerability click here to ask.

 

Josh Pauli | SYNGRESS | SQL Injection Attacks: Finding the Vulnerability

 

About Jahanzaib Khan

Jahanzaib Khan is Web Designer & Ethical Hacker. He Who has been working since 2014, and is managing several successful websites on the internet for about 3 years. Jahanzaib-khan.com

Check Also

SQL: Bypassing Authentication

SQL: Bypassing Authentication

We can now construct a valid SQL statement that will execute gracefully and retrieve information …

2 comments

  1. I truly appreciate your work, Great post.

Leave a Reply

Your email address will not be published. Required fields are marked *