creating a web application security lab part 2

securing and accessing your lab

Now that construction of your lairs have completed you might want to visit and inspect the marvels you have created. If you paid attention in part 1 you might have noticed that we used the fictional .lair top level domain. As this is not a valid domain you will have to set your own dns. You can run your own dns server (in which case you shouldn't need thisw guide), or we can override it using the hosts file. On unix like systems (linux, mac os) you will find this file located at /etc/hosts and on windows it is c:\windows\system32\drivers\etc\hosts (You'lll need administrative/ or root privileges to change this file). I added my labs like this:

127.0.0.1 localhost.localdomain localhost
# Auto-generated hostname. Please do not remove this comment.
184.105.235.24 moon.lair
184.105.235.24 vulcano.lair

184.105.235.24 is off course the IP of my server. After changing this file you can browse to http://moon.lair and http://vulcano.lair in your browser. Once you have established access you should check that your lab embodies the characteristics you gave it, the quickest and easiest way to do this is with phpinfo. As root on your server, create a phpinfo file in the appsec lab webroot.

root@localhost$ echo "" > /var/www/appseclab/webroot/secrit.php

Now you can verify you php_flag settings by visiting the phpinfo url. Although it is the same file, the php_ directives in each virtual host allows you to change the php behaviour of each virtual host, but you knew that already. So now that you have verified that you can access the lairs and they have the special features you requested there is but one small problem, they are accessible by anyone. Sure, you've hidden them away using tricky domains and hopefully, no-one bothers to look. You could set some henchmen to monitor the apache logs and launch an all out assoult on any unfamiliar IP accessing the lair, but since hencmen are unreliable I recommend a more consistent approach. Passwords! We'll start by creating the password file using the htpasswd utility.

root@localhost$ htpasswd -m -c /var/www/appseclab/etc/.htpasswd drevil
New password:
Re-type new password:
Adding password for user drevil
root@locahost$ cat /var/www/appseclab/etc/.htpasswd
drevil:$apr1$BIJjwQFA$ZpWJEJ15o/Fub6Chn7EGk0

Next we add authentication to our common config.

AuthType Basic
AuthName "Beware of sharks with lazors on their headz!"
AuthUserFile /var/www/appseclab/etc/.htpasswd
Require user drevil

Now restart apache to activate your cunning password protection scheme! What could ever go wrong!?!?!?

Like all supervillan plots, there is a gaping flaw which will allow the hero to seize the day and ensure your defeat.Your lab is still exposed to the internet and the only protection offered is a password which is transmitted in cleartext over the wires. You could always enable SSL on the virtual hosts, but that only solves half the problem and could affect the behaviour of some web apps when testing them in your lab.
A better option would be to bind the virtual host to a private or internal interface and connect to it using VPN or SSH port forwarding. This will encrypt the traffic and keep your lab away from the internet.