Web Application Penetration Testing

Web Application Penetration Testing

Introduction

Web applications make services available to customers and company employees and offer convenience. Unfortunately, they can also provide the same advantages to unauthorised adversaries and quite often, can expose more than just that. A web application penetration test is usually aimed at identifying security issues that allow known functionality to be abused and also identify unintentional features that may cause issues.

What do we cover?

We have tested various types of web applications including:

  • Online banking websites
  • Payment gateways (see our PCI DSS service)
  • Online gaming and gambling sites
  • Web portals
  • Extranet and Intranet applications
  • Websites based on third-party code (e.g WordPress or SharePoint)
  • Online shopping applications
  • Software as a Service (SaaS) and similar

Which methodology is used?

We cover the OWASP Top 10 which includes the following:

  • A1 Injection
  • A2 Broken Authentication and Session Management
  • A3 Cross-Site Scripting (XSS)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration
  • A6 Sensitive Data Exposure
  • A7 Missing Function Level Access Control
  • A8 Cross-Site Request Forgery (CSRF)
  • A9 Using Components with Known Vulnerabilities
  • A10 Unvalidated Redirects and Forwards

However, we do not limit ourselves to any list and instead adapt our testing to the target web application. This means that, where appropriate, we will test for, identify and simulate abuse of vulnerabilities that may not fall under the umbrella of the OWASP Top 10 but still affect your web application. For example, we have performed research into:

  • The interaction between applications that require payment and third-party payment gateways, to identify vulnerabilities that allow spoofing of payments
  • Hidden files on the web server leading to disclosure of sensitive data such as credit card details
  • Abuse of application-framework-specific functionality in Liferay and Cometd
  • Remote code execution vulnerabilities in PHP and Ruby on Rails applications

How does the process look like?

Most of our engagements follow these steps:

  1. First step is that you contact us
  2. We ask you a number of questions to understand what you have in mind, the goals for the exercise and the scope
  3. We perform a scoping exercise to better understand the size of the project; in the case of a web application test, the scoping exercise often involves going through the target applications to better understand the exposure and therefore tailor our proposed work to your needs
  4. We verify our scope with you where appropriate
  5. We work on a proposal which describes the goals, the scope, the methodology, deliverables, dates allocated for the project, terms and conditions and the price
  6. The actual work takes place during the allocated dates; your IT staff involved in the project often need to be available during the tests
  7. Upon completing the tests, we work on the reports and often provide a brief report of the main findings so that your staff are informed of the results immediately
  8. The deliverables are provided to you
  9. Often the process also includes testing of the security fixes once applied

What are the deliverables?

At the end of the project, the client usually receives the following:

  • Executive report, which is an easy to follow 4 page report that includes information about the penetration test, list of the findings and a short explanation of the security fixes or mitigation techniques
  • Technical report, which includes the following sections:
    • Introduction, which describes the scope, methodology and purpose of the work
    • Methodology, which describes our tests to explain what was covered and how; this would include both tests that led to vulnerability discoveries, and also those that did not
    • Findings and recommendations which are categorised as High security threats, Other security threats and Other concerns and recommendations
    • Each finding that is considered a security threat includes:
      • A description of the security issue as it affects the target system
      • Our assessment of the impact of the vulnerability
      • Details on how to reproduce the issue found
      • Solutions and recommendations, which are tailored for the target audience and can go into quite some detail
  • Other material is sometimes provided such as:
    • Video demonstrations showing exploitation of your applications
    • Dedicated exploit code to reproduce the security issues found
    • When the tests are done on-site, we often brief the involved executives and/or technical team and discuss solutions to the security issues found
    • Similarly, conference calls can be used when the work is done remotely

What costs can one expect?

Cost is dependent on the size and complexity of the system on test and the level of rigor in which testing is to be performed. This is determined through pre-sale client discussions and scoping questionnaires. The price of an engagement will be delivered as a fixed bid quote.

Get in touch