Penetration Testing

Penetration testing is a method of evaluating the security of a computer system or network by simulating an attack by malicious actors

I perform both Web application and infrastructure penetration testing and my integrated approach means I don’t just give you a list of problems but help you solve them and address their root causes now and in the future. Penetration testing of Internet-facing applications and infrastructure is an essential necessity for any business. 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 your product or service won’t fall apart when subjected to malicious activity.

Traditional penetration testing concludes with the delivery of a report at the end of the penetration test. It lists identified issues and makes recommendations and you are left to address the issues. No wonder many organisations find it difficult to actually improve security of their IT by conducting penetration tests alone - it takes much more to consistently operate secure services or release secure applications than just a penetration test. After I issue the penetration test report we can work with your technical team to address both the specific security issues as well as their root causes.

Following the conclusion of the penetration testing engagement I issue a detailed report with my findings and recommendations, as well as a digitally signed certificate of testing that can be shared with third parties such as customers, investors or regulators - provided no significant or material security issues were identified or all such issues were fully addressed and re-tested.

Web Application Penetration Testing

Penetration testing of Web applications involves 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 in certain cases.

The penetration testing process involves intercepting, analysing, modifying and generating specially crafted malicious and/or invalid HTTP requests to identify and exploit vulnerabilities that may exist in the application, such as the ones identified by the industry-standard sources such as OWASP Top 10 (2021) Web Application Security Risks:

  • A01 Broken Access Control

  • A02 Cryptographic Failures

  • A03 Injection

  • A04 Insecure Design

  • A05 Security Misconfiguration

  • A06 Vulnerable and Outdated Components

  • A07 Identification and Authentication Failures

  • A08 Software and Data Integrity Failures

  • A09 Security Logging and Monitoring Failures

  • A10 Server Side Request Forgery

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.