There have been a number of people coming to me and asking what tool to use for testing web applications. The answer is easy. The tool is Burp Pro.
However, I think many people are missing the point. When dealing with a web application the true vulnerabilities are not the ones that are identified when scanning an application with a tool. Sure, there are tools will help you find things like XSS or SQLi, but what about some of the harder to spot vulnerabilities? Things line XSRF and logic errors are not things that can be easily identified with a tool but can be devastating when attacked.
So what I want to offer today is a sort of quick view of how to approach a web application when looking for those hard to find vulnerabilities.
First, let’s identify some tools to assist with testing for XSRF. Notice, I did not say tools that will test for XSRF.
I said these tools assist with testing for XSRF because it will required you to do a bit of research into the business logic flow of an application.
Speaking of business logic flow, it is also important to map out how an application is put together. Look at the different input fields through the lens of Burp. See where different fields (input and output) exist. When you have identified these different fields, start tampering with them and seeing how the application reacts.
I want to share a presentation with you that clearly identifies how to do a great web application assessment.
Go and spend some time looking over the presentation. See how little of it was related to XSS and SQLi? This is what we mean by testing business logic.
I also wanted to share something that many people know about, but many more do not. I am shocked at how many of my students do now know about Laudanum. If you have the ability to upload scripts, you need to upload Laudanum. You upload the correct script (i.e. shell.asp for asp servers .php for php servers, etc.) and then you browse to the file you have uploaded. If everything went correctly (and it will most of the time) you will have shell on the server.
Finally, try forced browsing. What you do is list out all of the pages that are available to an administrative user (i.e. user management pages) then log in as a standard user, then try to view the admin pages by force browsing to them. For many sites the only security they have keeping general users from these pages is the fact that the links to them have been removed.
Is this everything you need to know? Not even close. I just hope it gets you going down the right direction. Tools are great, but we are Penetration Testers. We need to do more.
Plus, simply running tools is boring....
PaulDotCom will be teaching Offensive Countermeasures at Black Hat July 30-31