Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

Pen Testing Methods, Prep and Reporting Cheat Sheet (DRAFT) by

This is a draft cheat sheet. It is a work in progress and is not finished yet.

White Box Penetr­ation Testing

Testers are provided with inform­ation in advance including target URLs, applic­ation functi­onality summary, applic­ation map and test accounts.
Target system personnel are available to answer questions.
This type of testing is an integral part of the develo­pment process and as a result it is often performed by an internal team.

Rules of Engagement

Identi­fying tester traffic and data
Target system personnel should be know source identi­fiers such as IP addresses, email addresses, and other identi­fiers.
Agreeing upon a testing time frame
This includes testing windows and time for analysis, reporting and follow-up. The delive­rables should be scheduled prior to testing.
Establ­ishing commun­ica­tions plans
There should be various contacts both technical and manage­ment, as well as methods including email, phone, and possibly IM. Sensitive inform­ation regarding vulner­abi­lities should be discussed over secured channels with PGP/GnuPG for email or OTR/en­crypted IM.

Inform­ation Required for Testing

Applic­ations included in the scope
Multiple user IDs and passwords, each pair having different access.
Technology restri­ctions such as client types, ports and servers to avoid
Emergency contact inform­ation.

Establ­ishing the Test Scope

The scope is defined by the purpose of the test. What are the concerns associated witht he target applic­ation.
The type of of test should be agreed upon black, crystal or grey box testing.
The scope of the test will define which applic­ations and/or servers are involved and which should be avoided.

Managing a Web App Pen Test

Begins BEFORE the hands-on testing, involves the testing team and the target system personnel.
Developers can be brought in to help improve security awareness.
Any vendors or infras­tru­cture providers should be included.

Prepar­ation

It is the first step, and is contin­uous.
Practicing and developing skills is paramount.

Hybrid Web App Penetr­ation Testing

Combines manual and automated techni­ques.
Scanner provide a starting point with manual verifi­cation and exploi­tation as follow-up.
As new components of an applic­ation are discovered the process returns to automated scanning, repeating the cycle.
Scripting is done as needed.
This is the most frequently used technique for testing.

Automated Testing

Automated tools are used to scan a target for vulner­abi­lities.
Many automated scanners are available including HP WebIns­pect, Trustwave App Scanner, IBM AppScan, ZAP, Burp Suite.
Rapidly scans site but can still take a long time.
Tester has less control and it is more prone to false positives.
Lacks the ability to provide business implic­ations to discovered flaws.

Manual Testing

Manual testing using scripts and tools
The tester processes each page of the target applic­ation using tools and script to help manipulate and formulate requests as well as gather and analyze data.
It is time consuming but allows for the discovery of logic and business flaws that tools cannot find.
Thorou­ghness is dependent on the tester's time, attention and skill set.

Grey Box Testing

Testers are provided with some inform­ation at the beginning of testing including URLs and user accounts.
Inform­ation gathering is a critical part of this type of testing.
Commun­ication between the tester and target system personnel is critical.
This is the most common type of testing performed today.

Black Box

Little or no inform­ation provided to tester other than the name of the target, an IP range or applicable URLs.
The target is a "­black box".
This type of testing requires close coordi­nation between testers and target system personnel to ensure that the testing stays within scope.
This type of testing is not typically done in web applic­ation testing.
 

Reporting

Probably the most important part of the penetr­ation test, since it is the most lasting portion.
Format:
1. Executive Summary
2. Introd­uction
3. Method­ology
4. Findings
5. Conclu­sions
All inform­ation gathered during testing becomes part of reporting, important notes, permis­sions, memos and other items may be included in the append­ices.

Executive Summary

Contains a high-level overview of our test and findings
The audience is higher­-level personnel.
Maximum 1.5 pages, best kept to a single page.
Contains the findings, including the root cause, and recomm­end­ations, which should be reasonable and accomp­lis­hable. Including recomm­ended time frames including short-term versus long-term changes.

Introd­uction

Outlines the parts of the test including the scope, objective and the team.
This section should be 1-2 pages in length.

Method­ology

A step-b­y-step explan­ation of testing including tools used.
It should be clear enough that a competent tester could reproduce and verify the test.
This section is often 3-10 pages in length.

Findings

This is the meat of the report including each finding catego­rized by risk as pertaining to the applic­ation.
In some cases findings will be divided by applic­ation.
Recomm­end­ations are part of the findings. If there are multiple, each should be provided with an explan­ation of the most benefi­cial.

Conclu­sions

This is the final part of the report and is similar to the executive summary.
The audience is the techni­cians, unlike the executive summary which is geared to higher­-level.
Any appendices are added after the conclusion including
permission memos
lists of users harvested
records retrieved from the database
detailed tool output

Presen­tation

An optional part of penetr­ation tests but an excellent way to work with develo­pers.
Audience should be chosen by target personnel, possibly hold multiple sessions to focus the presen­tation on different kinds of staff such as develo­pers, admini­str­ators, management and testing staff.