This guide is written with newbie’s in mind to show them some of the basic concepts when testing web applications and trying to bring them up to speed on testing web applications. It’s not designed to be a one stop solution but a way to explain some of the basic information and give them materials to go and find out more for themselves.
In order to test web applications there are three tools that I use every single time. I use Firefox as my testing browser with foxy proxy plugin, Burp suit as my proxy and Google chrome for searching browsers, as I don’t want any Google searches affecting what’s in burp suit as the client may wish to see the burp suit logs.
Starting the test
Once I have good idea about the site I start by looking for default pages. For example if it’s a contents management site like Word press, Drupal or any other popular site, I tend to download the files and quickly set it up in a Lamp, WAMP or MAMP environment this way I can see what the default settings are as well as how the files are structured. This gives me a good idea of where to look in the application I am testing. Can I access an admin page? Or is there a backup of the default admin login detail? This all needs to be investigated to see what you can and cannot access and help map the application.
If the application is not using a CMS then I start by trying to access common files like robots.txt and then try to view any pages listed in that. If there are not any robots files, I then try default pages like admin.php, account.php so on. At this point you could use the spider feature in burp suit to try and get a much better idea of the application or use Dirbuster to try brute force on any hidden directories.
Once this has all been done you should have a really good understanding of the application. What it does, how it was build and maybe even some small issues to report like internal path, information disclosure etc. Having a good idea of how the application was built, this is an essential to understand as if you trying to exploit an SQL injection. If you know the developers have followed a certain naming pattern, you can take an educated guess they have done the same in their database this will make exploiting it easier if you find SQL injections on the site.
Starting the attack
We have a really good understanding of the site and the inner workings and so it’s time to start finding issues with the site.
If the website has a login page then I first create an account, during this process I see if I can use a weak password like the character ‘A’. If I can then this is an issue and would report it to the client as they should be using at least 9-20 characters with a mixture of upper, lower, numbers and symbols for the password. After I have registered with the site I attempt to login to the site looking for any errors messages. I want to make sure that the errors are not given any information away like “This passwords does not match the username” As an attacker this then tells me that I have a valid username so I can enumerate user.
This is where you can inject into the page; you can find this with an error message, which is the most common place, just like the example below. The reason this is an issue is it lets anyone write anything on your site so it’s a great tool to use with social engineer. We could write a message encode it then send it to a customer, they would then ring the number and we could try to get account information from them.
Example Error injection
http://testsite.com/page/sign-in?error=Please call tech support 0800 000 000