Difference between revisions of "Top 10 2013-A9-Using Components with Known Vulnerabilities"

From OWASP
Jump to: navigation, search
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
= TEMPORARY PLACEHOLDER for 2013 T10 =
 
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
 
     |usenext=2013NextLink
 
     |usenext=2013NextLink
Line 11: Line 10:
 
}}
 
}}
  
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
+
{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2013}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
+
{{Top_10_2010:SummaryTableValue-2-Template|Exploitability|AVERAGE|year=2013}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
+
{{Top_10_2010:SummaryTableValue-1-Template|Prevalence|WIDESPREAD|year=2013}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|AVERAGE}}
+
{{Top_10_2010:SummaryTableValue-3-Template|Detectability|DIFFICULT|year=2013}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
+
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE|year=2013}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
+
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013}}
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>blank.</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors.
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>blank</td>
+
</td>
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>blank</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attacker identifies a weak component through scanning or manual analysis. They customize the exploit as needed and execute the attack. It gets more difficult if the used component is deep in the application.
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>blank</td>
+
</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>blank</td>
+
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Virtually every application has these issues because most development teams don’t focus on ensuring their components stay up to date. In many cases,  the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.
 +
</td>
 +
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could be minimal, up to complete host takeover and data compromise.
 +
</td>
 +
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.
 +
</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9|year=2013}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9|year=2013}}
blank
+
In theory, it ought to be easy to figure out if you are currently using any vulnerable components or libraries. Unfortunately, vulnerability reports do not always specify exactly which versions of a component are vulnerable in a standard, searchable way. Further, not all libraries use an understandable version numbering system. Worst of all, not all vulnerabilities are reported to a central clearinghouse that is easy to search, although sites like CVE and NVD are becoming easier to search.
 +
 
 +
Determining if you are vulnerable requires searching these databases, as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability. If one of your components does have a vulnerability, you should carefully evaluate whether you are actually vulnerable by checking to see if your code uses the part of the component with the vulnerability and whether the flaw could result in an impact you care about.
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=9|year=2013}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=9|year=2013}}
blank
+
One option is not to use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date.
#blankBullet1
+
Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version.
#blankBullet2
+
Software projects should have a process in place to:
 +
# Identify the components and their versions you are using, including all dependencies. (e.g., the versions plugin).
 +
# Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
 +
# Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=9|year=2013}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=9|year=2013}}
blank
+
Component vulnerabilities can cause almost any type of risk imaginable, from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011.
{{Top_10_2010:ExampleBeginTemplate}}<span style="color:red;">blank code</span>{{Top_10_2010:ExampleEndTemplate}}
+
 
blank
+
* Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission.
{{Top_10_2010:ExampleBeginTemplate}}<nowiki>http://example.com/app/accountView?id=</nowiki><span style="color: red;">' or '1'='1</span>{{Top_10_2010:ExampleEndTemplate}}
+
* Spring Remote Code Execution – Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.
blank
+
 
 +
Every application using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=9|year=2013}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=9|year=2013}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[SQL_Injection_Prevention_Cheat_Sheet | OWASP SQL Injection Prevention Cheat Sheet]]
+
 
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.html ESAPI Encoder API]
+
&nbsp;&nbsp;''None''
 +
 
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
* [http://cwe.mitre.org/data/definitions/77.html CWE Entry 77 on Command Injection]
+
* The Unfortunate Reality of Insecure Libraries
* [http://cwe.mitre.org/data/definitions/89.html CWE Entry 89 on SQL Injection]
+
* Open Source Software Security
 +
* Addressing Security Concerns in Open Source Components
 +
* MITRE Common Vulnerabilities and Exposures
  
 
{{Top_10_2013:BottomAdvancedTemplate
 
{{Top_10_2013:BottomAdvancedTemplate

Revision as of 14:40, 23 February 2013

[[Top 10 {{{year}}}-Cross-Site Request Forgery (CSRF)|← Cross-Site Request Forgery (CSRF)]]
2013 Table of Contents

2013 Top 10 List

[[Top 10 {{{year}}}-Unvalidated Redirects and Forwards|Unvalidated Redirects and Forwards →]]
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
AVERAGE
Prevalence
WIDESPREAD
Detectability
DIFFICULT
Impact
MODERATE
Application / Business Specific
Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors. Attacker identifies a weak component through scanning or manual analysis. They customize the exploit as needed and execute the attack. It gets more difficult if the used component is deep in the application. Virtually every application has these issues because most development teams don’t focus on ensuring their components stay up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse. The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could be minimal, up to complete host takeover and data compromise. Consider what each vulnerability might mean for the business controlled by the affected application. It could be trivial or it could mean complete compromise.
Am I Vulnerable To 'Using Components with Known Vulnerabilities'?

In theory, it ought to be easy to figure out if you are currently using any vulnerable components or libraries. Unfortunately, vulnerability reports do not always specify exactly which versions of a component are vulnerable in a standard, searchable way. Further, not all libraries use an understandable version numbering system. Worst of all, not all vulnerabilities are reported to a central clearinghouse that is easy to search, although sites like CVE and NVD are becoming easier to search.

Determining if you are vulnerable requires searching these databases, as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability. If one of your components does have a vulnerability, you should carefully evaluate whether you are actually vulnerable by checking to see if your code uses the part of the component with the vulnerability and whether the flaw could result in an impact you care about.

How Do I Prevent 'Using Components with Known Vulnerabilities'?

One option is not to use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. Software projects should have a process in place to:

  1. Identify the components and their versions you are using, including all dependencies. (e.g., the versions plugin).
  2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
  3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
Example Attack Scenarios

Component vulnerabilities can cause almost any type of risk imaginable, from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011.

  • Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission.
  • Spring Remote Code Execution – Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.

Every application using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.

References

OWASP

  None

External

  • The Unfortunate Reality of Insecure Libraries
  • Open Source Software Security
  • Addressing Security Concerns in Open Source Components
  • MITRE Common Vulnerabilities and Exposures
[[Top 10 {{{year}}}-Cross-Site Request Forgery (CSRF)|← Cross-Site Request Forgery (CSRF)]]
2013 Table of Contents

2013 Top 10 List

[[Top 10 {{{year}}}-Unvalidated Redirects and Forwards|Unvalidated Redirects and Forwards →]]

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png
[[Category:OWASP Top Ten {{{year}}} Project]]