One key element many organisations overlook when commissioning any form of security testing is the importance of an effective scoping process.
This blog from senior security consultant Jed Kafetz runs through the key information Redscan requires to scope, plan and price a web application penetration test to ensure it delivers the best outcomes and value for money.
When reaching out to us for a quotation, providing the most complete and accurate information possible will not only guarantee a quick turnaround time, but will also ensure that we are not under or over scoping the engagement.
Our most important goals are to ensure that our clients get the most value from their investment in a pen test, and that the test provides sufficient coverage.
What information do we need to scope a web app pen test?
There are a few key bits of information we need to accurately scope a web app test:
- The type of application
- A brief overview of the key functionality
- The number of user roles
- If the app uses a REST API backend, the number of API endpoints
- Screenshots
Type
Firstly, we need to understand what kind of web application we are testing. Web apps fall into two categories:
• Single-paged application (SPA)
• Multi-paged application (MPA)
A single-page application (SPA) is a modern type of web application that interacts with the web browser by dynamically rewriting the current web page with new data from the web server, typically obtained through a REST API. This is instead of the default method of the browser loading entire new pages. Web applications which make use of modern JavaScript frameworks such as Vue, React, and Angular are all considered single page applications. Examples of such apps are Gmail and Trello.
A multi-page application (MPA) is the traditional type of web application. These applications reload the entire page and display the new one when a user interacts with the web app. Examples of such apps are eBay and Amazon.
Let’s consider the example of searching for an item. In a SPA, when a user types a search term and clicks search, the application will likely send a request to the Search API endpoint (e.g /API/search) and receive only the results in JSON format, which will be used to update the relevant portions of the web page.
In an MPA, when a user types a search term and clicks search, this request is sent to the server, which will perform the query, render the results in a new page, and return that entire page in a response to the browser. The browser will then load this new page containing the search results.
Functionality
Next, we need a list of the key dynamic functionality that makes up your application. A brief list of the functionality is fine. For example, a very simple ecommerce site may contain:
• Admin User management – create/edit user
• User profile management – update details
• Listings – create/edit/search listings
• Cart – add/remove/update/initiate checkout
• Checkout – submit details, choose payment method, initiate payment, complete payment
We are only really concerned with dynamic functionality as this is complex and takes time to test, as opposed to static functionality such as a page displaying terms and conditions.
User roles
Next, we need to know the number of user roles in the application. Following the same example as above, the ecommerce site may have an administrator user and a regular user. This information is important because different user roles often have access to different functionality, so we test from the perspective of all user roles to ensure complete coverage. Additionally, we will test for any sort of implementation flaws allowing for privilege escalation.
API endpoints
Finally, if the app in question is an SPA and utilises a REST API backend, it is important for us to know how many API endpoints are used. This helps us gauge the overall size of the application and allows us to accurately estimate the number of days required for testing. It would be ideal if you can provide API documentation (such as a swagger file or postman collection).
Screenshots
Along with the above information, a few screenshots highlighting key functionality of the application are helpful to understand and scope the engagement accurately, without needing an in-depth demo or walkthrough.
Why choose Redscan?
If you’re looking to have a web application security tested, Redscan are well placed to assist. Our CREST penetration testing team, including Certified Web Application Testers (CCT APP), are hugely experienced at performing web application security testing and can help your organisation to identify and remediate a wide range of vulnerabilities, from misconfigurations and authentication weaknesses to session management and database interaction flaws.
