Web Application Enumeration
The enumeration phase is the first (and arguably most important) phase of any test because it is very difficult to perform the rest of the test in depth without a good understanding of the larger context, i.e. the better this first phase is, the more test possibilities you have to perform and, as a result, the more flaws to be discovered, so it is crucial to know how to perform a good reconnaissance.
Identifying the technologies utilized in a web application, as well as obtaining as much information as possible about the application’s structure, is the goal of reconnoiter a web application.
Take notes on everything you find about how the application works, so you’ll always have something to turn to if you run out of ideas, and you won’t get lost and end up testing the same things or skipping steps in your approach.
Important note: This article is not intended to be a checklist or a step-by-step guide to doing a reconnaissance, but rather to provide a list of strategies, recommendations, and tools that can aid in the process of obtaining information for use during a web application test.
Source code
While this is obvious (hit f12 and select the elements tab), it can provide useful information in some scenarios, such as links to JavaScript files or URLs that may hold important data. When looking at the source code, you may come across important information in the developers’ comments.
NMAP
To avoid going into too much detail, I’ll assume you’re familiar with NMAP and some of its features. I’d just like to point out that it’s useful for more than just discovering open ports on a host; in the case of web applications, it can also show you some information about the web server (such as the service version) and show you some files or directories on the site.
for example:
nmap -sCV -p 80,443,8080 example.com
I used the -sC option in this example, which runs the standard nmap scripts, but you may look at the list of scripts and utilize them as needed to discover more about the application.
Bruteforce files and directories
Often, applications have files and directories that are not visible but can be accessed via the URL; the most popular technique to find these files and directories is to use a fuzzing tool; these tools will take a list of common file names and test if they exist on the server. This may lead to the discovery of more application functions, configuration files, API endpoints, and so on. ffuf, feroxbuster, gobuster, and wfuzz are some of the most popular tools for this. The most famous wordlists for this purpose are from the SecLists repository, which has wordlists for specific contexts.
ffuf -u http://example.com/FUZZ -w /path/to/wordlist.txt
Web technologies in use
As said before, it is crucial to know which technologies the application being tested employs. There are tools like whatweb, wappalyzer, webtech, and builtwith that can help with this. We have wafw00f to see if the application has a WAF (Web Application Firewall).
whatweb -a 3 http://example.com
wafw00f -a http://example.com
Vulnerability Scans
Vulnerability scans are greatly useful for running more generic tests as well as when testing a large number of websites. Zaproxy, burpsuite, and nuclei are some of the most commonly used scans. burpsuite and zaproxy are web application analysis programs with many tools; among these tools, these two programs have their own vulnerability scan. Nuclei works via command line and uses templates, allowing anyone to create a template, that is, an automation for testing a vulnerability, which keeps the tool constantly updated, making it extremely useful.
nuclei -u http://example.com
CMS Scans
CMS stands for “Content Management System,” which refers to the technologies that are commonly used to develop websites, such as wordpress or fuelCMS. These could have known vulnerabilities associated with their version, improper configuration, or installed extension/plugin or theme. This is where CMS Scans come in; once you’ve identified which CMS is being used in the application, you can run a specific vulnerability scan for that CMS, such as wpscan, to hunt for these previously documented vulnerabilities. Clusterd, CMSScan, VulnX, droopescan, joomlavs, wpscan, cmsmap are some CMS scanning tools.
./clusterd.py [options]
vulnx -u http://example.com
droopescan scan drupal -u http://example.org/
ruby joomlavs.rb -u examplejoomla.com --scan-all
wpscan --url http://examplewordpress.com/ -e u,ap,at
cmsmap.py https://example.comManual Tests
When performing manual testing in the application, keep an eye out for information that can be valuable, such as a username. Using a proxy to log the requests and using the site resources as a regular user to evaluate them can also guide you down the right road. Attempting to find information by accessing files such as robots.txt, sitemap.xml, and.well-known is also worth testing manually, as is forcing the application to respond to errors, which may contain useful information in and of themselves. To force these errors, try accessing a page that does not exist, add characters like “[]” to the cookie, or try different request methods.The tools already mentioned, such as burpsuite or zaproxy, are also used for these manual testing because they allow for request analysis as well as having other features that can assist in the more manual tests.
Final thoughts
In this article, I covered some fundamentals of web application enumeration, which may be handy in the early stages of testing but may prove to be critical later on. One final note: apply the information from this post to your specific situation.
