This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Map execution paths through application (OTG-INFO-007)"
(Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == == Description of the Issue == == Black Box testing and example == == Gray Box testing and example == Not appl...") |
|||
| Line 1: | Line 1: | ||
{{Template:OWASP Testing Guide v4}} | {{Template:OWASP Testing Guide v4}} | ||
| + | |||
| + | |||
== Brief Summary == | == Brief Summary == | ||
| + | |||
| + | Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly. | ||
| + | |||
| + | |||
== Description of the Issue == | == Description of the Issue == | ||
| + | |||
| + | In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to document what code paths were discovered and tested. | ||
| + | |||
| + | There are several ways to approach the testing and measurement of code coverage: | ||
| + | |||
| + | * Path - test each of the paths through an application which includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch. | ||
| + | * Data flow (or taint analysis) - tests the assignment of variables via external interaction (normally users). Focuses on mapping the flow, transformation and use of data throughout an application. | ||
| + | * Race - tests multiple concurrent instances of the application manipulating the same data. | ||
| + | |||
| + | The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the application owner what functions or code sections they are particularly concerned about and how those code segments can be reached. | ||
| + | |||
| + | |||
== Black Box testing and example == | == Black Box testing and example == | ||
| + | |||
| + | |||
== Gray Box testing and example == | == Gray Box testing and example == | ||
| + | |||
| + | |||
Not applicable. | Not applicable. | ||
| + | |||
| + | |||
== References == | == References == | ||
| + | |||
| + | |||
'''Whitepapers''' | '''Whitepapers''' | ||
| − | [1] | + | |
| + | [1] | ||
| + | |||
| + | http://en.wikipedia.org/wiki/Code_coverage | ||
'''Tools''' | '''Tools''' | ||
| − | * | + | |
| − | * | + | |
| + | * Spreadsheet software | ||
| + | |||
| + | * Diagramming software | ||
Revision as of 00:46, 6 December 2012
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project
Brief Summary
Before commencing security testing, understanding the structure of the application is paramount. Without a thorough understanding of the layout of the application, it is unlkely that it will be tested thoroughly.
Description of the Issue
In black box testing it is extremely difficult to test the entire code base. Not just because the tester has no view of the code paths through the application, but even if they did, to test all code paths would be very time consuming. One way to reconcile this is to document what code paths were discovered and tested.
There are several ways to approach the testing and measurement of code coverage:
* Path - test each of the paths through an application which includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch. * Data flow (or taint analysis) - tests the assignment of variables via external interaction (normally users). Focuses on mapping the flow, transformation and use of data throughout an application. * Race - tests multiple concurrent instances of the application manipulating the same data.
The trade off as to what method is used and to what degree each method is used should be negotiated with the application owner. Simpler approaches could also be adopted, including asking the application owner what functions or code sections they are particularly concerned about and how those code segments can be reached.
Black Box testing and example
Gray Box testing and example
Not applicable.
References
Whitepapers
[1]
http://en.wikipedia.org/wiki/Code_coverage
Tools
- Spreadsheet software
- Diagramming software
