Effectively Scoping Application Security Penetration Testing and Ethical Hacking

Effectively Scoping Application Security Penetration Testing and Ethical Hacking

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

Categories: Application

About Author

Write a Comment

Your e-mail address will not be published.
Required fields are marked*