DVWA 1.9+: Manual SQL Injection

Welcome back to the DVWA Series. All previous (and future) DVWA articles are available here. Fell free to explore and comment.

In the present article we’ll try to explore one of the OWASP’s top ten security risks, SQL Injection. DVWA comes prepared to allow for SQL Injection and blind SQL Injection. In this article we’ll cover the SQL Injection.

As mentioned before, SQL Injection is the number one security risk in the OWASP Top Ten 2017 and you can find more information in the previous link.

In case you’re wondering about my layout, I’m using OWASP ZAP 2.8.0 which includes an HUD (the left and right button and the bottom line). Although I won’t be using it directly to alter requests, I’m getting fond of having it.

Remember to change the security settings to ‘Low’ for our initial attack. The diference between a SQL Injection and a blind SQL Injection is about feedback. A blind SQL Injection has limited or no feedback, but that doesn’t make secure. In this case we’re after the normal SQL Injection, so let’s start by using the most common techniques (available in this OWASP article):

1' or ‘1’ = ‘1

Our payload was efficient in getting us all of the database content! As stated in the OWASP article, our query results in a true statement, so the DBMS will return all matching results.

Let’s try with the medium security level.

There is no input text available but there is a form with a select box. This means the webpage as to send our input choice to the server either with GET or POST requests. This is where OWASP ZAP comes into play.

OWASP ZAP is a web capturing proxy, that stands between the web page and the server and allows us to see all communication and tamper with it. With the 2.8.0 came an extraordinary feature, the ZAP HUD that can be enabled using the browser button in the toolbar:

We’ll catch the requests and input our queries to obtain the DB information.

So, if you have not done t already, start OWASP ZAP and open the browser.

Before continuing, put the domain in scope to get all functionality out of the HUD. Click the ‘Submit’ button in the form and take a look at the ‘History’ tab:

Click the latest history line and look at the HTTP Message:

The ‘id’ is in the request. Let’s change it:

Hit Replay in Browser.

“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 ‘\’or\’1\’=\’1' at line 1”

This is a default MySQL error message. Although we already knew it’s a MySQL instance, when testing a new webapp it’s important to fingerprint the backend DBMS. Let’s try to obtain the version using a crafted SQL statement: SELECT id, name FROM users WHERE id=1 UNION SELECT 1, version() limit 1,1

Let’s input our initial SQL statement and take a look at the output:

The high security level introduces more difficulties. I’ll try to get back to it in a future article.

Conclusion

SQL Injection is a major concern for web app security. In the following article we’ll get to use a powerful tool for getting our injection done. See you soon.