SEC602 LAB 14 – Web Application Vulnerabilities

To begin lab 14 I logged into the server and disabled the world wide web publishing service.


I then navigated to the user accounts control settings and set it to “Never notify”.


Because the world wide web service is now inactive, I installed XAMPP to take its place as a web server. During installation I only selected the Apache and MySQL server options and installed it.


I then opened the XAMPP Control Panel and started the Apache and MySQL services, noting the ports that they run on.


After that I extracted the contents of the dvwa folder found in c:\gtslabs to the htdocs folder within xampp.


After it had been extracted I edited the config file to ensure that the db_password field was blank.


I then had to create a inbound firewall rule that would only connections through xampp. The rule applies to TCP and the ports noted previously: 80 http, 443 https and 3306 MySQL.


Once that had been done I navigated to the server page in internet explorer and was displayed the following page. I clicked the “Create/ Reset Database” button and a database was created for me.


I then logged in to the DVWA admin area and altered the security level from high to low. This makes it easier to perform cross side scripting on the web server and connected database.


I then navigated to the command execution screen and inputted “server”. The resulting text shows the server being pinged.


I then executed another command ” – l 800 server” which performed a ping again but instead of sending 32 bytes of data, it sent 800.


I then type /? which gave me a list of commands available. This input box is acting like command prompt and its ping function.


I then proceeded to type “server | dir” which listed the contents of the server. It is clear that DVWA is vulnerable to command injection where commands can be executed on the server of which the server was not designed to do. This page should only be able to ping hosts, but instead people also have the option to list the directories and perform other arbitrary commands.


I then navigated to the SQL Injection page and submitted “2”. This then gave me the corresponding information about the user with the ID of 2.


I then typed hello into the box which resulted in nothing. I followed this with a single quote which gave me an SQL syntax error. This shows my that the application executes SQL statements using the input.


I then navigated to the XSS Reflected page which handles cross site scripting. I typed a name into the input box and the following was returned.


I then typed “alert(‘Hello World!’)” into the input box which exploited a vulnerability in the web application causing it to run the script.


Critical Analysis and Thinking

From this lab it is clear that there are many ways to exploit a web application but this vulnerability largely depends on what the application is built for.

Command line injection, SQL injection and Cross site scripting were three of the techniques used in this lab to exploit the web application. Out of the three, Cross site scripting​ is the most worrying for developers as its vulnerability is through the website itself. Other than SQL injection and command line injection which need either a database or a shell behind them. Cross site scripting can be executed without any assistance.

Because of these vulnerabilities developers should test there application before it goes live. They should also take steps towards preventing these exploits by checking the user input and making sure it is validated before it is executed.

SEC602 LAB 14 – Web Application Vulnerabilities

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s