By: Eric Kobelski, Security Engineer
One question that we get consistently is “What exactly is a web application penetration test?”. There are some companies that will run a vulnerability scanner against your application and call that a penetration test, but this is where NuHarbor Security is different. While we do leverage tooling, our engineers have a mix of automatic and manual testing procedures to catch items that a scanner is not able to see. To help describe this concept, we’ve broken down the engagement process into five stages: Reconnaissance, Mapping, Discovery, Exploitation, and Reporting.
Below is a definition of each stage and the type of work we do in each.
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 of this information is found using sources on the Internet. We collect the following types of things from the client:
- A brief overview of the application and what is does
- What URL (or 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 provided credentials and leverage various scanning engines that are available on the Internet to determine the following types of information:
- What server-side technologies (Java, PHP, Asp.NET, etc.) may be in play with this application?
- What client-side technologies (jQuery, AngularJS, etc.) may be in play with this application?
- What development paradigms (MVC, client side, SPA, etc.) are potentially in use?
With those pieces of information, we can build a framework to properly complete the remaining four phases, once the engagement starts.
Starting on the first day of the engagement we verify the information that was obtained as part of reconnaissance and begin the mapping phase. In a single sentence, 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 the functionality on the page. This is done per user role that is currently under test. Our engineers will interact with the application in ways that a scanner cannot do, such as looking for different functionality that occurs when your mouse over an object or drag and drop items in the application. We also look for sequential process flows (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.
Once we have 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 is not linked directly from inside the web application.
The application will be reviewed for any default configuration items that may pose a risk such as the use of default credentials or if there are any exploitable libraries or plugins present.
A review of the application’s authentication and session management will be done. This will look for issues with how accounts are used in the application and if its 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 will determine if this is reflective (meaning it’s not stored, only shown to the current user) or is persisted (meaning it is 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 as part of 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 that are 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 would include a review of all server headers that are sent to determine if they are 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 onto the final stage, exploitation, to determine what can be done with what has been found.
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 will execute any known vulnerabilities against them to determine if the application is affected by these. If SQL or command injection was possible, our engineers will work to determine what is 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 the discovered potential exploits are tested, the engagement moves onto the last phase, which is reporting.
This is the most beneficial state of the engagement to our customers. All items discovered are rated against a defined risk classification scale to determine the severity of the item. 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.
Common questions regarding a Web Application Penetration Test
How often should I have a Web Application Penetration Test?
We would 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 the testing be conducted in the environment that is closest to production without it actually being the production environment. Typically, we leverage a staging or UAT (User Acceptance Testing) environment prior to the code being released to production. If you do not have one of these types of environments, during the scoping process we can 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 a great thing to do, there are 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) work. These are best caught by manual testing by engineers with experience in this realm.
Does it matter which browser my application is certified in?
This is a great question to discuss during the scoping of the engagement. If your application depends on a certain browser or technology, we just need to know what those are to ensure we are testing the application under the conditions it will be used.
I purchased my application; shouldn’t it be secure?
Verifying the software vendor has had some security testing is a great thing check, but there are items out of the control of the vendor. If the software has been customized or is running on servers not owned by the vendor, it is a good idea to have these applications tested to ensure no vulnerabilities have accidentally been inadvertently added.