When scoping an application security penetration test, Or thus suggest that you remember the following:

The principal focus of the testing should on the application under test. This means that the vulnerability of the surrounding environment is not under test, nor are for example Internet facing firewalls, except in their relationship to the application. Therefore it would be appropriate for the Vendor to confirm that the firewalls are configured correctly for this application and that no unnecessary ports are allowed through. Conversely, the vendor should be instructed not to test your firewalls beyond this.

The test should include a paper review of the architectural design, before beginning testing. The review should validate the physical placement of the various network components servers, and identify potential issues or security weaknesses.

It should be left to the vendor to use their judgment as to which particular tests are relevant to a particular application. There are two exceptions to this.

If it can be seen that the vendors proposed testing is not comprehensive enough, then the project should insist on extending the scope to include additional areas of testing.

  If in the opinion of the project, the tests proposed would have a undesirable effect on production infrastructure or applications. In this case steps must be taken to achieve the same testing via an alternative manner. For example, this may involve the use of application disaster recovery equipment.

While its difficult to specifically prescribe which tests are appropriate for any generic set of applications, in principal you should consider the following where applicable:

Password cracking scan of password files on servers.

  An on-box scan for security vulnerabilities.

  An examination of client-side application for information that reveals information about how the application functions that could be used for a more focused attack.

  Examination of client-side code and locally stored information such as cookies and session information. This should include alterations to such information in an attempt to:

- subvert authentication checking - establish the bounds of server reliance on client data fields - test for other unexpected results and potentially access confidential information.

Bounds checking and application validation for both accidental and mischievous input. The test should ensure that applications correctly respond to unexpected data formats or sizes.

  Potential for buffer overflows.

  Examination of application-to-application interaction between resources such as the web service and back-end data feeds. Attempts are made to access application resources by impersonating other system functions or sources.

  An examination of application-level traffic passing between various host systems for passwords, CGI parameters, and other data that might be reused as part of an exploitation attempt.

  Conduct authenticated user testing to see if they can abuse the system as a "customer".

  Attempted permission escalation by, for example, referencing application components with higher server-side permissions, or exploitation of race conditions to identify lax permission or authentication checking.

  Susceptibility of the application to replay attack and man in the middle attacks.

  Other session orientated attacks, including an analysis of system responses to such data.

  Susceptibility of the application to specially crafted packets delivered independently of the front end application checking.

  Investigation of robustness and resilience of application Authentication mechanisms.

  Software-specific manufacturer-recognised exploits

  Content sharing vulnerabilities

  Presence of deployment process vulnerabilities

  Presence of activation process vulnerabilities

  Request process vulnerabilities

  File and user permission vulnerabilities

  Cluster connectivity vulnerabilities

  Excess build and configuration weaknesses

  Application of applicable security patches, fixes and updates

  Legacy application code development weaknesses

  SQL injection weaknesses

  Cross-scripting vulnerabilities

  Potential to fraud the application

  Encryption and authentication vulnerabilities

  Defacement weaknesses

  Redirections vulnerabilities

  Administration rights & controls

  Sniffer attack vulnerabilities

Some applications may have a number of identical components in the architecture, e.g. a web-enabled application may have 4 web servers in parallel for loading reasons. In these cases, the project should ensure that the vendor is testing all instances of the components. Extending the web server example further, this would mean that each web servers operating system would need to be tested to ensure that any hardening processes undertaken had been completed on each of the servers.

This does not mean that each instance of the actual application code running on each web server is subjected to all tests. In other words it should be sufficient to conduct data validation tests against only 1 of the servers

It happens more often that one would think, but there have been many cases of penetration tests launching attacks against networks that were not authorised for testing. Therefore the project must ensure the vendor knows the limits that they are working under. It is worth asking the vendor what methods they use to limit unintentional damage to your network.

Lastly, the vendor should be reminded by the project that any information collected is to be treated in confidence, and that they must take appropriate steps to ensure any data retained by them is secured and destroyed securely when no longer required.