One question we’re consistently asked is, “What exactly is a web application penetration test?” Some companies will run a vulnerability scanner against your application and call that a penetration test. But that’s where NuHarbor‘s different. While we do leverage advanced tooling, our human engineers use a mix of automatic and manual testing procedures to catch items that a scanner can’t see.
We’ve broken down the engagement process into five stages:
- Reconnaissance
- Mapping
- Discovery
- Exploitation
- Reporting
Below is a definition of each stage and the type of work each involves.
Reconnaissance
This is the information collection process of the engagement. Some of the information is collected as part of the statement of work process and some is found using internet sources. We collect the following types of information from the client:
- A brief overview of the application and what is does
- What URL(s) can the application be found on?
- What types of roles does the application have?
Prior to the start of the engagement, we verify any credentials provided and leverage various scanning engines that are available on the internet to determine the following types of information:
- What server-side technologies (e.g., Java, PHP, Asp.NET, etc.) may be in play with this application?
- What client-side technologies (e.g., jQuery, AngularJS, etc.) may be in play with this application?
- What development paradigms (e.g., MVC, client side, SPA, etc.) are potentially in use?
With this information, we can build a framework to properly complete the remaining four phases once the engagement starts.
Mapping
On day one of the engagement we verify the information obtained during reconnaissance and begin the mapping phase. This is where we learn the application from an end-user’s perspective. NuHarbor engineers will visit every page of the application and interact with all functionality on each page. This is done per user role under testing. Our engineers will interact with the application in ways that a scanner cannot, such as looking for different functionality that occurs when your mouse hovers over an object or dragging and dropping items in the application. We also look for sequential process flows (i.e., steps that must occur in a certain order) to use in later stages of the engagement.
At the completion of this stage, our engineers will have an understanding on how the application works and what services it provides.
Discovery
Once we’ve established the known footprint of the application, we begin to look for things that are intentionally (or unintentionally) hidden and areas of the application that are vulnerable. Based on the technologies discovered, our engineers will look for additional, well-known content, such as administrative web portals, login pages, or other content that isn’t linked directly from inside the web application.
The application will be reviewed for any default configuration items that may pose a risk, such as use of default credentials or exploitable libraries or plugins.
A review of the application’s authentication and session management will be performed. This will look for issues with how accounts are used in the application and if it’s possible to elevate privileges between different users.
All form fields, URL parameters, and other locations will be reviewed for injectable content. If injection is possible, we’ll determine if this is reflective (i.e., it’s not stored, and only shown to the current user) or persistent (i.e., it’s stored in the application and may impact multiple users).
A thorough review of the logic within the application will also be exercised to determine if there are vulnerabilities present. This is where we test the application flows discovered in the mapping phase. Areas where files may be uploaded and/or interacted with will be tested to see if malicious content can be provided.
Any encryption mechanisms used as part of session management or user authentication are reviewed to ensure best practices are being adhered to.
Lastly, the application is reviewed for any misconfigured security items or unnecessary disclosures. This includes a review of all server headers that are sent to determine if they’re necessary, what elements of the application are stored within the web browser’s cache, and how data is passed throughout the application.
Once the mapping and discovery phases are complete, our engineers move on to the final stage, exploitation, to determine what can be done with what has been found.
Exploitation
In the exploitation phase, we determine what can be done based on the information gathered as part of our prior steps. If any vulnerable third-party plugins or libraries are in play, we’ll execute any known vulnerabilities against them to determine if the application is affected. If SQL or command injection was possible, our engineers will work to determine the scope of the exposure. Meaning, is it possible to compromise the entire server or the data within the application? If file interaction is possible, is it possible to upload malicious content to compromise the server?
When all discovered potential exploits are tested, the engagement moves into the last phase: reporting.
Reporting
This is the most beneficial stage of the engagement to our customers. All items discovered are rated against a defined risk classification scale to determine severity. Each item is then reviewed in detail, which includes the following information:
- The risk classification of the item
- The impact and/or description of what was found
- The requirements needed to exploit the finding
- A complete set of reproduction steps
- A recommendation on how to best address the finding
Lastly, evidence, where applicable, is provided of the successful exploitation or finding.
Web Application Penetration Test FAQs
How often should I have a web application penetration test?
We recommend having your web application tested at least once a year or after every major release. Major releases often change out libraries or introduce new workflows/functionality to the application, which should be tested.
Which environment should we have our application tested in?
We recommend testing to be conducted in the environment that is closest to production without actually being the production environment. Typically, we leverage a staging or user acceptance testing (UAT) environment prior to the code being released to production. If you don’t have one of these types of environments, during the scoping process we’ll work with you to determine how to best test without impacting your production environment.
I’ve had an application vulnerability scan and/or source code review – isn’t that sufficient?
While these are great exercises, there are simply things that a scanner or review cannot catch. Items such as logic flaws or privilege escalation are things that require knowledge of how the application and its framework operate. These are best caught through manual testing by highly skilled and experienced engineers .
Does it matter which browser my application is certified in?
This is a great question to bring up during the scoping of the engagement. If your application depends on a certain browser or technology, we simply need to know what those are to ensure we’re testing the application under the conditions it will be used.
I purchased my application – shouldn’t it be secure?
Verifying the software vendor has performed security testing is a great thing to check, but there are items out of the vendor’s control. If the software has been customized or is running on servers not owned by the vendor, it’s a good idea to have these applications tested to ensure no vulnerabilities have been added inadvertently.
