When performing black-box web application penetration test one of the most important steps, but often overlooked is the application profiling phase. The objective of the application profile phase is gather as much information about the application structure and the applications functionality as possible. Typically, especially during a black-box test, the tester is provided the application URL and perhaps a couple of logins to use for the pentest.
As with any other phase of a pentesting, the application profile phase is really made up of several steps. One of these steps is determining the applications directory structure. Its simple to find the “public” directory structure of the application, but what about the “private” directories of the application that should not be found, such as old versions of the application or more importantly administration functions?
To find these and other gems that can provide juicy information hidden in the “private” directories the tester must fuzz the applications directory structure. Web application fuzzing is simply sending random data to the web site requesting a resource and reviewing the results of the request to determine if the resource exist.
To give a simple example how fuzzing works lets examine the fuzzing process on the imaginary website www.site.com. The website directory structure consist of the following directories and if they are linked in the web application:
/admin – Not linked in the web application
/docs – Linked in the web application
/images – Linked in the web application
/pages – Linked in the web application
/scripts – Linked in the web application
/source – Not linked in the web application
/test – Not linked in the web application
The following HTTP status codes are used when fuzzing an application to inform the tester if the requested resource exist:
200 - OK
301 – Moved Permanently
302 – Moved Temporarily
401 - Unauthorized
Any other HTTP status code says the resource does not exist or is forbidden (HTTP 403 status code) to the tester. Understanding the HTTP status codes, the tester can to fuzz the application to determine its directory structure.
The tester will fuzz the directory structure by manually requesting the following directories and the request corresponding HTTP status code:
/admin – 401
/backup – 404
/code – 404
/docs – 200
/images – 200
/include – 200
/old – 404
/pages – 200
/source – 301 Redirects to /test directory
/scripts – 200
/test – 200
By manually fuzzing the application the tester found the /admin, /source and /test directories. Had the tester not fuzzed the website these directories would have been missed. Although the /admin directory requires authorization to access the tester now knows to spend some time trying access this area of the application. Finding the /source and /test directories, the tester chances of finding information about the security of the application increases.
Although in the above example the tester was able to find 2 “private” directories with just 6 guesses in the real world the tester would typically try thousands of directories to increase the probability of finding “private” directories. Of course, no tester wants to do thousands of manual requests to a website, so a fuzzing tool should be used to fuzz the directory structure.
With an understanding of what fuzzing is and how it works next time I will discuss a tool that I use to perform web application fuzzing. Of course like any tool there are lots of them out there is this tool is my personal preference.
No comments:
Post a Comment