This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

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

From OWASP
Jump to: navigation, search
m (Bei 'Top_10_2010:SummaryTableHeaderEndTemplate' den Parameter '|language=de' ergänzt)
(Updated according to OWASP Top10 2013 DE)
Line 25: Line 25:
 
   {{Top_10:SummaryTableTemplate|exploitability=2|prevalence=1|detectability=3|impact=2|language=de|year=2013}}
 
   {{Top_10:SummaryTableTemplate|exploitability=2|prevalence=1|detectability=3|impact=2|language=de|year=2013}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013|language=de}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013|language=de}}
−
     <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}}>Einige verwundbare Software-Komponenten (z.B. Bibliotheken von Frameworks) können von Tools erkannt und automatisch ausgenutzt werden. Dadurch steigt die Zahl der Bedrohungsquellen ins Unermessliche.
 
</td>
 
</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}}>Ein Angreifer erkennt Komponenten mit Schwachstellen mittels Scan, oder manueller Analyse. Er passt den Exploit an und führt den Angriff aus. Bei tief eingebetteten Komponenten ist dies schwieriger.
 
</td>
 
</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 colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>So gut wie jede Anwendung ist von diesem Problem betroffen, da die meisten Entwicklungs-Teams wenig darauf achten, dass die benutzten Komponenten bzw. Bibliotheken aktuell sind. Häufig kennen sie nicht einmal alle Komponenten, oder machen sich keine Gedanken über deren Version.<br/>Die rekursive Abhängigkeit von weiteren Bibliotheken verschlechtert die Situation weiter.
 
</td>
 
</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 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Die ganze Bandbreite von Schwachstellen ist möglich, inkl. Injection, Fehler in der Zugriffskontrolle, XSS usw. Die Auswirkungen können von minimal bis hin zur vollständigen Übernahme des Servers und der Daten reichen.
 
</td>
 
</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 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Betrachten Sie was jede einzelne Lücke der Anwendung für Ihren Geschäftsbetrieb bedeuten kann. Es kann vollkommen harmlos bis hin zu existenzbedrohend sein.
 
</td>
 
</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
Line 39: Line 39:
 
<!--- OWASP-TOP-10 ohne 'Bin ich verwundbar' ---->
 
<!--- OWASP-TOP-10 ohne 'Bin ich verwundbar' ---->
 
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=9|year=2013|language=de}}   
 
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=9|year=2013|language=de}}   
−
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.
+
Die durch Schwachstellen in Komponenten verursachten Lücken können von minimalen Risiken bis zu ausgeklügelter Malware führen, die für gerichtete Angriffe geeignet ist. Die Komponenten laufen meist mit allen Anwendungsrechten, wodurch ein Mangel in <u>jeder</u> Komponente schwerwiegend sein kann. Folgende <span style="color:red;">'''verwundbare'''</span> Komponenten wurden 22 Millionen Mal in 2011 heruntergeladen:
  
−
* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451  Apache CXF Authentication Bypass] – By failing to provide an identity token, attackers could invoke any web service with full permission.
+
* [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451  <span style="color:red;">Apache CXF Authentication Bypass</span>]&nbsp;&ndash;&nbsp;Durch das Fehlen eines Identifikations-Tokens, konnten Angreifer beliebige Web-Services aufrufen (Apache CXF ist ein Web-Service-Framework, nicht zu verwechseln mit dem Apache Application Server).
−
* [http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/  Spring Remote Code Execution]– Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.
+
* [http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/  <span style="color:red;">Spring Remote Code Execution</span>]&nbsp;&ndash;&nbsp;Der Missbrauch der ‘Expression Language‘ in Spring ermöglichte Angreifern das Ausführen von beliebigem Code auf dem 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.
+
Jede Anwendung, die eine der beiden Bibliotheken benutzt, ist angreifbar, da sie beide direkt von Benutzern ansprechbar sind. Bei anderen Bibliotheken kann dies schwieriger sein.
  
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=9|year=2013|language=de}}  
 
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=9|year=2013|language=de}}  
−
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.
+
Eine Option wäre, nur selbstgeschriebene Komponenten zu benutzen. Dies ist jedoch nicht sehr realistisch.
−
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.
+
Die meisten Framework-Projekte bringen keine Sicherheits-Patches für alte Versionen heraus. Meist werden die Lücken einfach in der nächsten Version behoben. Deshalb ist es sehr wichtig, diese neuen Versionen einzusetzen.  
−
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).
+
Software-Projekte sollten folgende Prozesse etabliert haben:
−
# Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
+
# Übersicht aller Komponenten und Versionen, die Sie direkt oder indirekt benutzen (z.B. [http://mojo.codehaus.org/versions-maven-plugin/ Versions-Plugin]).
−
# Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
+
# Laufendes Beobachten der Sicherheit dieser Komponenten mithilfe aktueller, frei zugänglichen Datenbanken, Mailing-Listen der Projekte und von Sicherheitsseiten.
 +
# Entwickeln Sie Richtlinien zum Einsatz von Komponenten, für die Entwicklung von Software, das Durchführen von Sicherheitstests und akzeptable Lizenzbedingungen.
 +
# Ggf. sollten Sie erwägen, Sicherheitsschichten einzuziehen, die Ihre Komponenten weiter härten (z.B. unbenutzte Funktionen sperren, oder Lücken schließen).
 +
 
 
{{Top_10:SubsectionTableEndTemplate}}
 
{{Top_10:SubsectionTableEndTemplate}}
  
Line 104: Line 107:
 
* [http://www.sonatype.com/content/download/1025/10060/file/sonatype_executive_security_brief_final.pdf  Addressing Security Concerns in Open Source Components]
 
* [http://www.sonatype.com/content/download/1025/10060/file/sonatype_executive_security_brief_final.pdf  Addressing Security Concerns in Open Source Components]
 
* [http://cve.mitre.org/  MITRE Common Vulnerabilities and Exposures]
 
* [http://cve.mitre.org/  MITRE Common Vulnerabilities and Exposures]
 +
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277 Beispiel einer 'Mass Assignment'-Schwachstelle, die inzwischen in ActiveRecord, ein 'Ruby on Rails-GEM', beboben wurde]
 
{{Top_10:SubsectionTableEndTemplate}} {{Top 10 DeveloperEdition:NavigationByHeadertab
 
{{Top_10:SubsectionTableEndTemplate}} {{Top 10 DeveloperEdition:NavigationByHeadertab
 
     |headertab=JAVA
 
     |headertab=JAVA
Line 194: Line 198:
 
{{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}}
−
* tbd !!
+
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 +
* [[OWASP SafeNuGet| OWASP SafeNuGet (für .NET Bibliotheken durch NuGet)]]
 +
* [[OWASP Dependency Check| OWASP Dependency Check (für Java, ...)]]
 +
* [[OWASP Good Component Practices Project]]
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2013|language=de}}
−
* tbd!!
+
* [http://mojo.codehaus.org/versions-maven-plugin Versions-Plugin für Maven]
 +
* [https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf  The Unfortunate Reality of Insecure Libraries]
 +
* [http://en.wikipedia.org/wiki/Open_source_software_security  Open Source Software Security]
 +
* [http://www.sonatype.com/content/download/1025/10060/file/sonatype_executive_security_brief_final.pdf  Addressing Security Concerns in Open Source Components]
 +
* [http://cve.mitre.org/  MITRE Common Vulnerabilities and Exposures]
 +
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277 Beispiel einer 'Mass Assignment'-Schwachstelle, die inzwischen in ActiveRecord, ein 'Ruby on Rails-GEM', beboben wurde]
 
{{Top_10:SubsectionTableEndTemplate}} {{Top 10 DeveloperEdition:NavigationByHeadertab
 
{{Top_10:SubsectionTableEndTemplate}} {{Top 10 DeveloperEdition:NavigationByHeadertab
 
     |headertab=.NET
 
     |headertab=.NET

Revision as of 16:50, 2 January 2015

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

Die Top-10-Risiken

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


Bedrohungsquellen
Angriffsvektoren
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
Anwendungs-
spezifisch		 Ausnutzbarkeit
DURCHSCHNITTLICH		 Verbreitung
SEHR HÄUFIG		 Auffindbarkeit
SCHWIERIG		 Auswirkung
MITTEL		 Anwendungs-/
Geschäftsspezifisch
Einige verwundbare Software-Komponenten (z.B. Bibliotheken von Frameworks) können von Tools erkannt und automatisch ausgenutzt werden. Dadurch steigt die Zahl der Bedrohungsquellen ins Unermessliche. Ein Angreifer erkennt Komponenten mit Schwachstellen mittels Scan, oder manueller Analyse. Er passt den Exploit an und führt den Angriff aus. Bei tief eingebetteten Komponenten ist dies schwieriger. So gut wie jede Anwendung ist von diesem Problem betroffen, da die meisten Entwicklungs-Teams wenig darauf achten, dass die benutzten Komponenten bzw. Bibliotheken aktuell sind. Häufig kennen sie nicht einmal alle Komponenten, oder machen sich keine Gedanken über deren Version.
Die rekursive Abhängigkeit von weiteren Bibliotheken verschlechtert die Situation weiter. 		Die ganze Bandbreite von Schwachstellen ist möglich, inkl. Injection, Fehler in der Zugriffskontrolle, XSS usw. Die Auswirkungen können von minimal bis hin zur vollständigen Übernahme des Servers und der Daten reichen. Betrachten Sie was jede einzelne Lücke der Anwendung für Ihren Geschäftsbetrieb bedeuten kann. Es kann vollkommen harmlos bis hin zu existenzbedrohend sein.
Mögliche Angriffsszenarien

Die durch Schwachstellen in Komponenten verursachten Lücken können von minimalen Risiken bis zu ausgeklügelter Malware führen, die für gerichtete Angriffe geeignet ist. Die Komponenten laufen meist mit allen Anwendungsrechten, wodurch ein Mangel in jeder Komponente schwerwiegend sein kann. Folgende verwundbare Komponenten wurden 22 Millionen Mal in 2011 heruntergeladen:

  • Apache CXF Authentication Bypass – Durch das Fehlen eines Identifikations-Tokens, konnten Angreifer beliebige Web-Services aufrufen (Apache CXF ist ein Web-Service-Framework, nicht zu verwechseln mit dem Apache Application Server).
  • Spring Remote Code Execution – Der Missbrauch der ‘Expression Language‘ in Spring ermöglichte Angreifern das Ausführen von beliebigem Code auf dem Server.

Jede Anwendung, die eine der beiden Bibliotheken benutzt, ist angreifbar, da sie beide direkt von Benutzern ansprechbar sind. Bei anderen Bibliotheken kann dies schwieriger sein.

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

Eine Option wäre, nur selbstgeschriebene Komponenten zu benutzen. Dies ist jedoch nicht sehr realistisch. Die meisten Framework-Projekte bringen keine Sicherheits-Patches für alte Versionen heraus. Meist werden die Lücken einfach in der nächsten Version behoben. Deshalb ist es sehr wichtig, diese neuen Versionen einzusetzen.

Software-Projekte sollten folgende Prozesse etabliert haben:

  1. Übersicht aller Komponenten und Versionen, die Sie direkt oder indirekt benutzen (z.B. Versions-Plugin).
  2. Laufendes Beobachten der Sicherheit dieser Komponenten mithilfe aktueller, frei zugänglichen Datenbanken, Mailing-Listen der Projekte und von Sicherheitsseiten.
  3. Entwickeln Sie Richtlinien zum Einsatz von Komponenten, für die Entwicklung von Software, das Durchführen von Sicherheitstests und akzeptable Lizenzbedingungen.
  4. Ggf. sollten Sie erwägen, Sicherheitsschichten einzuziehen, die Ihre Komponenten weiter härten (z.B. unbenutzte Funktionen sperren, oder Lücken schließen).
Verteidigungs-Option 1 gegen 'Nutzung 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 'Nutzung 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.
Verwenden des OWASP-Plugins im Maven-Build (pom.xml):

<reporting>
<plugins>
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>RELEASE</version>
<!-- Proxy configuration, if needed ----
<configuration>
<proxyUrl>yourserver</proxyUrl>
<proxyPort>yourport</proxyPort>
</configuration>
---------------------------------------->
</plugin>
</plugins>
</reporting>


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 'Nutzung 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 Software-Komponenten (z.B. Bibliotheken) zur Verfügung.

Referenzen

OWASP

Andere

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

Tbd

tbd
tbd

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

Tbd

tbd

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

Tbd

tbd

tbd
tbd
Referenzen

OWASP

  • tbd !!

Andere

  • tbd!!
Verteidigungs-Option 1 gegen 'Nutzung von Komponenten mit bekannten Schwachstellen':

Tbd

tbd
tbd

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

Tbd

tbd

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

Tbd

tbd

tbd
tbd
Referenzen

OWASP OWASP

Andere

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

tbd Text

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

tbd Text

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

tbd (ganze Breite) Text

Auswirkung(en) auf den Benutzer

Text

Wie kann ich 'Nutzung 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-2017 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
Retrieved from "https://wiki.owasp.org/index.php?title=Germany/Projekte/Top_10_fuer_Entwickler-2013/A9-Benutzen_von_Komponenten_mit_bekannten_Schwachstellen&oldid=187488"