I perform both Web application and infrastructure penetration testing and help you address the root causes of any identified weaknesses in accordance with risk and good practice.
All penetration testing engagements include the following:
Free consultancy to identify the appropriate scope and type of testing,
Detailed report documenting identified issues and recommendations on how to address them in accordance with risk and good practice,
A free retest of identified issues once they have been addressed,
A Certificate of Penetration Testing for third-party assurance purposes (provided no significant issues have been identified or all such issues have been addressed and retested).
Penetration testing gives you the assurance that all the hard work you have invested in designing and implementing secure infrastructure or applications has paid off and that your product or service won’t fall apart when subjected to malicious activity.
My fees for penetration testing range from £1,000+VAT for small engagements to £10,000+VAT for large and complex applications or infrastructure. All engagements are fixed-fee to provide predictability and easy budgeting.
Web Application Penetration Testing
Web application penetration testing, also known as web app pen testing, is a type of security testing that focuses on identifying vulnerabilities and weaknesses in web applications. The goal of web application penetration testing is to identify vulnerabilities that could be exploited by attackers to gain unauthorised access to sensitive data, inject malicious code, or disrupt the normal functioning of the application.
Penetration testing of Web applications involves the identification of security weaknesses and vulnerabilities caused by insecure coding practices, misconfiguration and bugs. It is usually performed on a test instance of the application but can also be performed on live instances if required.
The penetration testing process involves generating specially crafted malicious or invalid HTTP requests to identify and exploit vulnerabilities that may exist in the application, such as weaknesses identified by industry-standard sources such as OWASP Top 10 Web Application Security Risks.
API Penetration Testing
More and more applications depend on publicly accessible Application Programming Interfaces (APIs) to provide their core functionality as well as to integrate with and/or extend other applications and data sources. With all the versatility and features of APIs come potential security weaknesses and vulnerabilities, some of which can be critical, and many of which can be identified and addressed through penetration testing. However, effective penetration testing of APIs requires complete, up to date and accurate API specification and documentation which would allow a penetration tester to generate valid API requests which then can be used to effectively penetration test the API and its endpoint(s) by generating malicious variations of the original valid request. It is therefore important to ensure that whoever is penetration testing an API needs to be able to generate valid API requests before it can be tested. Having an accurate and complete API specification in the right format is key.
To obtain the best results from a penetration test of an API the API specification should meet the following good practice requirements:
The API specification must be in a standard format such as OpenAPI and machine-readable notation such as JSON or YAML
The API specification must be complete, i.e. should not be missing any required methods / parameters / headers / etc
The API specification must be accurate, i.e. it should match the actually deployed services accessible on the relevant endpoint(s)
The API specification must not contain unnecessary, extraneous or unused methods / parameters / headers
The API specification must correctly specify relevant endpoint URL(s) and specify secure transport ('https://')
The API specification must specify authentication / authorisation requirements clearly and unambiguously and specify how any relevant tokens or credentials can be obtained
The API specification must specify all required and optional parameters, indicating them as such, and the format in which they must be specified (e.g. 'date': 'DD-MM-YYYY' or 'DDMMYY'?)
If there is more than one version of the API the specification must indicate the version of the API and the correct endpoint(s) for that version
A number of tools exist which can be used to create, edit, validate and share API specifications, such as:
When you have a complete and accurate API specification use an appropriate tool, such as OpenAPI Validator or Swagger Inspector above, to validate it. If the tools identify any issues with the specification they must be addressed before penetration testing. Once the API specification has been validated, share it with the penetration tester alongside a set of sample/test credentials and values for all parameters that cannot be obtained from the API itself.
Infrastructure Penetration Testing
Infrastructure penetration testing is a generic term covering testing of operating systems, network services, network devices and other targets. Its objective is to identify vulnerabilities and misconfigurations that can be exploited to obtain unauthorised access to data, systems or hosted applications. Specific testing activities and methodologies may differ depending on the scope and objectives of the infrastructure testing engagement but most engagements involve the following stages:
1. Identification and enumeration of targets of testing
2. Reconnaissance and information gathering
3. Identification of vulnerabilities, weaknesses or misconfiguration
4. Testing and exploitation of identified vulnerabilities, if applicable
5. Post-exploitation activities, if applicable
6. Reporting and recommendations to address the identified issues
All of the above is performed in strict conformance with the client requirements taking into account the scope and the objectives of testing as well as any applicable technical, legal or organisational restrictions.
Understanding your options
When it comes to commissioning a penetration test you will need to decide whether you require a black, grey or white box penetration test. The type of testing chosen will decide the amount of time and effort required as well as the level of security assurance obtained.
Black box testing is the usual type of testing – it gives basic assurance that is usually sufficient in most cases. White box testing provides the maximum possible assurance as it involves additional testing activities including review of design, architecture and source code, while grey box testing is midway between the black and white box testing in terms of assurance.
The type of testing chosen determines how much time and effort is required and the extent of your own team’s involvement in the testing process: whereas with black box testing your team’s involvement is limited to provision of a test instance of your application or specification of infrastructure to be tested, with grey or white box testing documentation, meetings and access to source code would have to be arranged. The time required to test particular application or infrastructure depends on its size and complexity, as well as the type of testing. Most penetration testing engagements are black box tests and usually take about a week to complete.