OWASP - User contributions [en]

Category:Vulnerability

2009-01-05T08:23:29Z

Zqc0512: /* What is a vulnerability? */

This category is for tagging common types of software vulnerabilities.

==What is a vulnerability?== test test test test test

<categorytree hideroot="on" style="float:right; clear:right; margin-left:1ex; border:1px solid gray; padding:0.7ex; background-color:white;">Vulnerability</categorytree>
A vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. The term "vulnerability" is often used very loosely. However, here we need to distinguish [[:Category:Threat|threats]], [[:Category:Attack|attacks]], and [[:Category:Countermeasure|countermeasures]].

Please '''do not post any actual vulnerabilities''' in products, services, or web applications. Those disclosure reports should be posted to bugtraq or full-disclosure mailing lists.

==Examples of vulnerabilities==
* Lack of input validation on user input
* Lack of sufficient logging mechanism
* Fail-open error handling
* Not closing the database connection properly

For a great overview, check out the [[OWASP Top Ten Project]]. You can read about the top vulnerabilities and download a paper that covers them in detail. Many organizations and agencies use the Top Ten as a way of creating awareness about application security.

{{Template:PutInCategory}}

'''NOTE:''' Before you add a vulnerability, please search and make sure there isn't an equivalent one already. You may want to consider creating a redirect if the topic is the same. Every vulnerability article has a defined structure. Please read the details of [[How To Add a Vulnerability]] before creating a new article.

[[Category:Article Type]]
[[Category:OWASP Honeycomb Project]]

CLASP Concepts

2008-12-11T03:30:55Z

Zqc0512: /* Overview of CLASP Taxonomy */

{{Template:SecureSoftware}}

==Concepts View==
[[Glossary#CLASP|CLASP]] is the outgrowth of years of extensive field work in which system resources of many development lifecycles were methodically decomposed in order to create a comprehensive set of security requirements. These resulting requirements form the basis of CLASP’s best practices which allow organizations to systematically address vulnerabilities that, if exploited, can result in the failure of basic security services — e.g., confidentiality, authentication, and access control.

===Adaptability of CLASP to Existing Development Processes===
[[Glossary#CLASP|CLASP]] is designed to allow you to easily integrate its security-related activities into your existing application development processes. Each [[Glossary#CLASP|CLASP]] activity is divided into discrete process components and linked to one or more specific project roles. In this way, [[Glossary#CLASP|CLASP]] provides guidance to project participants — e.g., project managers, security auditors, developers, architects, testers, and others — that is easy to adopt to their way of working; this results in incremental improvements to security that are easily achievable, repeatable, and measurable.

===CLASP Vulnerability Lexicon===
[[Glossary#CLASP|CLASP]] also contains a comprehensive Vulnerability Lexicon that helps development teams avoid/remediate specific designing/coding errors that can lead to exploitable security services. The basis of this Lexicon is a highly flexible taxonomy — i.e., classification structure — that enables development teams to quickly locate Lexicon information from many perspectives: e.g., problem types (i.e., basic causes of vulnerabilities); categories of problem types; exposure periods; avoidance and mitigation periods; consequences of exploited vulnerabilities; affected platforms and programming languages; risk assessment.

===Automated Analysis Tool===
Much of the information in the [[Glossary#CLASP|CLASP]] Vulnerability Lexicon can be enforced through use of automated tools using techniques of static analysis of source code.

==Overview of CLASP Process==
This section provides an overview of [[Glossary#CLASP|CLASP]]’s structure and of the dependencies between the [[Glossary#CLASP|CLASP]] process components and is organized as follows:
* CLASP Views
* CLASP Resources
* Vulnerability Use Cases

===CLASP Views===
The [[Glossary#CLASP|CLASP]] process is presented through five high-level perspectives called [[Glossary#CLASP|CLASP]] Views. These views are broken down into activities which in turn contain process components. This top-down organization by View > Activity > Process Component allows you to quickly understand the [[Glossary#CLASP|CLASP]] process, how [[Glossary#CLASP|CLASP]] pieces interact, and how to apply them to your specific software development lifecycle.
These are the [[Glossary#CLASP|CLASP]] Views:
* Concepts View
* Role-Based View
* Activity-Assessment View
* Activity-Implementation View
* Vulnerability View
See figure 1.

[[Image:CLASP_Views.gif|none|thumb|600px|Figure 1: CLASP Views and their interactions]]

===CLASP Resources===
The [[Glossary#CLASP|CLASP]] process supports planning, implementing and performing security-related software development activities. The [[Glossary#CLASP|CLASP]] Resources provide access to artifacts that are especially useful if your project is using tools to help automate [[Glossary#CLASP|CLASP]] process pieces.
This table lists the name and location of [[Glossary#CLASP|CLASP]] Resources delivered with [[Glossary#CLASP|CLASP]] and indicates which [[Glossary#CLASP|CLASP]] Views they can support:
{| class="wikitable"
|+
|-----
!CLASP Resources
!Location
|-----
| Basic Principles in Application Security (all Views) || Resource A
|-----
| Example of Basic Principle: Input Validation (all Views) || Resource B
|-----
| Example of Basic-Principle Violation: Penetrate-and-Patch Model (all Views) || Resource C
|-----
| Core Security Services (all Views; especially III) || Resource D
|-----
| Sample Coding Guideline Worksheets (Views II, III & IV)
Note: Each worksheet can be pasted into a MS Word document.
| Resource E
|-----
| System Assessment Worksheets (Views III & IV)
Note: Each worksheet can be pasted into a MS Word document.
| Resource F
|-----
| Sample Road Map: Legacy Projects (View III) || Resource G1
|-----
| Sample Road Map: New-Start Projects (View III)|| Resource G2
|-----
| Creating the Process Engineering Plan (View III)|| Resource H
|-----
| Forming the Process Engineering Team (View III) || Resource I
|-----
| Glossary of Security Terms (all Views) || [[Glossary|Resource J]]
|-----
|}

===Vulnerability Use Cases===
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases depict conditions under which security services can become vulnerable in software applications. The Use Cases provide [[Glossary#CLASP|CLASP]] users with easy-to-understand, specific examples of the cause-and-effect relationship between security-unaware design/source coding and possible resulting vulnerabilities in basic security services — e.g., authentication authorization, confidentiality, availability, accountability, and non-repudiation.
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases are based on the following common component architectures:
* Monolithic UNIX
* Monolithic mainframe
* Distributed architecture (HTTP[S] & TCP/IP)
It is recommended to understand the [[Glossary#CLASP|CLASP]] Use Cases as a bridge from the Concepts View of [[Glossary#CLASP|CLASP]] to the Vulnerability Lexicon (in the Vulnerability View) since they provide specific examples of security services becoming vulnerable in software applications
See figure 2.
[[Image:CLASP_Vulnerability_Use_Cases.gif|none|thumb|600px|Figure 2: Recommended position of the Use Cases within the CLASP process]]

===CLASP Best Practices===
The foundation of CLASP is in seven key Best Practices for application security. See [[:Category:CLASP Best Practice|CLASP Best Practices]].
# [[:Category:BP1 Institute awareness programs|Institute awareness programs]]
# [[:Category:BP2 Perform application assessments|Perform application assessments]]
# [[:Category:BP3 Capture security requirements|Capture security requirements]]
# [[:Category:BP4 Implement secure development practices|Implement secure development practices]]
# [[:Category:BP5 Build vulnerability remediation procedures|Build vulnerability remediation procedures]]
# [[:Category:BP6 Define and monitor metrics|Define and monitor metrics]]
# [[:Category:BP7 Publish operational security guidelines|Publish operational security guidelines]]

==CLASP and Security Policies==
A high-level view of [[Glossary#CLASP|CLASP]] can help increase awareness of the importance of implementing application security on these organizational levels, from the bottom up: > best practices of application-security > application-security policy > IT security policy > operations security policy > corporate security policy.
[[Image:CLASP_and_Security_Policies.gif|none|thumb|600px|Figure 4: Interaction of CLASP and Security Policies]]

==What is a Security Vulnerability==
[[Glossary#CLASP|CLASP]] defines a security vulnerability as a flaw in a software environment — especially in an application — that allows an attacker to assume privileges within the user's system, utilize and regulate its operation, compromise the data it contains, and/or assume trust not granted to the attacker.
A security vulnerability occurs in a software application when any part of it allows a breach of the security policy governing it.
[[Glossary#CLASP|CLASP]] identifies 104 underlying problem types that form the basis of security vulnerabilities in application source code. An individual problem type in itself is often not a security vulnerability; frequently it is a combination of problems that create a security condition leading to a vulnerability in the source code. [[Glossary#CLASP|CLASP]] divides the 104 problem types into 5 high-level categories. Each problem type may have more than one parent category.
[[Glossary#CLASP|CLASP]] defines a consequence of an exploited or exploitable vulnerability as a failure in one or more of these basic security services:
* Authorization (resource access control)
* Confidentiality (of data or other resources)
* Authentication (identity establishment and integrity)
* Availability (denial of service)
* Accountability
* Non-repudiation
The following figure shows in which phases of the software development lifecycle a security-related vulnerability can occur and also which points in an operational system an attack can target.
[[Image:CLASP_Vulnerabilities_SDLC_Phases.gif|none|thumb|600px|Figure 5: Vulnerabilities from Perspective of SDLC Phases]]

==Overview of CLASP Taxonomy==
The [[Glossary#CLASP|CLASP]] taxonomy is a high-level classification of the [[Glossary#CLASP|CLASP]] process, divided into the following classes for better evaluation and resolution of security vulnerabilities in source code:
* '''Problem types''' underlying security-related vulnerabilities.
* '''Categories''' into which the problem types are divided for diagnostic and resolution purposes.
* '''Exposure periods''' (i.e., SDLC phases) in which vulnerabilities can be inadvertently introduced into application source code.
* '''Consequences''' of exploited vulnerabilities for basic security services.
* '''Platforms''' and programming languages which may be affected by a vulnerability.
* '''Resources''' required for attack against vulnerabilities.
* '''Risk assessment''' of exploitable/exploited vulnerabilities.
* '''Avoidance and mitigation periods''' (i.e., SDLC phases) in which preventative measures and countermeasures can be applied.
See figure 6.
[[Image:CLASP_Taxonomy.gif|none|thumb|600px|Figure 6: CLASP taxonomy and the relationship between its parts]]

==Applying CLASP Components==
This page describes a possible sequence for applying [[Glossary#CLASP|CLASP]] components, using the Sample Coding Guidelines ([[Glossary#CLASP|CLASP]] Resource E) as a basis. See figure 7.
[[Image:CLASP_Applying_Components.gif|none|thumb|600px|Figure 7: a possible sequence for applying CLASP components]]
The steps below describe a possible sequence for applying [[Glossary#CLASP|CLASP]] components depicted in the figure above:
* Read the [[Glossary#CLASP|CLASP]] Concepts View to gain an overview of the [[Glossary#CLASP|CLASP]] process.
* In the Concepts View, pay special attention to the page Description of [[Glossary#CLASP|CLASP]] Process. This page contains a diagram showing, among other things, the location of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities), the five high-level, source-code-related categories by which they are organized, and the consequences of exploitable security vulnerabilities for security services.
* Read the [[Glossary#CLASP|CLASP]] Sample Coding Guidelines thoroughly and select a subset of them relevant to your specific software development project. These guidelines contain a set of security-related coding standards to be applied to your project.
* Apply the remaining [[Glossary#CLASP|CLASP]] Resources throughout the planning, design, construction, and testing process, as needed.
* Use the Sample Coding Guidelines to select a subset of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities) — located in the [[Glossary#CLASP|CLASP]] Vulnerability View — which are most important to your project.
* Familiarize yourself with the [[Glossary#CLASP|CLASP]] Role-Based View, which provides an overview of the project roles associated with applying the selected subset of Sample Coding Guidelines, and assign these guidelines to your relevant project personnel — e.g., designer, security auditor, implementers.
* Consider the subset of vulnerabilities selected in part though the Sample Coding Guidelines when using the Activity-Assessment View to assess and select the desired subset of 24 activities contained in the Activity-Implementation View.

== CLASP and IT Internal Controls ==
A significant number of the internal controls required by the Sarbanes-Oxley Act for assurance of accurate and reliable corporate financial reporting are located in the IT area.
The figure below shows how [[Glossary#CLASP|CLASP]] can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects.
[[Image:CLASP_IT_Internal_Controls.gif|none|thumb|600px|Figure 8: How CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. Centers on Sarbanes-Oxley sections 302, 404 and 409]]

[[Category:OWASP CLASP Project]]

CLASP Concepts

2008-12-11T03:28:58Z

Zqc0512: /* Overview of CLASP Taxonomy */

{{Template:SecureSoftware}}

==Concepts View==
[[Glossary#CLASP|CLASP]] is the outgrowth of years of extensive field work in which system resources of many development lifecycles were methodically decomposed in order to create a comprehensive set of security requirements. These resulting requirements form the basis of CLASP’s best practices which allow organizations to systematically address vulnerabilities that, if exploited, can result in the failure of basic security services — e.g., confidentiality, authentication, and access control.

===Adaptability of CLASP to Existing Development Processes===
[[Glossary#CLASP|CLASP]] is designed to allow you to easily integrate its security-related activities into your existing application development processes. Each [[Glossary#CLASP|CLASP]] activity is divided into discrete process components and linked to one or more specific project roles. In this way, [[Glossary#CLASP|CLASP]] provides guidance to project participants — e.g., project managers, security auditors, developers, architects, testers, and others — that is easy to adopt to their way of working; this results in incremental improvements to security that are easily achievable, repeatable, and measurable.

===CLASP Vulnerability Lexicon===
[[Glossary#CLASP|CLASP]] also contains a comprehensive Vulnerability Lexicon that helps development teams avoid/remediate specific designing/coding errors that can lead to exploitable security services. The basis of this Lexicon is a highly flexible taxonomy — i.e., classification structure — that enables development teams to quickly locate Lexicon information from many perspectives: e.g., problem types (i.e., basic causes of vulnerabilities); categories of problem types; exposure periods; avoidance and mitigation periods; consequences of exploited vulnerabilities; affected platforms and programming languages; risk assessment.

===Automated Analysis Tool===
Much of the information in the [[Glossary#CLASP|CLASP]] Vulnerability Lexicon can be enforced through use of automated tools using techniques of static analysis of source code.

==Overview of CLASP Process==
This section provides an overview of [[Glossary#CLASP|CLASP]]’s structure and of the dependencies between the [[Glossary#CLASP|CLASP]] process components and is organized as follows:
* CLASP Views
* CLASP Resources
* Vulnerability Use Cases

===CLASP Views===
The [[Glossary#CLASP|CLASP]] process is presented through five high-level perspectives called [[Glossary#CLASP|CLASP]] Views. These views are broken down into activities which in turn contain process components. This top-down organization by View > Activity > Process Component allows you to quickly understand the [[Glossary#CLASP|CLASP]] process, how [[Glossary#CLASP|CLASP]] pieces interact, and how to apply them to your specific software development lifecycle.
These are the [[Glossary#CLASP|CLASP]] Views:
* Concepts View
* Role-Based View
* Activity-Assessment View
* Activity-Implementation View
* Vulnerability View
See figure 1.

[[Image:CLASP_Views.gif|none|thumb|600px|Figure 1: CLASP Views and their interactions]]

===CLASP Resources===
The [[Glossary#CLASP|CLASP]] process supports planning, implementing and performing security-related software development activities. The [[Glossary#CLASP|CLASP]] Resources provide access to artifacts that are especially useful if your project is using tools to help automate [[Glossary#CLASP|CLASP]] process pieces.
This table lists the name and location of [[Glossary#CLASP|CLASP]] Resources delivered with [[Glossary#CLASP|CLASP]] and indicates which [[Glossary#CLASP|CLASP]] Views they can support:
{| class="wikitable"
|+
|-----
!CLASP Resources
!Location
|-----
| Basic Principles in Application Security (all Views) || Resource A
|-----
| Example of Basic Principle: Input Validation (all Views) || Resource B
|-----
| Example of Basic-Principle Violation: Penetrate-and-Patch Model (all Views) || Resource C
|-----
| Core Security Services (all Views; especially III) || Resource D
|-----
| Sample Coding Guideline Worksheets (Views II, III & IV)
Note: Each worksheet can be pasted into a MS Word document.
| Resource E
|-----
| System Assessment Worksheets (Views III & IV)
Note: Each worksheet can be pasted into a MS Word document.
| Resource F
|-----
| Sample Road Map: Legacy Projects (View III) || Resource G1
|-----
| Sample Road Map: New-Start Projects (View III)|| Resource G2
|-----
| Creating the Process Engineering Plan (View III)|| Resource H
|-----
| Forming the Process Engineering Team (View III) || Resource I
|-----
| Glossary of Security Terms (all Views) || [[Glossary|Resource J]]
|-----
|}

===Vulnerability Use Cases===
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases depict conditions under which security services can become vulnerable in software applications. The Use Cases provide [[Glossary#CLASP|CLASP]] users with easy-to-understand, specific examples of the cause-and-effect relationship between security-unaware design/source coding and possible resulting vulnerabilities in basic security services — e.g., authentication authorization, confidentiality, availability, accountability, and non-repudiation.
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases are based on the following common component architectures:
* Monolithic UNIX
* Monolithic mainframe
* Distributed architecture (HTTP[S] & TCP/IP)
It is recommended to understand the [[Glossary#CLASP|CLASP]] Use Cases as a bridge from the Concepts View of [[Glossary#CLASP|CLASP]] to the Vulnerability Lexicon (in the Vulnerability View) since they provide specific examples of security services becoming vulnerable in software applications
See figure 2.
[[Image:CLASP_Vulnerability_Use_Cases.gif|none|thumb|600px|Figure 2: Recommended position of the Use Cases within the CLASP process]]

===CLASP Best Practices===
The foundation of CLASP is in seven key Best Practices for application security. See [[:Category:CLASP Best Practice|CLASP Best Practices]].
# [[:Category:BP1 Institute awareness programs|Institute awareness programs]]
# [[:Category:BP2 Perform application assessments|Perform application assessments]]
# [[:Category:BP3 Capture security requirements|Capture security requirements]]
# [[:Category:BP4 Implement secure development practices|Implement secure development practices]]
# [[:Category:BP5 Build vulnerability remediation procedures|Build vulnerability remediation procedures]]
# [[:Category:BP6 Define and monitor metrics|Define and monitor metrics]]
# [[:Category:BP7 Publish operational security guidelines|Publish operational security guidelines]]

==CLASP and Security Policies==
A high-level view of [[Glossary#CLASP|CLASP]] can help increase awareness of the importance of implementing application security on these organizational levels, from the bottom up: > best practices of application-security > application-security policy > IT security policy > operations security policy > corporate security policy.
[[Image:CLASP_and_Security_Policies.gif|none|thumb|600px|Figure 4: Interaction of CLASP and Security Policies]]

==What is a Security Vulnerability==
[[Glossary#CLASP|CLASP]] defines a security vulnerability as a flaw in a software environment — especially in an application — that allows an attacker to assume privileges within the user's system, utilize and regulate its operation, compromise the data it contains, and/or assume trust not granted to the attacker.
A security vulnerability occurs in a software application when any part of it allows a breach of the security policy governing it.
[[Glossary#CLASP|CLASP]] identifies 104 underlying problem types that form the basis of security vulnerabilities in application source code. An individual problem type in itself is often not a security vulnerability; frequently it is a combination of problems that create a security condition leading to a vulnerability in the source code. [[Glossary#CLASP|CLASP]] divides the 104 problem types into 5 high-level categories. Each problem type may have more than one parent category.
[[Glossary#CLASP|CLASP]] defines a consequence of an exploited or exploitable vulnerability as a failure in one or more of these basic security services:
* Authorization (resource access control)
* Confidentiality (of data or other resources)
* Authentication (identity establishment and integrity)
* Availability (denial of service)
* Accountability
* Non-repudiation
The following figure shows in which phases of the software development lifecycle a security-related vulnerability can occur and also which points in an operational system an attack can target.
[[Image:CLASP_Vulnerabilities_SDLC_Phases.gif|none|thumb|600px|Figure 5: Vulnerabilities from Perspective of SDLC Phases]]

==Overview of CLASP Taxonomy==
The [[Glossary#CLASP|CLASP]] taxonomy is a high-level classification of the [[Glossary#CLASP|CLASP]] process, divided into the following classes for better evaluation and resolution of security vulnerabilities in source code:
* '''Problem types''' underlying security-related vulnerabilities.
* '''Categories''' into which the problem types are divided for diagnostic and resolution purposes.
* '''Exposure periods''' (i.e., SDLC phases) in which vulnerabilities can be inadvertently introduced into application source code.
* '''Consequences''' of exploited vulnerabilities for basic security services.
* '''Platforms''' and programming languages which may be affected by a vulnerability.
* '''Resources''' required for attack against vulnerabilities.
* '''Risk assessment''' of exploitable/exploited vulnerabilities.
* '''Avoidance and mitigation periods''' (i.e., SDLC phases) in which preventative measures and countermeasures can be applied. yes test
See figure 6.
[[Image:CLASP_Taxonomy.gif|none|thumb|600px|Figure 6: CLASP taxonomy and the relationship between its parts]]

==Applying CLASP Components==
This page describes a possible sequence for applying [[Glossary#CLASP|CLASP]] components, using the Sample Coding Guidelines ([[Glossary#CLASP|CLASP]] Resource E) as a basis. See figure 7.
[[Image:CLASP_Applying_Components.gif|none|thumb|600px|Figure 7: a possible sequence for applying CLASP components]]
The steps below describe a possible sequence for applying [[Glossary#CLASP|CLASP]] components depicted in the figure above:
* Read the [[Glossary#CLASP|CLASP]] Concepts View to gain an overview of the [[Glossary#CLASP|CLASP]] process.
* In the Concepts View, pay special attention to the page Description of [[Glossary#CLASP|CLASP]] Process. This page contains a diagram showing, among other things, the location of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities), the five high-level, source-code-related categories by which they are organized, and the consequences of exploitable security vulnerabilities for security services.
* Read the [[Glossary#CLASP|CLASP]] Sample Coding Guidelines thoroughly and select a subset of them relevant to your specific software development project. These guidelines contain a set of security-related coding standards to be applied to your project.
* Apply the remaining [[Glossary#CLASP|CLASP]] Resources throughout the planning, design, construction, and testing process, as needed.
* Use the Sample Coding Guidelines to select a subset of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities) — located in the [[Glossary#CLASP|CLASP]] Vulnerability View — which are most important to your project.
* Familiarize yourself with the [[Glossary#CLASP|CLASP]] Role-Based View, which provides an overview of the project roles associated with applying the selected subset of Sample Coding Guidelines, and assign these guidelines to your relevant project personnel — e.g., designer, security auditor, implementers.
* Consider the subset of vulnerabilities selected in part though the Sample Coding Guidelines when using the Activity-Assessment View to assess and select the desired subset of 24 activities contained in the Activity-Implementation View.

== CLASP and IT Internal Controls ==
A significant number of the internal controls required by the Sarbanes-Oxley Act for assurance of accurate and reliable corporate financial reporting are located in the IT area.
The figure below shows how [[Glossary#CLASP|CLASP]] can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects.
[[Image:CLASP_IT_Internal_Controls.gif|none|thumb|600px|Figure 8: How CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. Centers on Sarbanes-Oxley sections 302, 404 and 409]]

[[Category:OWASP CLASP Project]]