Application Security Testing

The most common attack against online services is against weaknesses in the application code. Protect your systems against data theft and exposure.

The testing described in my System/Network Health Check service concentrates primarily on exposed services, network infrastructure, software versions and patch levels. The greatest risk, however, to any application’s security is the application code itself. Unless securely written, your information can be exposed to a variety of risks, as illustrated in a number of high-profile media reports relating to financial and other online services.

The risk is particularly high in the most common scenario: application development work has been outsourced to an external party or an in-house team, and a highly functional and complex application has been delivered, installed and tested at a functional level, and is then exposed to the Internet or other untrusted network.

Application Security Services

My in-depth knowledge of application-level security allows tests of the following kinds (amongst others) to be undertaken:

  • Information Gathering: review site structure and determine whether unnecessary (or sensitive) information is exposed;
  • Authentication: attempt to bypass or exploit authentication mechanisms to gain unauthorised access to privileged areas or to the system itself;
  • Encryption: attempt to bypass encryption where it is relied upon for any purpose;
  • Session Handling: investigate whether session-handling mechanisms can be exploited to hijack another user’s session or conduct replay attacks;
  • Cross-Site Scripting: investigate whether user input is sufficiently validated to prevent insertion of malicious code;
  • SQL Injection: investigate whether user input is sufficiently validated to prevent unauthorised database manipulation; and
  • Error Engineering: investigate whether errors produced by the application software or underlying system expose sensitive information.

As for all our services, the exercise will complete with production of a report containing findings, assessment of potential impact and recommendations, in a format that you can actually use.

The precise tests that will be performed cannot easily be predicted in advance, as such testing is a dynamic and reactive process – one finding may lead to another, and so application-level testing can only be undertaken manually.

Testing can take place as a ‘blind’ external attacker, or, where relevant, as an authenticated user. I always strongly recommend that a full backup is performed before testing commences, as application testing can result in changes to the data or supporting systems.

Remote Application Testing

Testing can be performed against any service exposed to the Internet, in particular those that accept input from the user. Normally, this will be a Web application, running over HTTP or HTTPS (SSL), but other, more unusual, forms of application-level testing can be performed (such as interactive Telnet-driven software or direct access to SQL databases).

As far as possible, this level of testing will identify exploitable flaws in application coding, configuration and implementation.  Whilst not as exhaustive as a full code review (please refer to the next section), it will identify those aspects of an Internet-facing application that may present a risk to:

  • Confidentiality of private or sensitive information held in protected areas or back-end systems;
  • Integrity of information, whether public or private; or
  • Availability of service and/or information repositories.

Any application-level testing can be performed as an unauthenticated external attacker or authenticated user. The extent to which each group is deemed a risk will be dependent on the type of information available and the criticality of the service’s Integrity and Availability.

The final report will, as far as possible, frame the potential impact of any identified flaws within the appropriate context. For example:

  • An unauthenticated user accessing pages outside the navigation structure may not be deemed a major risk; or
  • An authenticated user injecting malicious script may not be deemed a risk if audit and accountability levels or moderation workflow processes are reasonable.

Application Code Review

This form of testing involves manually reviewing the source code of an application, and seeks to identify:

  • Flaws in input validation;
  • Flaws in authentication processes;
  • Flaws in session management;
  • Etc.

Testing of this nature may not identify problems in implementation or configuration within the live hosted environment – for example:

  • Server-level authentication processes cannot always be assessed from a review of code;
  • Exposure of source code through server misconfiguration will not be highlighted.

The advantage of a code review, however, is that potential issues can be identified that may not be highlighted during a ‘blind’ remote analysis.

A code review can be undertaken on any application code with a security function, such as ensuring users are authenticated, input is validated or sensitive data is filtered before publication. The assets such code may be protecting might include private data (perhaps including credit card details), authentication information, system administrative functions, or even the system itself.

An application code review will seek to highlight flawed functions such as:

  • User input validation is not sufficient to prevent injection attacks, overflow attempts or Denials of Service;
  • Authentication processes are not strong enough to prevent bypass or enforce, for example, password complexity requirements;
  • Session management is not robust enough to prevent session hijacking or replay attacks;
  • Etc.

Whilst attackers will not generally have access to application source code, and so a code review may not be an accurate representation of any perceived attack scenario, it can act as an effective preventative measure, highlighting potential areas of risk that may not be obvious during remote testing.

Application code reviews can be undertaken in two ways:

  1. Focused Manual Review – this first level of application testing will focus purely on identified routines (e.g. input/output routines, where input is accepted from an authenticated or unknown user, and subsequently used to perform, for example, database operations). It will also examine any output presented to the user based on that input. It will not address session handling or authentication processes, since such reviews will generally require examination of most of an application’s code.
  2. Full Manual Review – a full review will involve detailed examination of all application source code.

Due to the nature of application testing, I provide per-task quotations on request, once I have an understanding of the scope and complexity of the application that needs to be tested. Contact me to discuss your specific requirements.

Related Pages

Contact me now to discuss your consultancy needs
"I would have no hesitation in recommending Peter for work on any Government IT programme requiring accreditation. He was knowledgeable on all aspects of Information Assurance." — Pan Government Accreditor

Register • Log InHelpContact