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 internal report with my findings and recommendations, as well as a 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 defined by the industry-standard sources such as OWASP Top 10 Web Application Security Risks:
1. Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
2. Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
3. Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
4. XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
5. Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
6. Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
8. Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
9. Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
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
5. Post-exploitation activities
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.