Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/A9-Benutzen von Komponenten mit bekannten Schwachstellen"

From OWASP
Jump to: navigation, search
m (Überschrift mithilfe 'Top_10_2010:SubsectionColoredTemplate' hinzugefügt)
(Erstbefüllung der Verteidigungs-Optionen für JAVA)
Line 58: Line 58:
 
<!-- Beispiele für JAVA --->
 
<!-- Beispiele für JAVA --->
 
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=9|year=2013|language=de}}  
 
{{Top_10:SubsectionTableBeginTemplate|type=headertab}}  {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=9|year=2013|language=de}}  
====Tbd====
+
====Erkennen aller verwendeten Software-Komponenten====
 +
Verschaffen Sie sich einen Überblick über alle, vom Programm benutzten Software-Komponenten, deren Abhängigkeiten (rekursive Abfrage der benutzten Komponenten), sowie den Versionsständen.<br>
 +
Beispiele für Tools, die Sie dabei unterstützen:
 +
* [[OWASP Dependency Check]]
 +
* [http://mojo.codehaus.org/versions-maven-plugin Versions-Plugin für Maven]
 +
* weitere kommerzielle Produkte: [http://lists.owasp.org/pipermail/owasp-topten/2013-September/001239.html vgl Top10-Mail-Liste]
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=9|year=2013|language=de}}
 +
====Sicherheits-(CERT-)Meldungen für die verwendeten Versionen prüfen====
 +
Um herauszufinden, ob diese Versionen von Schwachstellen betroffen sind, ist es notwendig, die oben genannten Schwachstellen-Datenbanken regelmäßig, in kurzen Abständen zu durchsuchen, sowie sich mithilfe von Mailing-Listen und weiteren Meldungen zeitnah über mögliche Lücken zu informieren.
  
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
+
Am einfachsten geht dies mithilfe von Tools:
tbd<br>
+
* [[OWASP Dependency Check]]
<span style="color: green;">'''tbd</span><br>
+
Falls eine benutzte Komponente verwundbar ist, sollten Sie genau prüfen, ob Ihre Anwendung verwundbare Teile der Komponente nutzt und ob der Fehler Auswirkungen hat, um die Sie sich kümmern müssen.
{{Top_10_2010:ExampleEndTemplate}}
+
 
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=9|year=2013|language=de}}
+
====Tbd====
+
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
+
<span style="color: green;">'''tbd</span><br>
+
: <span style="color: green;">'''tbd</span><br>
+
::  <span style="color: green;">'''tbd</span><br>
+
{{Top_10_2010:ExampleEndTemplate}}
+
  
 +
'''Anmerkung:'''<br>Theoretisch sollte es einfach sein, herauszufinden, ob die Anwendung verwundbare Komponenten, oder Bibliotheken benutzt. Leider enthalten Berichte über Sicherheitslücken kommerzieller oder von Open-Source-Software nicht immer automatisch auswertbare, exakte Versions-Angaben der verwundbaren Komponenten. Ferner benutzen nicht alle Bibliotheken ein verständliches Versionsnummerierungs-Schema. Darüber hinaus werden nicht alle Schwachstellen an zentrale Schwachstellen-Datenbanken, wie CVE und NVD gemeldet.
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=9|year=2013|language=de}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=9|year=2013|language=de}}
====Tbd====
+
====Entwickeln Sie Ihre Richtlinien zum Einsatz von Software-Komponenten====
{{Top_10_2010:ExampleBeginTemplate|year=2013}}
+
Um die Anzahl der, zu prüfenden Software-Komponenten und deren Versionen handhabbar zu halten, empfiehlt es sich, eine eigene Richtlinie dazu zu erstellen und durchzusetzen. Im Idealfall stellen Sie Ihren Entwicklern für bestimmte Aufgaben freigegebene Libraries zur Verfügung.
<span style="color: green;">'''tbd</span><br>
+
: <span style="color: green;">'''tbd</span><br>
+
::  <span style="color: green;">'''tbd</span><br>
+
{{Top_10_2010:ExampleEndTemplate}}
+
 
+
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=9|year=2013|language=de}}
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=9|year=2013|language=de}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 
+
* [[OWASP Dependency Check]]
 
* [[OWASP Good Component Practices Project]]
 
* [[OWASP Good Component Practices Project]]
 
+
* [http://mojo.codehaus.org/versions-maven-plugin Versions-Plugin für Maven]
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
 
* [https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf  The Unfortunate Reality of Insecure Libraries]
 
* [https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf  The Unfortunate Reality of Insecure Libraries]

Revision as of 07:33, 11 September 2013

BAUSTELLE! Hier entsteht das deutsche Wiki der OWASP Top 10 fuer Entwickler-2013

← A8-Cross-Site Request Forgery (CSRF)
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A10-Ungeprüfte Um- und Weiterleitungen →
A9 Benutzen von Komponenten mit bekannten Schwachstellen


Bedrohungsquelle
Angriffsvektor
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
Application Specific Ausnutzbarkeit
DURCHSCHNITTLICH
Verbreitung
SEHR HÄUFIG
Auffindbarkeit
SCHWIERIG
Auswirkung
MITTEL
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.
Mögliche Angriffsszenarien

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.

Wie kann ich 'Benutzen von Komponenten mit bekannten Schwachstellen' verhindern?

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.
[edit]

Verteidigungs-Option 1 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Erkennen aller verwendeten Software-Komponenten

Verschaffen Sie sich einen Überblick über alle, vom Programm benutzten Software-Komponenten, deren Abhängigkeiten (rekursive Abfrage der benutzten Komponenten), sowie den Versionsständen.
Beispiele für Tools, die Sie dabei unterstützen:

Verteidigungs-Option 2 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Sicherheits-(CERT-)Meldungen für die verwendeten Versionen prüfen

Um herauszufinden, ob diese Versionen von Schwachstellen betroffen sind, ist es notwendig, die oben genannten Schwachstellen-Datenbanken regelmäßig, in kurzen Abständen zu durchsuchen, sowie sich mithilfe von Mailing-Listen und weiteren Meldungen zeitnah über mögliche Lücken zu informieren.

Am einfachsten geht dies mithilfe von Tools:

Falls eine benutzte Komponente verwundbar ist, sollten Sie genau prüfen, ob Ihre Anwendung verwundbare Teile der Komponente nutzt und ob der Fehler Auswirkungen hat, um die Sie sich kümmern müssen.

Anmerkung:
Theoretisch sollte es einfach sein, herauszufinden, ob die Anwendung verwundbare Komponenten, oder Bibliotheken benutzt. Leider enthalten Berichte über Sicherheitslücken kommerzieller oder von Open-Source-Software nicht immer automatisch auswertbare, exakte Versions-Angaben der verwundbaren Komponenten. Ferner benutzen nicht alle Bibliotheken ein verständliches Versionsnummerierungs-Schema. Darüber hinaus werden nicht alle Schwachstellen an zentrale Schwachstellen-Datenbanken, wie CVE und NVD gemeldet.

Verteidigungs-Option 3 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Entwickeln Sie Ihre Richtlinien zum Einsatz von Software-Komponenten

Um die Anzahl der, zu prüfenden Software-Komponenten und deren Versionen handhabbar zu halten, empfiehlt es sich, eine eigene Richtlinie dazu zu erstellen und durchzusetzen. Im Idealfall stellen Sie Ihren Entwicklern für bestimmte Aufgaben freigegebene Libraries zur Verfügung.

Referenzen

OWASP

Andere

Verteidigungs-Option 1 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Tbd

tbd
tbd

Verteidigungs-Option 2 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Tbd

tbd

tbd
tbd
Verteidigungs-Option 3 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

Tbd

tbd

tbd
tbd
Referenzen

OWASP

  • tbd !!

Andere

  • tbd!!

Verteidigungs-Option 1 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

tbd Text

Verteidigungs-Option 2 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

tbd Text

Verteidigungs-Option 3 gegen 'Benutzen von Komponenten mit bekannten Schwachstellen':

tbd (ganze Breite) Text

Auswirkung(en) auf den Benutzer

Text

Wie kann ich 'Benutzen von Komponenten mit bekannten Schwachstellen' verhindern?

Text

Referenzen

← A8-Cross-Site Request Forgery (CSRF)
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

A10-Ungeprüfte Um- und Weiterleitungen →

© 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