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
Germany/Projekte/Top 10-2013-A9-Benutzen von Komponenten mit bekannten Schwachstellen
NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.
← A8-Cross-Site Request Forgery (CSRF) | A10-Ungeprüfte Um- und Weiterleitungen → |
Anwendungs- spezifisch |
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. He customizes the exploit as needed and executes 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/libraries are 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 range from minimal 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. |
Bin ich durch 'Nutzung von Komponenten mit bekannten Schwachstellen' verwundbar?
In theory, it ought to be easy to figure out if you are currently using any vulnerable components or libraries. Unfortunately, vulnerability reports for commercial or open source software 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. |
Wie kann ich 'Nutzung von Komponenten mit bekannten Schwachstellen' verhindern?
One option is not to use components that you didn’t write. But that’s not very realistic. Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical. Software projects should have a process in place to: Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
|
Mögliche Angriffsszenarien
Component vulnerabilities can cause almost any type of risk imaginable, ranging 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.
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. |
Referenzen
OWASP Andere
|
← A8-Cross-Site Request Forgery (CSRF) | A10-Ungeprüfte Um- und Weiterleitungen → |