OWASP - User contributions [en]

Social Engineering

2007-04-19T18:58:59Z

Manionc: /* References */

==Definition ==
An attack based on deceiving end users or administrators at a target site. Social engineering attacks are are typically carried out by email or by contacting users by phone and impersonating an authorized user, in an attempt to gain unauthorized access to a system or application.

== Examples ==
'''Example #1:'''
*An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
*The attacker then logs in as one of the users from over the network.
*System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
* Educate staff
* Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
* Identify security-related transactions that must be done in person

== Related Attacks ==

== References ==
Social Engineering [http://en.wikipedia.org/wiki/Social_engineering_(computer_security)#Quid_pro_quo]

Social Engineering

2007-04-19T18:58:12Z

Manionc: /* References */

==Definition ==
An attack based on deceiving end users or administrators at a target site. Social engineering attacks are are typically carried out by email or by contacting users by phone and impersonating an authorized user, in an attempt to gain unauthorized access to a system or application.

== Examples ==
'''Example #1:'''
*An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
*The attacker then logs in as one of the users from over the network.
*System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
* Educate staff
* Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
* Identify security-related transactions that must be done in person

== Related Attacks ==

== References ==
[http://en.wikipedia.org/wiki/Social_engineering_(computer_security)#Quid_pro_quo]

Social Engineering

2007-04-19T18:56:46Z

Manionc:

Social Engineering

2007-04-19T18:54:12Z

Manionc: /* Examples */

Social Engineering

2007-04-19T18:53:36Z

Manionc: /* Definition */

==Definition ==
An attack based on deceiving end users or administrators at a target site. Social engineering attacks are are typically carried out by email or by contacting users by phone and impersonating an authorized user, in an attempt to gain unauthorized access to a system or application.

== Examples ==
Example #1: (Believe it or not, this has worked for some attackers!)
*An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
*The attacker then logs in as one of the users from over the network.
*System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
* Educate staff
* Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
* Identify security-related transactions that must be done in person

Social Engineering

2007-04-19T18:51:46Z

Manionc:

==Definition ==
An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems.

== Examples ==
Example #1: (Believe it or not, this has worked for some attackers!)
*An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
*The attacker then logs in as one of the users from over the network.
*System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
* Educate staff
* Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
* Identify security-related transactions that must be done in person

Social Engineering

2007-04-19T18:50:53Z

Manionc: /* Countermeasures */

'''Social Engineering'''

==Definition ==
An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems.

== Examples ==
Example #1: (Believe it or not, this has worked for some attackers!)
1. An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
3. The attacker then logs in as one of the users from over the network.
4. System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
* Educate staff
* Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
* Identify security-related transactions that must be done in person

Social Engineering

2007-04-19T18:49:56Z

Manionc:

'''Social Engineering'''

==Definition ==
An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems.

== Examples ==
Example #1: (Believe it or not, this has worked for some attackers!)
1. An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
3. The attacker then logs in as one of the users from over the network.
4. System bugs are then exploited to gain complete control of the system.

== Countermeasures ==
– Educate staff
– Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
– Identify security-related transactions that must be done in person

Social Engineering

2007-04-19T18:48:19Z

Manionc: New page: '''Social Engineering''' '''Definition''' An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning user...

'''Social Engineering'''

'''Definition'''
An attack based on deceiving users or administrators at the target site. Social engineering attacks are typically carried out by telephoning users or operators and pretending to be an authorized user, to attempt to gain illicit access to systems.

'''Examples'''
Example #1: (Believe it or not, this has worked for some attackers!)
1. An attacker, posing an a system administrator, sends an email to several users on a large network (like a college campus network) and asks them to, “Please change your password to ‘xyz123’ and then notify me when you've completed this.”
3. The attacker then logs in as one of the users from over the network.
4. System bugs are then exploited to gain complete control of the system.

'''Countermeasures'''
– Educate staff
– Establish mechanisms for problem reporting and handling and make sure users know what those mechanisms are
– Identify security-related transactions that must be done in person

OWASP Testing Guide Table of Contents

2006-10-09T13:39:53Z

Manionc: /* The OWASP Testing Framework */

==[[Testing Guide Frontispiece|Frontispiece]]==
#Copyright and License
#Endorsements
#Trademarks

==[[Testing Guide Introduction|Introduction]]==
#Performing An Application Security Review
#Principles of Testing
#Testing Techniques Explained

==[[Methodologies Used]]==
#Secure application design
#Code Review (See the code review project)
#*Overview
#*Advantages and Disadvantages
#Penetration Testing
#*Overview
#*Advantages and Disadvantages
#The Need for a Balanced Approach
#A Note about Web Application Scanners
#A Note about Static Source Code Review Tools

==[[Finding Specific Issues In a Non-Technical Manner]]==
#Threat Modeling Introduction
#Design Reviews
#Threat Modeling the Application
#Policy Reviews
#Requirements Analysis
#Developer Interviews and Interaction

==[[:Category:OWASP Code Review Project|Finding Specific Vulnerabilities Using Source Code Review]]==

''For code review please see the [[:Category:OWASP_Code_Review_Project|OWASP Code Review Project]]

==[[Manual testing techniques]]==
#[[Business logic testing]]
#[[Authentication Testing Guide|Authentication]]
#[[How to perform cookie manipulation test|Cookie manipulation]]
#[[How to test for weak session tokens|Weak session tokens]]
#[[How to perform session riding test|Session riding test]]
#[[Testing for Cross site scripting vulnerabilities]]
#[[Testing for vulnerable remember password implementation]]
#[[Weak Password Self-Reset Testing]]
#[[Testing for default or guessable user accounts and empty passwords]]
#[[Testing for application layer Denial of Service (DoS) attacks]]
#*[[DoS Testing: Locking Customer Accounts]]
#*[[DoS Testing: Buffer Overflows]]
#*[[DoS Testing: User Specified Object Allocation]]
#*[[DoS Testing: User Input as a Loop Counter]]
#*[[DoS Testing: Writing User Provided Data to Disk]]
#*[[DoS Testing: Failure to Release Resources]]
#*[[DoS Testing: Storing too Much Data in Session]]
#[[Testing for buffer overflow]]
#*[[Testing for heap overflow vulnerability]]
#*[[Testing for stack overflow vulnerability]]
#*[[Testing for format string vulnerability]]
#[[Testing for test and debug files]]
#[[Testing file extensions handling]]
#[[Testing for Old, backup and unreferenced files]]
#[[Testing defense from Automatic Attacks]]
#[[Infrastructure configuration management testing]]
#[[Application configuration management testing]]
#[[SSL/TLS Testing: support of weak ciphers]]
#[[SSL Testing: certificate validity]]
#[[Web Services Security Testing]]
#[[Analysis about error codes]]
#[[Web services Testing]]
#*[[XML Structural Attacks]]
#*[[XML content-level attacks]]
#*[[HTTP GET parameters/REST attacks]]
#*[[Naughty SOAP attachments]]
#*[[Brute force attacks]]

==[[The OWASP Testing Framework]]==
#Overview
#Phase 1 — Before Development Begins
#*Phase 1A: Policies and Standards Review
#*Phase 1B: Develop Measurement and Metrics Criteria (Ensure Traceability)
#Phase 2: During Definition and Design
#*Phase 2A: Security Requirements Review
#*Phase 2B: Design and Architecture Review
#*Phase 2C: Create and Review UML Models
#*Phase 2D: Create and Review Threat Models
#Phase 3: During Development
#*Phase 3A: Code Walkthroughs
#*Phase 3B: Code Reviews
#Phase 4: During Deployment
#*Phase 4A: Application Penetration Testing
#*Phase 4B: Configuration Management Testing
#Phase 5: Maintenance and Operations
#*Phase 5A: Conduct Operational Management Reviews
#*Phase 5B: Conduct Periodic Health Checks
#*Phase 5C: Ensure Change Verification
#A Typical SDLC Testing Workflow
#* Figure 3: Typical SDLC Testing Workflow.

==[[Appendix A: Testing Tools]]==
#Source Code Analyzers
#*Open Source / Freeware
#*Commercial
#Black Box Scanners
#*Open Source
#*Commercial
#Other Tools
#*Runtime Analysis
#*Binary Analysis
#*Requirements Management

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
#Whitepapers
#Books
#Articles
#Useful Websites
#OWASP — http://www.owasp.org

[[Category:OWASP Testing Project]]
[[Category:Test]]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors| Appendix C: Fuzz Vectors]]==

Definition for Security Assessment Techniques

2006-10-05T21:22:47Z

Manionc: /* Techniques */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Manual Security-Focused Code Review (Software Security Specialist)
* Automated Source Code Aanalysis (Tool-Based Static Code Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:21:10Z

Manionc:

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:20:18Z

Manionc: /* Manual Security-Focused Code Review */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:20:01Z

Manionc: /* Application Security Architecture Review */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:19:36Z

Manionc: /* Manual Security-Focused Code Review */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:18:58Z

Manionc:

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T21:06:02Z

Manionc: /* Automated Source Code Analysis */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==Manual Application Security Code Review==

Reviews the underlying foundational level to identify coding issues, which may create/enable an attacker to compromise an applications systems and/or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Code reviews should be specifically tailored to find vulnerabilities common in applications.

''Advantages:''
* If integrated into application SDLC, coding issues can be resolved early in the development and functional testing process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* …

''Disadvantages:''
* …
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* …

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-10-05T20:26:33Z

Manionc: /* Automated Security Code Scanning */

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed:

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated Security Code Scanning (Tool Based Static Analysis)
* Automated External Application Scanning (Tool Based)
* Manual Penetration Testing (Security Test Specialist)
* Manual Application Security Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Automated Security Code Scanning==

Involves the use of one or more software tools to conduct automated [Static_code_analysis]

''Advantages:''
*

''Disadvantages:''
*

Recommended use:
*

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==Manual Application Security Code Review==

Reviews the underlying foundational level to identify coding issues, which may create/enable an attacker to compromise an applications systems and/or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Code reviews should be specifically tailored to find vulnerabilities common in applications.

''Advantages:''
* If integrated into application SDLC, coding issues can be resolved early in the development and functional testing process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* …

''Disadvantages:''
* …
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* …

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Blind XPath Injection

2006-09-08T20:27:31Z

Manionc: /* Blind XPath Injection */

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Simple XPath Injection===
Before you can understand what Blind XPath Injection is, you must first have a basic understanding of Simple XPath Injection. So, lets suppose an application includes the following ASP.NET and C# source code:
...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr = nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this sample code is written, an attacker could try to inject an XPath expression into the UserID text field. For example, the attacker could enter the following text into the UserID text field (just like with SQL injection):

' or 1=1 or ''='

If this entry is not handled properly by the application, then the application will return the first account number in the XML document. If that occurs, the attacker will be logged in as the first user listed in the XML document.

===Blind XPath Injection===

==Examples ==

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:26:06Z

Manionc: /* Simple XPath Injection */

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Simple XPath Injection===
Before you can understand what Blind XPath Injection is, you must first have a basic understanding of Simple XPath Injection. So, lets suppose an application includes the following ASP.NET and C# source code:
...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr = nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this sample code is written, an attacker could try to inject an XPath expression into the UserID text field. For example, the attacker could enter the following text into the UserID text field (just like with SQL injection):

' or 1=1 or ''='

If this entry is not handled properly by the application, then the application will return the first account number in the XML document. If that occurs, the attacker will be logged in as the first user listed in the XML document.

===Blind XPath Injection===
Using Blind XPath Injection, an attacker can extract a complete XML document for XPath querying without prior knowledge of the query. The attacker can access the entire XML "database" used in the XPath query which can be powerful against sites that use XPath queries (and XML "databases") for authentication, searching and other uses.

==Examples ==

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:21:05Z

Manionc: /* Simple XPath Injection */

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Simple XPath Injection===
Suppose an application includes the following ASP.NET and C# source code:
...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr = nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this code is written, an attacker could easily inject an XPath expression into the UserID text field and then submit the query. For example, the attacker could enter the following text into the UserID field (just like with SQL injection):

' or 1=1 or ''='

If not handled properly by the application, this data entry will always returns the first account number in the XML document. Such an attack is called “Xpath Injection”, which is an basically the same as a “SQL injection” attack. This can result in having the attacker logged in (as the first user listed in the XML document), although the attacker did not provide any valid user name or password.

===Blind XPath Injection===
Using Blind XPath Injection, an attacker can extract a complete XML document for XPath querying without prior knowledge of the query. The attacker can access the entire XML "database" used in the XPath query which can be powerful against sites that use XPath queries (and XML "databases") for authentication, searching and other uses.

==Examples ==

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:17:08Z

Manionc: /* Simple XPath Injection */

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Simple XPath Injection===
Suppose an application includes the following ASP.NET and C# source code:

...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this code is written, an attacker could easily inject an XPath expression into the UserID text field and then submit the query. For example, the attacker could enter the following text into the UserID field (just like with SQL injection):

' or 1=1 or ''='

If not handled properly by the application, this data entry will always returns the first account number in the XML document. Such an attack is called “Xpath Injection”, which is an basically the same as a “SQL injection” attack. This can result in having the attacker logged in (as the first user listed in the XML document), although the attacker did not provide any valid user name or password.

===Blind XPath Injection===
Using Blind XPath Injection, an attacker can extract a complete XML document for XPath querying without prior knowledge of the query. The attacker can access the entire XML "database" used in the XPath query which can be powerful against sites that use XPath queries (and XML "databases") for authentication, searching and other uses.

==Examples ==

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:16:12Z

Manionc:

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Simple XPath Injection===
'''Example 1 (Using ASP.NET with C#):'''

Suppose an application includes the following code:

...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this code is written, an attacker could easily inject an XPath expression into the UserID text field and then submit the query. For example, the attacker could enter the following text into the UserID field (just like with SQL injection):

' or 1=1 or ''='

If not handled properly by the application, this data entry will always returns the first account number in the XML document. Such an attack is called “Xpath Injection”, which is an basically the same as a “SQL injection” attack. This can result in having the attacker logged in (as the first user listed in the XML document), although the attacker did not provide any valid user name or password.

===Blind XPath Injection===
Using Blind XPath Injection, an attacker can extract a complete XML document for XPath querying without prior knowledge of the query. The attacker can access the entire XML "database" used in the XPath query which can be powerful against sites that use XPath queries (and XML "databases") for authentication, searching and other uses.

==Examples ==

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:14:57Z

Manionc: /* Examples */

{{Template:Attack}}

{{Template:Stub}}

==Description==

===About XPath===
XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries. [http://www.w3.org/TR/xpath]

===Blind XPath Injection===
Using Blind XPath Injection, an attacker can extract a complete XML document for XPath querying without prior knowledge of the query. The attacker can access the entire XML "database" used in the XPath query which can be powerful against sites that use XPath queries (and XML "databases") for authentication, searching and other uses.

==Examples ==

===Basic XPath Injection===
'''Example 1 (Using ASP.NET with C#):'''

Suppose an application includes the following code:

...
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
...
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+UserID.Text+
"' and password/text()='"+Password.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="")
{
// Login failed - UserUD and password pair could not be found in the XML document
...
}
else
{
// Login succeeded - UserID and Password validated
...
}

Based on the way this code is written, an attacker could easily inject an XPath expression into the UserID text field and then submit the query. For example, the attacker could enter the following text into the UserID field (just like with SQL injection):

' or 1=1 or ''='

If not handled properly by the application, this data entry will always returns the first account number in the XML document. Such an attack is called “Xpath Injection”, which is an basically the same as a “SQL injection” attack. This can result in having the attacker logged in (as the first user listed in the XML document), although the attacker did not provide any valid user name or password.

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:Attack]]

Blind XPath Injection

2006-09-08T20:00:53Z

Manionc: /* Description */