|(2 intermediate revisions by 2 users not shown)|
| || |
== 360 Reviews
- outside-in & inside-out == |+|
== 360 Reviews ==
The term 360
degree reivews some from coupling source code review and dynamic testing.<br> |+|
The term 360 source code review and in to
|−|Dynamic testing is in effect runtime penetration testing. It can also be ferered to as hybrid testing.<br> | |
| || |
|−|As mentioned in previous sections source code review can assess an application of issues which may otherwise be difficult to assess. <br> |+|
|−|Issues such as information leakage, logging of sensitive data, privacy and other items in relation to general good-health of an application may have significant impact in terms of regulatory compliance. <br> |+|
code review to ..testingtesting. a penetration testcan or in the applicationthe in and .
|−|Assessing the cryptographic controls is suited well for sourec code review but testing authentication functionality is easier to deliver via dynamic testing. <br> | |
|−|When perfroming a penetration test it is very valueable if one can map a discovered vulnerability or parameter to a class file or script in the application source code.<br> | |
|−|such mapping assists the developer in both understanding and addressing the issue. <br> | |
| || |
|−|'''Pen Testing Pros''' |+|
| || |
|−|*Requires less specialized expertise |+|
to the vulnerabilities
|−|*Easier setup | |
|−|*Easier to perform | |
|−|*Exercises the entire app infrastructure | |
|−|*Proves vulnerabilities | |
| || |
|−|'''Code Review Pros''' |+|
the used in the places of the the application.
|−|*Assess all the content | |
|−|*Discover all instances of certain types of flaws | |
|−|*Verify controls are correct (Positive Security) | |
|−|*Verify controls are used in all the required places (Positive Security | |
|−|Combining them together gives a better overall view of the security posture of the application. | |
Latest revision as of 01:44, 29 December 2013
The term 360 Review refers to an approach in which the results of a source code review are used to plan and execute a penetration test, and the results of the penetration test are, in turn, used to inform additional source code review:
A penetration test that uses a code review as input to planning is referred to as white box testing (also called clear box and glass box testing). This approach can lead to a more productive penetration test, since testing can be focussed on suspected or even known vulnerabilities. Using knowledge of the specific frameworks, libraries and languages used in the web application, the penetration test can concentrate on weaknesses known to exist in those frameworks, libraries and languages.
A white box penetration test can also be used to establish the actual risk posed by a vulnerability discovered through code review. A vulnerability found during code review may turn out not to be exploitable during penetration test. This could be due to an incomplete code review, in which a missing protective measure (input validation, for instance) was determined to be missing, but was actually present. But it is also possible that mitigating controls (such as Defense in Depth mask the vulnerability in the actual operating environment. While the vulnerability in this latter case is real, the actual risk may be lower.
While vulnerabilities exploited during a white box penetration test (based on source code review) are certainly real, the actual risk of these vulnerabilities should be carefully analyzed. It is unrealistic that an attacker would be given access to the target web application's source code and advice from its developers. Thus, the risk that an outside attacker could exploit the vulnerabilities found by the white box penetration tester is probably lower. However, if the web application organization is concerned with the risk of attackers with inside knowledge (former employees or collusion with current employees or contractors), the real-world risk may be just as high.
The results of the penetration test can then be used to target additional code review. Besides addressing the particular vulnerability exploited in the test, it is a good practice to look for additional places where that same class of vulnerability is present, even if not explicitly exploited in test. For instance, if output encoding is not used in one area of the application and the penetration test exploited that, it is quite possible that output encoding is also not used elsewhere in the application.