# **DVWA(Damn Vulnerable Web Application) THM WALK-THROUGH REPORT**

We will first begin this by connecting to the try hack me vpn, after this we shall start our machine, which will take one minute to give out the IP address.
Now that we have the IP address, we can look it up in our browswer and there we have a login.php page.

**VULNERABILITIES**
We shall try log into the machine with different common credentials. We can start with:
username: admin
password: admin
The site shows us that the login failed. how about we try:
username: admin
password: password
Wow! we are in!

We can see that this site is very vulnerable to bruteforcing attacks using common wordlists. The password did not have any togglecase letters, no numbers and it was practically easy to guess at the top of one's head to be precise.

**1. SQL INJECTION**
When your system is vulnerable to SQL injection, it means that one is able to execute queries to your database and extract sensitive information which is in turn detrimental.

As we can see in the firgure below, when the system asks us for a user id, when we submit a number, it returns the id, firstname and surname of that user.

We can then try to firgure out the type of query being sent to the database through the view source: SELECT first_name, last_name FROM users WHERE user_id = (:id). Now we know there is a users table. We can try extract everyone from this table with a simple sql injection query: test' or 1=1# or test' or 1=1--' Where test could be any name you could think of with a quote at the end to close the username field. the **OR** is used as a conjunction in mysql to give an array of options and the **1=1** is a statement that always returns true no matter what is put as the username therefore all the records in that database shall be output.
The **--' or #** at the end tells the database not to exacute anything else past that point and to comment out any errors in the case of the double dashes.


Another vulnerability I have noticed, is the fact that one is able to change the output through the url. Where id="3", one can change the id and the system shall output the desired results.

We could try view the version of the sql database by keying in the injection: SELECT version() and see what it will yield.

That does not give out any results. I tried to firgure out why and I realised that the ID field is what is vulnerable in this database. We need to use the ID field to extract what we need from the database. We shall then try test' union select null, version()' and see what we get. Yess!! we are able to see here that the version of our database is 5.5.61-0ubuntu0.14.04.1.


We can also try to view the hostname and the user using the same injection and here are our results:

**RECOMMENDATIONS**
To prevent such sql injection attacks, one needs to atleast ensure the following:
Always check your database against SQL injection vulnerabilities
Input validation: having all inputs go through a specific standard determined by the application.
Monitoring what is being input into the system and flagging anything that seems unusual.
Whitelisting and blacklisting: Allowing and dissallowing specific content like IP addresses, domain names from accessing the system.

**2. BRUTE FORCING**

We are going to shake things up a little bit and check out the brute forcing tab on DVWA and see what it has to offer us.
For starters, when I tried to log in the page with the original log in credentials, it worked! Shocking how simple that was:
username: admin
password: password
This came up:

Though when I tried logging in with a random password, this came up:


The username or password was incorrect.

We can try use burpsuite and submit some payloads to go through the brute forcing process and see how that goes. We try logging in with the incorrect details and this is the response we get:

We shall try upload some payloads from burpsuite simple list and see whether we can hack the password with burp

We have the payload for the usernames:

We also have the payload for passwords:

Sending url to the intruder for the payload target:


Here are the results, though I really need to work on it again and see what my results would be the next time.

**RECOMMENDATIONS**
To brute force attacks, major changes that should be included are:
Setting a limit to the number of log-ins one should make: this is so that we are able to slow down the attacker.
Anotherr option would be to include complex passwords that have encryption keys or mixedlanguages that can't be found in wordlists.

That's all for today, see you next time when we handle other applications in this box!