-------------------------------------------------------------------------------- /_includes/risk_begin.html: -------------------------------------------------------------------------------- 1 | {%- comment -%} --------------------------------------------------------------------------- 2 | include: risk_begin.html 3 | description: Risk and likelyhood of Risk Factors by the Top 10 Category 4 | usage: {%- include risk_begin.html -%} 5 | page-parameters: 6 | page.year 2017 => used for styling and headlines 7 | page.exploitability: 1-3 => likelyhood of attack vectors 8 | page.prevalence: 1-3 => likelyhood of security weakness 9 | page.detectability: 1-3 => likelyhood of security weakness 10 | page.technical: 1-3 => severity for technical impacts 11 | ------------------------------------------------------------------------ {%- endcomment -%} 12 | {%- case page.year -%} 13 | {%- when 2017 -%} {%- assign th_color= '#4a1647' -%} 14 | {%- when 2013 -%} {%- assign th_color= '#4d953d' -%} 15 | {%- else -%} {%- assign th_color= '#4F81BD' -%} 16 | {%- endcase -%} 17 | 18 | 19 | {% case page.year %} 20 | {%- when 2017 -%} 21 | 22 | {%- else -%} 23 | 24 | 25 | {% endcase %} 26 | 27 | {% case page.year %} 28 | {%- when 2017 -%} 29 | 30 | {%- else -%} 31 | 32 | 33 | {% endcase %} 34 | 35 | 36 | 42 | {% include risk_factors_color.html likelihood=page.exploitability %} 43 | {%- include i18n.html token='exploitability' -%}: {{page.exploitability}} 44 | {% include risk_factors_color.html likelihood=page.prevalence -%} 45 | {%- include i18n.html token='prevalence' -%}: {{page.prevalence}} 46 | {% include risk_factors_color.html likelihood=page.detectability %} 47 | {%- include i18n.html token='detectability' -%}: {{page.detectability}} 48 | {% include risk_factors_color.html likelihood=page.technical %} 49 | {%- include i18n.html token='technical' -%}: {{ page.technical }} 50 | 55 | -------------------------------------------------------------------------------- /2017/Note_About_Risks.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 20 6 | title: Note About Risks 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Note_About_Risks.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Note_About_Risks 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html text="It's About the Risks that Weaknesses Represent" pos="firstWhole" -%} 20 | The Risk Rating methodology for the Top 10 is based on the [OWASP Risk Rating Methodology](/www-community/OWASP_Risk_Rating_Methodology). For each Top 10 category, we estimated the typical risk that each weakness introduces to a typical web application by looking at common likelihood factors and impact factors for each common weakness. We then ordered the Top 10 according to those weaknesses that typically introduce the most significant risk to an application. These factors get updated with each new Top 10 release as things change and evolve. 21 |
22 | The [OWASP Risk Rating Methodology](/www-community/OWASP_Risk_Rating_Methodology) defines numerous factors to help calculate the risk of an identified vulnerability. However, the Top 10 must talk about generalities, rather than specific vulnerabilities in real applications and APIs. Consequently, we can never be as precise as application owners or managers when calculating risks for their application(s). You are best equipped to judge the importance of your applications and data, what your threats are, and how your system has been built and is being operated. 23 |
24 | Our methodology includes three likelihood factors for each weakness (prevalence, detectability, and ease of exploit) and one impact factor (technical impact). The risk scales for each factor range from 1-Low to 3-High with terminology specific for each factor. The prevalence of a weakness is a factor that you typically don't have to calculate. For prevalence data, we have been supplied prevalence statistics from a number of different organizations (as referenced in the Acknowledgements on page 25), and we have aggregated their data together to come up with a Top 10 likelihood of existence list by prevalence. This data was then combined with the other two likelihood factors (detectability and ease of exploit) to calculate a likelihood rating for each weakness. The likelihood rating was then multiplied by our estimated average technical impact for each item to come up with an overall risk ranking for each item in the Top 10 (the higher the result the higher the risk). Detectability, Ease of Exploit, and Impact were calculated from analyzing reported CVEs that were associated with each of the Top 10 categories. 25 |
26 | **Note**: This approach does not take the likelihood of the threat agent into account. Nor does it account for any of the various technical details associated with your particular application. Any of these factors could significantly affect the overall likelihood of an attacker finding and exploiting a particular vulnerability. This rating does not take into account the actual impact on your business. *Your organization* will have to decide how much security risk from applications and APIs *the organization* is willing to accept given your culture, industry, and regulatory environment. The purpose of the OWASP Top 10 is not to do this risk analysis for you. 27 |
28 | The following illustrates our calculation of the risk for [A6:2017-Security Misconfiguration](A6_2017-Security_Misconfiguration). 29 |
30 | {% include risk_calculation_table.html %} 31 | {% include t10_subsection_end.html %} 32 | -------------------------------------------------------------------------------- /2017/Application_Security_Risks.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 4 6 | title: Application Security Risks 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Application_Security_Risks.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Application_Security_Risks 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html text="What are Application Security Risks?" pos="firstWhole" -%} 20 | Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention.
21 |
22 | ![Risks 2017 Image]({{site.baseurl}}/assets/images/Risks-2017.png){:width="80%"} 23 |
24 |
25 | Sometimes these paths are trivial to find and exploit, and sometimes they are extremely difficult. Similarly, the harm that is caused may be of no consequence, or it may put you out of business. To determine the risk to your organization, you can evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimate of the technical and business impact to your organization. Together, these factors determine your overall risk. 26 | 27 | {%- include t10_subsection.html text="What is My Risk?" pos="left" width='70%' -%} 28 | The [OWASP Top 10](https://owasp.org/www-project-top-ten) focuses on identifying the most serious web application security risks for a broad array of organizations. For each of these risks, we provide generic information about likelihood and technical impact using the following simple ratings scheme, which is based on the [OWASP Risk Rating Methodology](/www-community/OWASP_Risk_Rating_Methodology).
29 |
30 | {% include risk_factor_names_table.html %} 31 |
32 | In this edition, we have updated the risk rating system to assist in calculating the likelihood and impact of any given risk. For more details, please see [Note About Risks](Top_10-2017_Note_About_Risks). 33 |
34 | Each organization is unique, and so are the threat actors for that organization, their goals, and the impact of any breach. If a public interest organization uses a content management system (CMS) for public information and a health system uses that same exact CMS for sensitive health records, the threat actors and business impacts can be very different for the same software. It is critical to understand the risk to your organization based on applicable threat agents and business impacts. 35 |
36 | Where possible, the names of the risks in the Top 10 are aligned with [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) weaknesses to promote generally accepted naming conventions and to reduce confusion. 37 | 38 | {%- include t10_subsection.html text="References" pos="right" -%} 39 | **OWASP**
40 | * [OWASP Risk Rating Methodology](/www-community/OWASP_Risk_Rating_Methodology)
41 | * [Article on Threat/Risk Modeling (old wiki)](https://wiki.owasp.org/index.php/Application_Threat_Modeling)
42 |
43 | **External**
44 | * [ISO 31000: Risk Management Std](https://www.iso.org/iso-31000-risk-management.html)
45 | * [ISO 27001: ISMS](https://www.iso.org/isoiec-27001-information-security.html)
46 | * [NIST Cyber Framework (US)](https://www.nist.gov/cyberframework)
47 | * [ASD Strategic Mitigations (AU)](https://www.asd.gov.au/infosec/mitigationstrategies.htm)
48 | * [NIST CVSS 3.0](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator)
49 | * [Microsoft Threat Modelling Tool](https://aka.ms/tmt)
50 | {% include t10_subsection_end.html %} -------------------------------------------------------------------------------- /_includes/acknowlegements_individual_contributors_table.html: -------------------------------------------------------------------------------- 1 | {%- comment -%} --------------------------------------------------------------------------- 2 | include: acknowlegements_individual_contributors_table.html 3 | description: Table is included by the page '2017/Acknowledgements.md' 4 | usage: {%- include acknowlegements_individual_contributors_table.html -%} 5 | parameters: (none) 6 | ------------------------------------------------------------------------ {%- endcomment -%} 7 | 8 | 9 |

{%- include i18n.html token='threatAgents' %} / {% include i18n.html token='attackVectors' -%}		{%- include i18n.html token='threatAgents' -%}	{%- include i18n.html token='attackVectors' -%}	{%- include i18n.html token='securityWeakness' -%}		{%- include i18n.html token='impacts' -%}		{%- include i18n.html token='technicalImpacts' -%}	{%- include i18n.html token='businessImpacts' -%}
37 \| {%- case page.year -%} 38 \| {%- when 2017 -%} {%- include i18n.html token='appSpecific' -%} 39 \| {%- else -%} {%- include i18n.html token='applicationSpecific' -%} 40 \| {%- endcase -%} 41 \|	51 \| {%- case page.year -%} 52 \| {%- when 2017 -%} {%- include i18n.html token='businessQuestionmark' -%} 53 \| {%- else -%} {%- include i18n.html token='applicationBusinessSpecific' -%} 54 \| {%- endcase -%}

10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |

• ak47gen	• drwetter	• ilatypov	• neo00	• starbuck3000
• alonergan	• dune73	• irbishop	• nickthetait	• stefanb
• ameft	• ecbftw	• itscooper	• ninedter	• sumitagarwalusa
• anantshri	• einsweniger	• ivanr	• ossie-git	• taprootsec
• bandrzej	• ekobrin	• jeremylong	• PauloASilva	• tghosth
• bchurchill	• eoftedal	• jhaddix	• PeterMosmans	• TheJambo
• binarious	• frohoff	• jmanico	• pontocom	• thesp0nge
• bkimminich	• fzipi	• joaomatosf	• psiinon	• toddgrotenhuis
• Boberski	• gebl	• jrmithdobbs	• pwntester	• troymarshall
• borischen	• Gilc83	• jsteven	• raesene	• tsohlacol
• Calico90	• gilzow	• jvehent	• riramar	• vdbaan
• chrish	• global4g	• katyanton	• ruroot	• yohgaki
• clerkendweller	• grnd	• kerberosmansour	• securestep9
• D00gs	• h3xstream	• koto	• securitybits
• davewichers	• hiralph	• m8urnett	• SPoint42
• drkknight	• HoLyVieR	• mwcoates	• sreenathsasikumar

27 | 28 |

-------------------------------------------------------------------------------- /2017/Release_Notes.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 3 6 | title: Release Notes 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Release_Notes.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Release_Notes 15 | 16 | --- 17 | {%- include t10_subsection_begin.html -%} 18 | {%- include t10_subsection.html text="What changed from 2013 to 2017?" pos="firstWhole" -%} 19 | Change has accelerated over the last four years, and the OWASP Top 10 needed to change. We've completely refactored the OWASP Top 10, revamped the methodology, utilized a new data call process, worked with the community, re-ordered our risks, re-written each risk from the ground up, and added references to frameworks and languages that are now commonly used. Over the last few years, the fundamental technology and architecture of applications has changed significantly:
20 | * Microservices written in node.js and Spring Boot are replacing traditional monolithic applications. Microservices come with their own security challenges including establishing trust between microservices, containers, secret management, etc. Old code never expected to be accessible from the Internet is now sitting behind an API or RESTful web service to be consumed by Single Page Applications (SPAs) and mobile applications. Architectural assumptions by the code, such as trusted callers, are no longer valid.
21 | * Single page applications, written in JavaScript frameworks such as Angular and React, allow the creation of highly modular feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges.
22 | * JavaScript is now the primary language of the web with node.js running server side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client.
23 |
24 | **New issues, supported by data:**
25 | * [A4:2017-XML External Entities (XXE)](A4_2017-XML_External_Entities_(XXE)) is a new category primarily supported by [source code analysis security testing tools (SAST)](https://owasp.org/www-community/Source_Code_Analysis_Tools) data sets.
26 |
27 | **New issues, supported by the community:** 28 | We asked the community to provide insight into two forward looking weakness categories. After over 500 peer submissions, and removing issues that were already supported by data (such as Sensitive Data Exposure and XXE), the two new issues are:
29 | * [A8:2017-Insecure Deserialization](A8_2017-Insecure_Deserialization), which permits remote code execution or sensitive object manipulation on affected platforms.
30 | * [A10:2107-Insufficient Logging & Monitoring](A10_2017-Insufficient_Logging%2526Monitoring), the lack of which can prevent or significantly delay malicious activity and breach detection, incident response, and digital forensics.
31 |
32 | **Merged or retired, but not forgotten:**
33 | * [A4-Insecure Direct Object References](https://wiki.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References) and [A7-Missing Function Level Access Control](https://wiki.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control) merged into [A5:2017-Broken Access Control](A5_2017-Broken_Access_Control).
34 | * [A8-Cross-Site Request Forgery (CSRF)](https://wiki.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)), as many frameworks include [CSRF](/www-community/attacks/csrf) defenses, it was found in only 5% of applications.
35 | * [A10-Unvalidated Redirects and Forwards](https://wiki.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards), while found in approximately in 8% of applications, it was edged out overall by XXE.
36 | 37 | {% include t10_subsection_end.html %} 38 | 39 | {% include changes_from_2013_to_2017_table.html %} 40 | -------------------------------------------------------------------------------- /2017/de/Vorwort_der_deutschen_Version.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 1 6 | en: Foreword 7 | title: Vorwort der deutschen Version 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Foreword_de 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Vorwort der deutschen Version" -%} 20 | „Ist es nicht sonderbar, dass eine wörtliche Übersetzung fast immer eine schlechte ist? Und doch lässt sich alles gut übersetzen. Man sieht hieraus, wie viel es sagen will, eine Sprache ganz verstehen; es heißt, das Volk ganz kennen, das sie spricht.“ (G.C. Lichtenberg, „Sudelbücher“, 1800-1806).
21 | 22 | Die deutsche Version der OWASP Top 10 war genau das: eine Herausforderung, dem Ziel und dem Geist der Top 10 in deutscher Sprache gerecht zu werden. Hierbei wurden bei Bedarf auch kleinere Präzisierungen vorgenommen, die das Verständnis erleichtern. Wir verwenden daher bewusst nicht den Begriff „Übersetzung“, auch wenn es zu weiten Teilen genau das ist. Dinge ständig weiter zu treiben und kontinuierlich zu verbessern ist eben auch OWASP.
23 |
24 | Wir möchten Sie als Geschäftsführer, Manager, Anwendungs-Verantwortlicher, Prüfer oder Entwickler für Webanwendungssicherheit sensibilisieren und Ihnen den Einstieg in diese Thematik erleichtern.
25 | 26 | Dieses Dokument hilft Ihnen, eine neue Perspektive auf Ihre Anwendungen zu erhalten, um Sicherheitsfehler zu vermeiden und Risiken minimieren zu können. Einige englische Fachbegriffe wurden dabei beibehalten, weil sie auch im deutschen gebräuchlich sind.
27 | 28 | Wir wünschen Ihnen als Neueinsteiger oder Profi ein kurzweiliges Lesevergnügen und die (Bestätigung der) Erkenntnis, dass die Sicherheit ein kritischer Erfolgsfaktor für Webanwendungen ist.
29 | 30 | Fragen zur deutschen Version können Sie gerne direkt an [top10@owasp.de](mailto:top10@owasp.de) senden.
31 |
32 | Ihr deutschsprachiges Top 10-Team:
33 | * Christian Dresen
34 | * Alexios Fakos (Synopsys)
35 | * Louisa Frick (CycleSEC GmbH)
36 | * Torsten Gigler
37 | * Tobias Glemser
38 | * Dr. Frank Gut (Hochschule Furtwangen)
39 | * Dr. Ingo Hanke (SMA Solar Technology AG)
40 | * Dr. Thomas Herzog
41 | * Dr. Markus Koegel
42 | * Sebastian Klipper (CycleSEC GmbH)
43 | * Jens Liebau (bitinspect GmbH)
44 | * Ralf Reinhardt (sic[!]sec GmbH)
45 | * Martin Riedel (codecentric AG)
46 | * Michael Schaefer (SCHUTZWERK GmbH)
47 |
48 | Das Pdf zur deutschen Version der OWASP Top 10 finden Sie unter [https://owasp.org/www-chapter-germany/projekte/top_10/](/www-chapter-germany/projekte/top_10/). 49 | 50 | {%- include t10_subsection.html pos="whole" text="Stammtisch-Initiative des OWASP German Chapter" -%} 51 | In mehreren deutschen Städten gibt es [OWASP-Stammtische](https://owasp.org/www-chapter-germany/stammtische/), bei denen man sich in lockerer Runde trifft, um sich auszutauschen, nette Leute kennenzulernen oder ernsthafte Sicherheitsthemen zu diskutieren – meistens mit Vortrag.
52 | 53 | Aktive Stammtische gibt es (Stand Oktober 2020) in [Berlin](/www-chapter-germany/stammtische/berlin), [Dresden](/www-chapter-germany/stammtische/dresden/), [Frankfurt](/www-chapter-germany/stammtische/frankfurt/), [Hamburg](/www-chapter-germany/stammtische/hamburg/), [Hannover](/www-chapter-germany/stammtische/hannover/), [Heilbronn-Franken](/www-chapter-germany/stammtische/heilbronn_franken/), [Karlsruhe](/www-chapter-germany/stammtische/karlsruhe/), [Köln](/www-chapter-germany/stammtische/koeln/), [Leipzig](/www-chapter-germany/stammtische/leipzig/), [München](/www-chapter-germany/stammtische/muenchen/), [(ex) Ruhrpott](/www-chapter-germany/stammtische/ruhrpott/) und [Stuttgart](/www-chapter-germany/stammtische/stuttgart/). 54 | {%- include t10_subsection_end.html -%} 55 | -------------------------------------------------------------------------------- /2017/Foreword.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 1 6 | title: Foreword 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Foreword.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Foreword 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html text="Foreword" pos="firstWhole" -%} 20 | Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our software becomes increasingly complex, and connected, the difficulty of achieving application security increases exponentially. The rapid pace of modern software development processes makes the most common risks essential to discover and resolve quickly and accurately. We can no longer afford to tolerate relatively simple security problems like those presented in this OWASP Top 10. 21 |
22 | A great deal of feedback was received during the creation of the OWASP Top 10 - 2017, more than for any other equivalent OWASP effort. This shows how much passion the community has for the OWASP Top 10, and thus how critical it is for OWASP to get the Top 10 right for the majority of use cases. 23 |
24 | Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers, it has become the de facto application security standard. 25 |
26 | In this release, issues and recommendations are written concisely and in a testable way to assist with the adoption of the OWASP Top 10 in application security programs. We encourage large and high performing organizations to use the [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) if a true standard is required, but for most, the OWASP Top 10 is a great start on the application security journey. 27 |
28 | We have written up a range of suggested next steps for different users of the OWASP Top 10, including [What's Next for Developers](What%2527s_Next_for_Developers), [What's Next for Security Testers](What%2527s_Next_for_Security_Testers), [What's Next for Organizations](What%2527s_Next_for_Organizations), which is suitable for CIOs and CISOs, and [What's Next for Application Managers](What%2527s_Next_for_Application_Managers), which is suitable for application managers or anyone responsible for the lifecycle of the application. 29 |
30 | In the long term, we encourage all software development teams and organizations to create an application security program that is compatible with your culture and technology. These programs come in all shapes and sizes. Leverage your organization's existing strengths to measure and improve your application security program using the [Software Assurance Maturity Model](/www-project-samm). 31 |
32 | We hope that the OWASP Top 10 is useful to your application security efforts. Please don't hesitate to contact OWASP with your questions, comments, and ideas at our GitHub project repository:
33 | * [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues)
34 | You can find the OWASP Top 10 project and translations here:
35 | * [https://owasp.org/www-project-top-ten](https://owasp.org/www-project-top-ten)
36 |
37 | Lastly, we wish to thank the founding leadership of the OWASP Top 10 project, Dave Wichers and Jeff Williams, for all their efforts, and believing in us to get this finished with the community's help. Thank you! 38 |
39 |
40 | * Andrew van der Stock
41 | * Brian Glas
42 | * Neil Smithline
43 | * Torsten Gigler 44 | 45 | {%- include t10_subsection.html text="Project Sponsorship" pos="whole" -%} 46 | Thanks to [Autodesk](https://www.autodesk.com/) for sponsoring the OWASP Top 10 - 2017. 47 |
48 | Organizations and individuals that have provided vulnerability prevalence data or other assistance are listed on the [Acknowledgements page](Acknowledgements). 49 | {% include t10_subsection_end.html %} 50 | -------------------------------------------------------------------------------- /2017/de/Anmerkungen_zum_Risikobegriff.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 21 6 | en: Note_About_Risks 7 | title: Anmerkungen zum Risikobegriff 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Note_About_Risks 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Es geht um die Risiken, die Schwachstellen darstellen" -%} 20 | Die Methode der Risikobewertung der Top 10 basiert auf der **[OWASP Risk Rating Methode](/www-community/OWASP_Risk_Rating_Methodology)**. Für jede Kategorie der Top 10 schätzten wir das typische Risiko ab, das die entsprechende Schwachstelle in einer üblichen Webanwendung verursacht, indem wir die allgemeinen Wahrscheinlichkeits- und Auswirkungs-Faktoren für die jeweilige Schwachstelle betrachte-ten. Dann sortierten wir die Top 10 gemäß der Schwachstellen, die im Allgemeinen das größte Risiko für eine Anwendung darstellen. Die zugrundeliegenden Faktoren werden für jede Version der Top 10 geprüft und auf einen aktuellen Stand gebracht, da sich Dinge ständig ändern und entwickeln.
21 |
22 | Die **[OWASP Risk Rating Methode](/www-community/OWASP_Risk_Rating_Methodology)** definiert zahlreiche Faktoren, die helfen, das Risiko einer gefundenen Schwachstelle zu bewerten. Unabhängig davon ist die Top 10 allgemein gehalten und geht weniger auf spezifische Schwachstellen realer Anwendungen und APIs ein. Daher können wir niemals so genau wie derjenige sein, der das Risiko für seine eigene(n) Anwendung(en) abschätzt. Nur Sie selbst können am besten beurteilen, wie hoch der konkrete Schutzbedarf der Anwendung ist, wie wichtig die verarbeiteten Daten sind, wer oder was die Bedrohungsquellen darstellen und wie das System entwickelt wurde und betrieben wird.
23 |
24 | **Unsere Methodik** beinhaltet drei Wahrscheinlichkeits-Faktoren für jede Schwachstelle („Verbreitung“, „Auffindbarkeit“ und „Ausnutzbarkeit“) und einen Faktor zur „Technischen Auswirkung“. Die Gewichtung für jeden Faktor liegt zwischen „1-Niedrig“ und „3-Hoch“, in geeigneter Terminologie für den jeweiligen Faktor. Die „Verbreitung“ einer Schwachstelle muss üblicherweise nicht abgeschätzt werden. Hierfür haben uns verschiedene Organisationen Statistiken zur Verfügung gestellt (vgl. Kapitel [„Danksagung“](Danksagung)), die wir zu einer Top 10 Liste des Wahrscheinlichkeits-Faktors für die „Verbreitung“ zusammengestellt haben. Diese Daten wurden dann mit den beiden anderen Wahrscheinlichkeits-Faktoren für "Auffindbarkeit" und "Ausnutzbarkeit" gemittelt, um eine Bewertung der Eintrittswahrscheinlichkeit für jede Schwachstelle zu berechnen. Dieser Wert wurde im Folgenden mit unserem Schätzwert für die "Technische Auswirkung" der jeweiligen Schwachstelle multipliziert, um so zu einer Gesamtbewertung der Risiko-Einstufung zu gelangen (je höher das Ergebnis, desto höher das Risiko). "Auffindbarkeit", "Ausnutzbarkeit" und "Technischen Auswirkungen" wurden dabei durch die Analyse der CVEs, die für die jeweiligen Kategorie der Top 10 einschlägig sind, bestimmt.
25 |
26 | Es bleibt anzumerken, dass dieser Ansatz die Wahrscheinlichkeit der Bedrohungsquelle nicht mit berücksichtigt, ebenso wenig wie irgendwelche technischen Details der betroffenen Anwendung. Jeder dieser Faktoren könnte die Gesamtwahrscheinlichkeit, dass ein Angreifer eine bestimmte Schwachstelle findet und ausnutzt, signifikant beeinflussen. Dieses Bewer-tungsschema berücksichtig auch nicht die Auswirkungen auf das jeweilige Unternehmen und die Geschäftsprozesse. Die betroffene Organisation oder das Unternehmen wird für sich selbst entscheiden müssen, welches Sicherheitsrisiko durch (verwundbare) Anwendungen oder APIs sie oder es bereit ist zu tragen. Es ist nicht Sinn und Zweck der OWASP Top 10, Ihnen diese Risikoanalyse abzunehmen oder für Sie durchzuführen.
27 |
28 | Die folgende Darstellung zeigt die Berechnung des Risikos für **[A6:2017-Sicherheitsrelevante Fehlkonfiguration](A6_2017-Sicherheitsrelevante_Fehlkonfiguration)**.
29 | {% include risk_calculation_table.html %} 30 | {%- include t10_subsection_end.html -%} 31 | -------------------------------------------------------------------------------- /2017/de/Vorwort.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 2 6 | en: Foreword 7 | title: Vorwort 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Foreword 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Vorwort" -%} 20 | Seit längerer Zeit gefährdet unsichere Software unsere Finanz-, Gesundheits-, Verteidigungs-, Energie- sowie weitere kritische Infrastrukturen. Während unsere digitale Infrastruktur zunehmend komplex und vernetzt wird, wächst der Aufwand für Anwendungssicherheit exponentiell. Das schnelle Tempo moderner Softwareentwicklungsprozesse macht es dabei zwingend notwendig die häufigsten Schwachstellen schnell und zuverlässig zu entdecken. Wir können es uns schlicht nicht länger leisten, einfache Sicherheitsprobleme, wie die hier beschriebenen OWASP Top 10, zu ignorieren. 21 |
22 | Während der Erstellung dieser OWASP Top 10 - 2017 haben wir etliche Rückmeldungen erhalten. Weit mehr als es bei all den anderen OWASP Projekten die Regel ist. Dies zeigt, wie viel Leidenschaft die Community für die OWASP Top 10 hegt und belegt ebenfalls wie wichtig es für OWASP ist, eine für den überwiegenden Teil der Anwendungsfälle passende Top 10 zu erarbeiten. 23 |
24 | Auch wenn das ursprüngliche Ziel des OWASP Top 10 Projekt lediglich darin bestand, die Kenntnis über Sicherheitslücken unter Entwicklern und Managern zu verbreiten, so ist es inzwischen - der - defacto Sicherheitsstandard für Anwendungen geworden. 25 |
26 | In dieser Auflage, sind Sicherheitsrisiken und Empfehlungen nachvollziehbar präzisiert, um den Einsatz der OWASP Top 10 zu erleichtern. Wir fordern große oder besonders leistungsfähige Organisationen auf den [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) zu nutzen. Für die meisten ist die OWASP Top 10 jedoch ein guter erster Schritt auf der Reise nach mehr Anwendungssicherheit. 27 |
28 | Über die OWASP Top 10 hinaus existieren weitere Handreichungen für unterschiedliche Nutzer: So richtet sich Nächste Schritte für Software-Entwickler, Nächste Schritte für Sicherheitstester und Nächste Schritte für Organisationen primär an CIOs und CISOs, Nächste Schritte für Anwendungs-Verantwortliche eher an zuständige IT-Mitarbeiter. 29 |
30 | Langfristig möchten wir Sie ermuntern, Ihre eigene Richtlinie zur Anwendungssicherheit zu erstellen, die zu Ihrer Firmenkultur und Technologie passt. Eine solche Richtlinie kann es in allen möglichen Varianten geben. Nutzen Sie die bestehenden Kompetenzen in Ihrer Organisation, um die Anwendungssicherheit auch mit Hilfe des [Software Assurance Maturity Model (OWASP-SAMM)](/www-project-samm/)-Projekts zu verbessern. 31 |
32 | Wir hoffen, dass die OWASP Top 10 Ihnen bei der Verbesserung der Anwendungssicherheit helfen. Bei Fragen, Kommentare und Ideen besuchen Sie gerne die GitHub-Projektseite der englischen Original-Version:
33 | * [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues)
34 | Die OWASP Top 10 und deren Übersetzungen finden Sie unter:
35 | * [https://owasp.org/www-project-top-ten](https://owasp.org/www-project-top-ten)
36 |
37 | Zuletzt möchten wir uns bei den Initiatoren des OWASP Top 10 Projekts, Dave Wichers und Jeff Williams bedanken für alle ihr Bemühen, für ihr Vertrauen in uns und drauf das Projekt mit Hilfe der OWASP-Community zu einem guten Abschluss zu bringen. Vielen Dank! 38 |
39 | * Andrew van der Stock
40 | * Brian Glas
41 | * Neil Smithline
42 | * Torsten Gigler
43 | 44 | {%- include t10_subsection.html pos="whole" text="Attribution / Projekt Sponsoren" -%} 45 | Unser Dank geht an [Autodesk](https://www.autodesk.com) für ihre finanzielle Unterstützung zur Erstellung der OWASP Top 10 - 2017. 46 |
47 | Firmen und Personen, die Informationen zum Vorkommen von Schwachstellen beigesteuert haben oder die das Projekt auf andere Art und Weise unterstützt haben, sind auf der Seite '[Danksagung](Danksagung)' erwähnt. 48 | {%- include t10_subsection_end.html -%} 49 | -------------------------------------------------------------------------------- /_includes/risk_calculation_table.html: -------------------------------------------------------------------------------- 1 | {%- comment -%} --------------------------------------------------------------------------- 2 | include: risk_calculation_table.html 3 | description: Table is included by the pages '2017/Note_About_Risks.md' 4 | and '2017/de/Details zu den Risiko-Faktoren.md' 5 | usage: {%- include risk_calculation_table.html -%} 6 | parameters: (none) 7 | ------------------------------------------------------------------------ {%- endcomment -%} 8 |

9 | {%- case page.year -%} 10 | {%- when 2017 -%} {%- assign th_color= '#4a1647' -%} 11 | {%- when 2013 -%} {%- assign th_color= '#4d953d' -%} 12 | {%- else -%} {%- assign th_color= '#4F81BD' -%} 13 | {%- endcase -%} 14 | 15 | 16 | 17 | {% case page.year %} 18 | {%- when 2017 -%} 19 | 20 | {%- else -%} 21 | 22 | 23 | {% endcase %} 24 | 25 | {% case page.year %} 26 | {%- when 2017 -%} 27 | 28 | {%- else -%} 29 | 30 | 31 | {% endcase %} 32 | 33 | 34 | 35 | {% include risk_factors.html exploitability=3 prevalence=3 detectability=3 technical=2 width='16.5%' %} 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 50 | 51 | 52 | 53 | 54 | 57 | 58 |

{%- include i18n.html token='threatAgents' %} / {% include i18n.html token='attackVectors' -%}		{%- include i18n.html token='threatAgents' -%}	{%- include i18n.html token='attackVectors' -%}	{%- include i18n.html token='securityWeakness' -%}
{%- include i18n.html token='applicationSpecific' -%}	{%- include i18n.html token='businessSpecific' -%}
	3	3	3
	48 \| {%- include i18n.html token='likelihoodRating' -%}: 3.0 49 \| {%- include i18n.html token='likelihoodDescription' -%}			* 2
		55 \| {%- include i18n.html token='riskRanking' -%}: 6.0 56 \| {%- include i18n.html token='riskDescription' -%}

59 |

-------------------------------------------------------------------------------- /2017/de/Sicherheitsrisiken_fuer_Anwendungen.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 5 6 | en: Application_Security_Risks 7 | title: Sicherheitsrisiken für Anwendungen 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Application_Security_Risks 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Was sind Sicherheitsrisiken für Anwendungen?" -%} 20 | Angreifer können im Fall der Fälle viele unterschiedliche Angriffswege in einer Applikation ausnutzen, um Schaden für das Unternehmen oder die Organisation zu verursachen. Jeder einzelne dieser Wege stellt ein Risiko dar, das unter Umständen besondere Aufmerksamkeit bedarf. 21 |
22 | ![2017-Risks Image (de)]({{site.baseurl}}/assets/images/2017-Risks_de.png){:width="80%"} 23 |
24 | Manche dieser Angriffswege sind sehr leicht zu finden und auszunutzen, bei anderen kann es bedeutend schwer werden.
So unterschiedlich die Wege, so unterschiedliche sind auch die Auswirkungen: Einige sind kaum erwähnenswert, andere könnten letztlich zum Untergang des Unternehmens führen. Das individuelle Risiko kann stets nur unter Beachtung aller relevanter Faktoren abgeschätzt werden: Dabei handelt es sich um die jeweiligen Wahrscheinlichkeiten, die mit Bedrohungs-quellen, Angriffsvektoren und Schwachstellen verbunden sind. Diese werden mit den zu erwartenden technischen Auswirkungen sowie den Auswirkungen auf das Unternehmen kombiniert und bestimmen damit das individuelle Gesamtrisiko. 25 | 26 | {%- include t10_subsection.html pos="left" text="Was sind meine Risiken?" width='77%' -%} 27 | Die [OWASP Top 10](https://owasp.org/www-project-top-ten) beschreibt die schwerwiegendsten Risiken von Webanwendungen, die für ein breites Spektrum an Organisationen relevant sind. Für jedes dieser zehn Risiken stellen wir Informationen zu den beeinflussen-den Faktoren und den technischen Auswirkungen zur Verfügung. Zur Einschätzung verwenden wir folgendes Bewertungsschema auf Basis der [OWASP-Risk-Rating-Methode](/www-community/OWASP_Risk_Rating_Methodology):
28 |
29 | {% include risk_factor_names_table.html %} 30 |
31 | Mit der diesjährigen Ausgabe haben wir die Tabellen der Risikobewertung überarbeitet, um die Berechnung des Risiko nachvollziehbarer zu machen.
Für die Details der Verbesserungen sei hier auf den Abschnitt "[Anmerkungen zum Risikobegriff](Anmerkungen_zum_Risikobegriff)" verwiesen. 32 |
33 | Jedes Unternehmen und jede Organisation unterscheidet sich von allen anderen. Ebenso die Angreifer, deren Ziele und die Auswirkungen eines Sicherheitsvorfalles. Wenn beispielsweise eine Organisation ein Content-Management-System (CMS) für eine öffentliche Webseite nutzt, eine andere Firma das gleiche CMS nutzt, um darin (datenschutzrelevante) Patientendaten zu speichern, so können Sicherheitsvorfälle auch bei Einsatz gleicher Software sehr unterschiedliche Auswirkungen haben. Es ist also notwendig bei der Risikobewertung die Risiken, die sich aus der Tätigkeit des Unternehmens ergeben im Blick zu haben und diese auch wirklich umfassen zu verstehen.
34 | Die Namen der Risiken tragen – soweit möglich – die allgemein üblichen Bezeichnungen um das allgemeine Verständnis zu erhöhen und möglichst wenig zu verwirren. Siehe auch: [Common Weakness Enumeration](https://cwe.mitre.org/data/index.html) (CWE). 35 | 36 | {%- include t10_subsection.html pos="right" text="Referenzen" -%} 37 | **OWASP:**
38 | * [OWASP Risk Rating Methodology](/www-community/OWASP_Risk_Rating_Methodology)
39 | * [Article on Threat/Risk Modeling (altes Wiki)](https://wiki.owasp.org/index.php/Threat_Risk_Modeling)
40 |
41 | **Andere:**
42 | * [ISO 31000: Risk Management Std](https://www.iso.org/iso-31000-risk-management.html)
43 | * [ISO 27001: ISMS](https://www.iso.org/isoiec-27001-information-security.html)
44 | * [NIST Cyber Framework (US)](https://www.nist.gov/cyberframework)
45 | * [ASD Strategic Mitigations (AU)](https://www.asd.gov.au/infosec/mitigationstrategies.htm)
46 | * [NIST CVSS 3.0](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator)
47 | * [Microsoft Threat Modelling Tool](https://aka.ms/tmt)
48 | {%- include t10_subsection_end.html -%} 49 | -------------------------------------------------------------------------------- /2017/de/Neuerungen.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 4 6 | en: Release_Notes 7 | title: Neuerungen 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Release_Notes 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Was hat sich von Version 2013 zu 2017 verändert?" -%} 20 | Die Veränderungen haben in den letzten vier Jahren zugenommen, folglich wurden auch die OWASP Top 10 aktualisiert. Wir haben sie vollständig umgestaltet: die Methodik und den Prozess der Datenerhebung erneuert, mit der Community vollständig transparent zusammengearbeitet, die Risiken neu priorisiert, die Beschreibung der Risiken jeweils runderneuert und die Referenzen zu aktuellen Frameworks und Programmiersprachen angepasst. 21 | In den letzten Jahren hat sich die eingesetzte Technologie und Architektur von Anwendungen signifikant geändert:
22 | * Microservices, die in node.js und Spring Boot geschrieben werden, ersetzen traditionelle monolithische Anwendungen. Micro-services bringen neue Herausforderungen an die IT-Sicherheit mit, wie z.B. Vertrauensbeziehungen zwischen Microservices, Containern und das Management der Anmeldedaten. Alter Code, der nie dafür geschrieben wurde, aus dem Internet erreichbar zu sein, wird nun via APIs oder RESTful Web-Service nach außen geöffnet, z.B. mittels Single-Page-Anwendungen (SPA) oder für mobile Apps. Architekturelle Annahmen für den Code, wie z.B. vertrauenswürdige Nutzer, sind nicht mehr gültig.
23 | * Single-Page-Anwendungen, die in JavaScript-Frameworks, wie z.B. Angular oder React geschrieben wurden, unterstützen die Entwicklung von sehr modularen Clients mit einem großen Funktionsumfang. Das Verlagern von Funktionen auf den Client, die traditionell auf dem Server lagen, erzeugt weitere Herausforderungen für die IT-Sicherheit.
24 | * JavaScript ist inzwischen die meistgenutzte Sprache im Web, mit node.js auf den Servern und modernen Web-Frameworks wie Bootstrap, Electron, Angular oder React auf dem Client.
25 |
26 | **Neue Risiken, auf Basis der Datenerhebung:**
27 | * [A4:2017-XML External Entities (XXE)](A4_2017-XML External_Entities_(XXE)) ist eine neue Kategorie, die hauptsächlich per [Source-Code-Analyse-Sicherheits-Test-Tools](/www-community/Source_Code_Analysis_Tools) (SAST) gefunden wurde.
28 |
29 | **Neue Risiken, auf Basis der Expertenumfrage in der Community:**
30 | Wir haben die Community gebeten, zwei Risiken zu wählen, die zukünftig von größerer Bedeutung sein werden. Aufgrund der Ergebnisse der Expertenumfrage mit über 500 Einsendungen wurden nach dem Streichen von Risiken, die bereits aufgrund der Datenerhebung enthalten waren (z.B. Verlust der Vertraulichkeit sensibler Daten und XXE), folgende Risiken aufgenommen:
31 | * [**A8:2017-Unsichere Deserialisierung**](A8_2017-Unsichere_Deserialisierung), die ein externes Ausführen von beliebigem Code und die Manipulation von sensiblen Daten-Objekten auf betroffenen Plattformen ermöglicht.
32 | * [**A10:2017-Unzureichendes Logging & Monitoring**](A10_2017-Unzureichendes_Logging%2526Monitoring), das zum Übersehen oder zu beträchtlichen Verzögerungen beim Erkennen von bösartigen Aktivitäten oder digitalen Einbrüchen und dem Bearbeiten der Sicherheitsvorfälle sowie der digitalen Forensik führen kann.
33 |
34 | **Zusammengeführt oder aus den Top 10 ausgeschieden, jedoch nicht vergessen:**
35 | * [A4-Unsichere direkte Objektreferenzen](https://wiki.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References) und [A7-Fehlerhafte Autorisierung auf Anwendungsebene](https://wiki.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control) zusammengeführt (=vereint) zu [A5:2017-Fehler in der Zugriffskontrolle](A5_2017-Fehler_in_der_Zugriffskontrolle).
36 | * [A8-Cross-Site Request Forgery (CSRF)](https://wiki.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)), da viele Frameworks Maßnahmen gegen [CSRF](/www-community/attacks/csrf) beinhalten, wurde diese Kategorie nur noch in 5% der Anwendungen gefunden.
37 | * [A10-Ungeprüfte Um- und Weiterleitungen](https://wiki.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards), das noch in ca. 8% der Anwendungen auftrat, wurde insbes. durch XXE verdrängt.
38 | 39 | {% include t10_subsection_end.html %} 40 | 41 | {% include 2017/de/changes_from_2013_to_2017_table.html %} -------------------------------------------------------------------------------- /2017/Methodology_and_Data.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 22 6 | title: Top 10-2017 Methodology and Data 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Methodology_and_Data.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Methodology_and_Data 15 | 16 | --- 17 | {%- include t10_subsection_begin.html -%} 18 | {%- include t10_subsection.html text="Overview" pos="firstWhole" -%} 19 | At the OWASP Project Summit, active participants and community members decided on a vulnerability view, with up to two (2) forward looking vulnerability classes, with ordering defined partially by quantitative data, and partially by qualitative surveys. 20 | 21 | {%- include t10_subsection.html text="Industry Ranked Survey" pos="whole" -%} 22 | For the survey, we collected the vulnerability categories that had been previously identified as being “on the cusp” or were mentioned in feedback to 2017 RC1 on the Top 10 mailing list. We put them into a ranked survey and asked respondents to rank the top four vulnerabilities that they felt should be included in the OWASP Top 10 - 2017. The survey was open from Aug 2 – Sep 18, 2017. 516 responses were collected and the vulnerabilities were ranked.
23 |
24 | {% include industry_ranked_survey_table.html %} 25 |
26 | Exposure of Private Information is clearly the highest-ranking vulnerability, but fits very easily as an additional emphasis into the existing [A3:2017-Sensitive Data Exposure](A3_2017-Sensitive_Data_Exposure). Cryptographic Failures can fit within Sensitive Data Exposure. Insecure deserialization was ranked at number three, so it was added to the Top 10 as [A8:2017-Insecure Deserialization](Top_10-2017_A8-Insecure_Deserialization) after risk rating. The fourth ranked User-Controlled Key is included in [A5:2017-Broken Access Control](A5_2017-Broken_Access_Control); it is good to see it rank highly on the survey, as there is not much data relating to authorization vulnerabilities. The number five ranked category in the survey is Insufficient Logging and Monitoring, which we believe is a good fit for the Top 10 list, which is why it has become [A10:2017-Insufficient Logging&Monitoring](A10_2017-Insufficient_Logging%2526Monitoring). We have moved to a point where applications need to be able to define what may be an attack and generate appropriate logging, alerting, escalation and response. 27 | 28 | {%- include t10_subsection.html text="Public Data Call" pos="whole" -%} 29 | Traditionally, the data collected and analyzed was more along the lines of frequency data: how many vulnerabilities were found in tested applications. As is well known, tools traditionally report all instances found of a vulnerability and humans traditionally report a single finding with a number of examples. This makes it very difficult to aggregate the two styles of reporting in a comparable manner.
30 | 31 | For 2017, the incidence rate was calculated by how many applications in a given data set had one or more of a specific vulnerability type. The data from many larger contributors was provided in two views. The first was the traditional frequency style of counting every instance found of a vulnerability, while the second was the count of applications in which each vulnerability was found in (one or more times). While not perfect, this reasonably allows us to compare the data from Human Assisted Tools and Tool Assisted Humans. The raw data and analysis work is [available in GitHub](https://github.com/OWASP/Top10/tree/master/2017/datacall). We intend to expand on this with additional structure for future versions of the Top 10.
32 | 33 | We received 40+ submissions in the call for data, and because many were from the original data call that was focused on frequency, we were able to use data from 23 contributors covering ~114,000 applications. We used a one-year block of time where possible and identified by the contributor. The majority of applications are unique, though we acknowledge the likelihood of some repeat applications between the yearly data from Veracode. The 23 data sets used were either identified as tool assisted human testing or specifically provided incidence rate from human assisted tools. Anomalies in the selected data of 100%+ incidence were adjusted down to 100% max. To calculate the incidence rate, we calculated the percentage of the total applications there were found to contain each vulnerability type. The ranking of incidence was used for the prevalence calculation in the overall risk for ranking the Top 10. 34 | {% include t10_subsection_end.html %} -------------------------------------------------------------------------------- /2017/What%27s_Next_for_Developers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 16 6 | title: What's Next for Developers 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Developers.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Developers 15 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Developers.html 16 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Developers 17 | 18 | --- 19 | {%- include t10_subsection_begin.html -%} 20 | {%- include t10_subsection.html text="Establish & Use Repeatable Security Processes and Standard Security Controls" pos="firstWhole" -%} 21 | Whether you are new to web application security or already very familiar with these risks, the task of producing a secure web application or fixing an existing one can be difficult. If you have to manage a large application portfolio, this task can be daunting.
22 | To help organizations and developers reduce their application security risks in a cost-effective manner, OWASP has produced numerous free and open resources that you can use to address application security in your organization. The following are some of the many resources OWASP has produced to help organizations produce secure web applications and APIs. On the next page, we present additional OWASP resources that can assist organizations in verifying the security of their applications and APIs.
23 |
24 | {% include t10_subsection_inner_round_box.html 25 | topic='**Application Security Requirements:**' 26 | description="To produce a secure web application, you must define what secure means for that application. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) as a guide for setting the security requirements for your application(s). If you’re outsourcing, consider the [OWASP Secure Software Contract Annex](/www-community/OWASP_Secure_Software_Contract_Annex). 27 | **Note**: The annex is for US contract law, so please consult qualified legal advice before using the sample annex." 28 | %} 29 | {% include t10_subsection_inner_round_box.html 30 | topic='**Application Security Architecture:**' 31 | description="Rather than retrofitting security into your applications and APIs, it is far more cost effective to design the security in from the start. OWASP recommends the [OWASP Prevention Cheat Sheets](/www-project-cheat-sheets) as a good starting point for guidance on how to design security in from the beginning." 32 | %} 33 | {% include t10_subsection_inner_round_box.html 34 | topic='**Security Standard Controls:**' 35 | description="Building strong and usable security controls is difficult. Using a set of standard security controls radically simplifies the development of secure applications and APIs. The [OWASP Prevention Cheat Sheets](/www-project-cheat-sheets) is a good starting point for developers, and many modern frameworks now come with standard and effective security controls for authorization, validation, CSRF prevention, etc." 36 | %} 37 | {% include t10_subsection_inner_round_box.html 38 | topic='**Secure Development Lifecycle:**' 39 | description="To improve the process your organization follows when building applications and APIs, OWASP recommends the [OWASP Software Assurance Maturity Model (SAMM)](/www-project-samm). This model helps organizations formulate and implement a strategy for software security that is tailored to the specific risks facing their organization." 40 | %} 41 | {% include t10_subsection_inner_round_box.html 42 | topic='**Application Security Education:**' 43 | description="The OWASP Education Project provides training materials to help educate developers on web application security. For hands-on learning about vulnerabilities, try [OWASP WebGoat](/www-project-webgoat), [OWASP Juice Shop Project](/www-project-juice-shop) or the [OWASP Broken Web Applications Project](/www-project-broken-web-applications) [(old wiki)](https://wiki.owasp.org/index.php/OWASP_Broken_Web_Applications_Project). To stay current, come to an [OWASP AppSec Conference](/events), [OWASP Conference Training](/events), or local [OWASP Chapter meetings](/chapters)." 44 | %} 45 | There are numerous additional OWASP resources available for your use. Please visit the [OWASP Projects page](/projects), which lists all the Flagship, Labs, and Incubator projects in the OWASP project inventory. Most OWASP resources are available on our [website](https://owasp.org), and many OWASP documents can be ordered in [hardcopy or as eBooks](https://stores.lulu.com/owasp). 46 | {%- include t10_subsection_end.html -%} -------------------------------------------------------------------------------- /2017/What%27s_Next_for_Security_Testers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 17 6 | title: What's Next for Security Testers 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Security_Testers.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Security_Testers 15 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Security_Testers.html 16 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Security_Testers 17 | 18 | --- 19 | 20 | {%- include t10_subsection_begin.html -%} 21 | {%- include t10_subsection.html text="Establish Continuous Application Security Testing" pos="firstWhole" -%} 22 | Building code securely is important. But it’s critical to verify that the security you intended to build is actually present, correctly implemented, and used everywhere it is supposed to be. The goal of application security testing is to provide this evidence. The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio, and do it cost-effectively.
23 | Modern risks move quickly, so the days of scanning or penetration testing an application for vulnerabilities once every year or so are long gone. Modern software development requires continuous application security testing across the entire software development lifecycle. Look to enhance existing development pipelines with security automation that doesn’t slow development. Whatever approach you choose, consider the annual cost to test, triage, remediate, retest, and redeploy a single application, multiplied by the size of your application portfolio.
24 |
25 | {% include t10_subsection_inner_round_box.html 26 | topic='**Understand the Threat Model:**' 27 | description="Before you start testing, be sure you understand what’s important to spend time on. Priorities come from the threat model, so if you don’t have one, you need to create one before testing. Consider using [OWASP ASVS](/www-project-application-security-verification-standard) and the [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) as an input and don’t rely on tool vendors to decide what’s important for your business." 28 | %} 29 | {% include t10_subsection_inner_round_box.html 30 | topic='**Understand Your SDLC:**' 31 | description="Your approach to application security testing must be highly compatible with the people, processes, and tools you use in your software development lifecycle (SDLC). Attempts to force extra steps, gates, and reviews are likely to cause friction, get bypassed, and struggle to scale. Look for natural opportunities to gather security information and feed it back into your process." 32 | %} 33 | {% include t10_subsection_inner_round_box.html 34 | topic='**Testing Strategies:**' 35 | description="Choose the simplest, fastest, most accurate technique to verify each requirement. The [OWASP Security Knowledge Framework](/www-project-security-knowledge-framework) and [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard) can be great sources of functional and nonfunctional security requirements in your unit and integration testing. Be sure to consider the human resources required to deal with false positives from the use of automated tooling as well as the serious dangers of false negatives." 36 | %} 37 | {% include t10_subsection_inner_round_box.html 38 | topic='**Achieving Coverage and Accuracy:**' 39 | description="You don’t have to start out testing everything. Focus on what’s important and expand your verification program over time. That means expanding the set of security defenses and risks that are being automatically verified as well as expanding the set of applications and APIs being covered. The goal is to achieve a state where the essential security of all your applications and APIs is verified continuously." 40 | %} 41 | {% include t10_subsection_inner_round_box.html 42 | topic='**Clearly Communicate Findings:**' 43 | description="No matter how good you are at testing, it won’t make any difference unless you communicate it effectively. Build trust by showing you understand how the application works. Describe clearly how it can be abused without “lingo” and include an attack scenario to make it real. Make a realistic estimation of how hard the vulnerability is to discover and exploit, and how bad that would be. Finally, deliver findings in the tools development teams are already using, not PDF files." 44 | %} 45 | {%- include t10_subsection_end.html -%} -------------------------------------------------------------------------------- /2017/de/Methodik_und_Daten.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 23 6 | en: Methodology_and_Data 7 | title: Methodik und Daten 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Methodology_and_Data 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Übersicht" -%} 20 | Auf dem OWASP-Project-Summit 2017 entschieden sich aktive Teilnehmer und Community-Mitglieder für eine risikobasierten Reihenfolge mit bis zu zwei vorausschauend aufgenommenen Schwachstellenklassen. Die Reihenfolge wurde teilweise durch quantitative Daten und teilweise durch qualitative Erhebungen bestimmt. 21 | 22 | {%- include t10_subsection.html pos="whole" text="Rangliste auf Basis der Expertenumfrage in der Community" -%} 23 | Für die Umfrage haben wir die Schwachstellenkategorien gesammelt, die zuvor als "an der Schwelle" identifiziert oder im Feedback zu 2017 RC1 in der Top 10 Mailingliste erwähnt wurden. Wir haben sie in eine Rangliste aufgenommen und die Befragten gebeten, die vier wichtigsten Schwachstellen zu bewerten, die ihrer Meinung nach in die OWASP Top 10 - 2017 aufgenommen werden sollten. Die Umfrage war vom 2. August bis 18. September 2017 offen. 516 Antworten wurden ausgewertet und die Schwachstellen entsprechend geordnet.
24 |
25 | {% include industry_ranked_survey_table.html %} 26 |
27 | Die Offenlegung privater Informationen ist eindeutig die am höchsten eingestufte Schwachstelle, passt aber sehr gut als zusätzlicher Schwerpunkt in die bestehende **[A3:2017-Verlust der Vertraulichkeit sensibler Daten](A3_2017-Verlust_der_Vertraulichkeit_sensibler_Daten)**. Kryptographische Fehler können ebenfalls in diese Kategorie aufgenommen werden. Unsichere Deserialisierung wurde auf Platz drei eingestuft, so dass sie als **[A8:2017-Unsichere Deserialisierung](A8_2017-Unsichere_Deserialisierung)** in die Top 10 aufgenommen wurde. Das viertplatzierte Thema "User-Controlled Key" ist in **[A5:2017-Fehler in der Zugriffskontrolle](A5_2017-Fehler_in_der_Zugriffskontrolle)** mit enthalten. Es ist gut, dass es in der Umfrage einen hohen Rang einnimmt, da es bisher noch nicht viele Daten über Autorisierungsschwachstellen gibt. Das auf Platz 5 gelistete Thema ist "Insufficient Logging and Monitoring", passt unserer Meinung nach gut zu den Top 10 und wurde deshalb als **[A10:2017-Unzureichendes Logging & Monitoring](A10_2017-Unzureichendes_Logging%2526Monitoring)** aufgenommen. Wir sind an einem Punkt gelangt, an dem Anwendungen in der Lage sein müssen, mögliche Angriffsindizien zu definieren, eine geeignete Protokollierung zu erzeugen und eine angemessene Alarmierung, Eskalation und Reaktion auszulösen. 28 | 29 | {%- include t10_subsection.html pos="whole" text="Öffentlicher Aufruf: Wir brauchen Daten!" -%} 30 | Traditionell wurden bisher eher quantitative Daten gesammelt und analysiert: Wie viele Schwachstellen wurden in getesteten Anwendungen gefunden? Wie bekannt ist, melden Werkzeuge traditionell alle gefundenen Funde einer Schwachstelle. Menschen berichten traditionell über einen einzelnen Befund mit einer Reihe von Beispielen. Dies macht es sehr schwierig, die beiden Berichtsstile auf vergleichbare Weise zu aggregieren.
31 |
32 | In 2017 wurde die Häufigkeitsrate anhand der Anzahl der Anwendungen je Datensatz berechnet, die eine oder mehrere Schwachstellen eines bestimmten Typs aufwiesen. Die Daten von vielen größeren Mitwirkenden wurden auf zwei Arten zur Verfügung gestellt. Die erste war traditionell die Häufigkeit, bei der jedes gefundene Auftreten einer Schwachstelle gezählt wurde, während die zweite die Anzahl der Anwendungen ist, in denen die jeweilige Schwachstelle (ein oder mehrere Male) gefunden wurde. Obwohl nicht perfekt, erlaubt uns dies, die Daten von ‚Human Assisted Tools‘ (automatisierte Tests) und ‚Tool Assisted Humans‘ (manuelle Tests) zu vergleichen. Die Rohdaten und Analysearbeiten sind auf **[GitHub verfügbar](https://github.com/OWASP/Top10/tree/master/2017/datacall)**. Wir beabsichtigen, dies in den zukünftigen Versionen der Top 10 durch einen strukturierteren Ansatz weiter zu verbessern.
33 |
34 | Wir haben mehr als 40 Einreichungen für die Datenerhebung erhalten. Da viele von ihnen aus dem ursprünglichen Datenaufruf für den RC1 stammten, der sich auf die Auftrittshäufigkeit konzentrierte, haben wir die anwendungsbezogenen Daten von 23 Mitwirkenden verwendet, die ~114.000 Anwendungen umfassen. Wo immer möglich, haben wir einen einjährigen Zeitblock von Daten gleicher Anwendungen verwendet. Die Mehrzahl der gemeldeten Anwendungen sind einmal enthalten, obwohl es möglicherweise einige Dubletten bei den gemeldeten Anwendungen von Veracode gibt. Die 23 verwendeten Datensätze wurden als ‚‚Human Assisted Tools‘ bzw. ‚Tool Assisted Humans‘ klassifiziert. Anomalien in den ausgewählten Daten mit der Häufigkeit von über 100% wurden auf max. 100% angepasst. Um die Auftretungshäufigkeit zu berechnen, haben wir den Prozentsatz all der Anwendungen kalkuliert, bei denen festgestellt wurde, dass sie den jeweiligen Schwachstellentyp enthalten. Die Häufigkeit einer Schwachstelle ging bei der Berechnung des jeweiligen Risikowertes über den Risiko-Faktor 'Verbreitung' ein und wurde so in der Rangfolge der Top 10 berücksichtigt. 35 | {%- include t10_subsection_end.html -%} 36 | -------------------------------------------------------------------------------- /2017/de/Naechste_Schritte_fuer_Software-Entwickler.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 17 6 | en: What%27s_Next_for_Developers 7 | title: Nächste Schritte für Software-Entwickler 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/What%2527s_Next_for_Developers 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Umfassende Sicherheitsmaßnahmen etablieren und nutzen" -%} 20 | Egal ob man ein Neuling im Bereich der Webanwendungssicherheit ist oder schon mit den erläuterten Gefahren vertraut ist – die Entwicklung einer neuen sicheren Webanwendung oder das Absichern einer bereits existierenden kann sehr schwierig sein. Für die Betreuung eines großen Anwendungsportfolios kann das sehr abschreckend sein.
21 | Um Organisationen und Entwicklern dabei zu helfen Ihre Anwendungssicherheitsrisiken kostengünstig zu reduzieren, stellt OWASP zahlreiche kostenlose und frei zugängliche Ressourcen zur Verbesserung der Anwendungssicherheit zur Verfügung. Im Folgenden werden einige dieser OWASP-Ressourcen, die Organisationen helfen können sichere Webanwendungen oder APIs zu erstellen, vorgestellt. Auf der nächsten Seite stellen wir einige OWASP-Ressourcen vor, die Organisationen dabei helfen können Ihre Anwendungssicherheit zu überprüfen. 22 |
23 | 24 | {% include t10_subsection_inner_round_box.html 25 | topic='**Anwendungs-
sicherheits-
anforderungen:**' 26 | description=' 27 | Um eine sichere Web Anwendung zu erstellen ist es wichtig vorher zu definieren was "sicher" im Falle einer speziellen Anwendung bedeutet. OWASP empfiehlt dazu den [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) als Leitfaden zur Erstellung von Sicherheitsanforderungen. Bei Outsourcing der Anwendungsentwicklung empfiehlt sich der [OWASP Secure Software Contract Annex](/www-community/OWASP_Secure_Software_Contract_Annex) ([deutsch im alten Wiki](https://wiki.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex_German)).
Hinweis: Das Dokument ist ausschließlich als Orientierungshilfe anzusehen, es bezieht sich auf US-Recht. Konsultieren Sie in jedem Fall einen spezialisierten Anwalt, bevor Sie es benutzen.' 28 | %} 29 | {% include t10_subsection_inner_round_box.html 30 | topic='**Anwendungs-
sicherheits-
architektur:**' 31 | description=' 32 | Anstatt Sicherheit nachträglich in eine Anwendung oder API einzubauen, ist es kosteneffektiver, diese schon beim Design zu beachten. OWASP empfiehlt hierzu die [OWASP Prevention Cheat Sheets](/www-project-cheat-sheets) als einen guten Startpunkt, um die Anwendung von Anfang an sicher zu konstruieren.' 33 | %} 34 | {% include t10_subsection_inner_round_box.html 35 | topic='**Standardisierte
Sicherheits-
maßnahmen:**' 36 | description=' 37 | Die Entwicklung starker und anwendbarer Sicherheitsmaßnahmen ist nicht trivial. Standardisierte Sicherheitsmaßnahmen vereinfachen die Entwicklung sicherer Anwendungen oder APIs. [OWASP Proactive Controls](www-project-proactive-controls) ist ein guter Startpunkt für Entwickler. Viele moderne Frameworks enthalten heute schon standardmäßig effektive Sicherheitsprüfungen für Autorisierung, Validierung, CSRF-Schutz etc.' 38 | %} 39 | {% include t10_subsection_inner_round_box.html 40 | topic='**Sicherer
Entwicklungs-
zyklus:**' 41 | description=' 42 | Um den Prozess zur sicheren Anwendungserstellung in einer Organisation zu verbessern, empfiehlt OWASP das [OWASP Software Assurance Maturity Model (SAMM)](/www-project-samm). Das Modell hilft bei der Formulierung und Umsetzung einer Software Sicherheitsstrategie, die die spezifischen Risiken Ihrer eigenen Organisation berücksichtigt.' 43 | %} 44 | {% include t10_subsection_inner_round_box.html 45 | topic='**Trainings für
Anwendungs-
sicherheit:**' 46 | description=' 47 | Das [OWASP Education Project (altes Wiki)](https://wiki.owasp.org/index.php/Category:OWASP_Education_Project) bietet Trainingsunterlagen zur Schulung von Entwicklern im Bereich der Webanwendungssicherheit. Um praxisbezogene Erfahrungen über Schwachstellen zu sammeln empfiehlt die OWASP [OWASP WebGoat](/www-project-webgoat), [WebGoat.NET (altes Wiki)](https://wiki.owasp.org/index.php/Category:OWASP_WebGoat.NET), [OWASP NodeJS Goat](www-project-node.js-goat/), [OWASP Juice Shop Project](/www-project-juice-shop) oder das [OWASP Broken Web Applications Project](/www-project-broken-web-applications) [(altes Wiki)](https://wiki.owasp.org/index.php/OWASP_Broken_Web_Applications_Project). Um aktuell zu bleiben besuchen Sie die [OWASP AppSec Conference](/events), [OWASP Conference Training](/events), ein OWASP Training oder eines der lokalen [OWASP Chapter Meetings](/chapters) und [Stammtische](/www-chapter-germany/stammtische).' 48 | %} 49 | Es stehen zahlreiche weitere OWASP Ressourcen zur Verfügung. Besuchen Sie die [OWASP Projekt](/projects)-Übersicht, die eine Liste aller Flagship-, Lab- und Incubator-Projekte des OWASP Projektinventars bereitstellt. Viele OWASP Ressourcen sind auf unserer [Webseite](https:/owasp.org/) verfügbar und können auch in [Papierformat oder als eBook](https://stores.lulu.com/owasp) bestellt werden. 50 | {%- include t10_subsection_end.html -%} 51 | -------------------------------------------------------------------------------- /2017/What%27s_Next_for_Application_Managers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 19 6 | title: What's Next for Application Managers 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Application_Managers.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Application_Managers 15 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Application_Managers.html 16 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Application_Managers 17 | 18 | --- 19 | {%- include t10_subsection_begin.html -%} 20 | {%- include t10_subsection.html text="Manage the Full Application Lifecycle" pos="firstWhole" -%} 21 | Applications belong to the most complex systems humans regularly create and maintain. IT management for an application should be performed by IT specialists who are responsible for the overall IT lifecycle of an application. We suggest establishing the role of application manager as technical counterpart to the application owner. The application manager is in charge of the whole application lifecycle from the IT perspective, from collecting the requirements until the process of retiring systems, which is often overlooked.
22 |
23 | {% include t10_subsection_inner_round_box.html 24 | topic='**Requirements and Resource Management:**' 25 | description=" 26 | * Collect and negotiate the business requirements for an application with the business, including the protection requirements with regard to confidentiality, authenticity, integrity and availability of all data assets, and the expected business logic.
27 | * Compile the technical requirements including functional and nonfunctional security requirements.
28 | * Plan and negotiate the budget that covers all aspects of design, build, testing and operation, including security activities." 29 | %} 30 | {% include t10_subsection_inner_round_box.html 31 | topic='**Request for Proposals (RFP) and Contracting:**' 32 | description=" 33 | * Negotiate the requirements with internal or external developers, including guidelines and security requirements with respect to your security program, e.g. SDLC, best practices.
34 | * Rate the fulfillment of all technical requirements, including a planning and design phase.
35 | * Negotiate all technical requirements, including design, security, and service level agreements (SLA).
36 | * Adopt templates and checklists, such as [OWASP Secure Software Contract Annex](/www-community/OWASP_Secure_Software_Contract_Annex).
**Note**: The annex is for US contract law, so please consult qualified legal advice before using the sample annex." 37 | %} 38 | {% include t10_subsection_inner_round_box.html 39 | topic='**Planning and Design:**' 40 | description=" 41 | * Negotiate planning and design with the developers and internal shareholders, e.g. security specialists.
42 | * Define the security architecture, controls, and countermeasures appropriate to the protection needs and the expected threat level. This should be supported by security specialists.
43 | * Ensure that the application owner accepts remaining risks or provides additional resources.
44 | * In each sprint, ensure security stories are created that include constraints added for non-functional requirements." 45 | %} 46 | {% include t10_subsection_inner_round_box.html 47 | topic='**Deployment, Testing, and Rollout:**' 48 | description=' 49 | * Automate the secure deployment of the application, interfaces and all required components, including needed authorizations.
50 | * Test the technical functions and integration with the IT architecture and coordinate business tests.
51 | * Create "use" and "abuse" test cases from technical and business perspectives.
52 | * Manage security tests according to internal processes, the protection needs, and the assumed threat level by the application.
53 | * Put the application in operation and migrate from previously used applications if needed.
54 | * Finalize all documentation, including the change management data base (CMDB) and security architecture.' 55 | %} 56 | {% include t10_subsection_inner_round_box.html 57 | topic='**Operations and Change Management:**' 58 | description=" 59 | * Operations must include guidelines for the security management of the application (e.g. patch management).
60 | * Raise the security awareness of users and manage conflicts about usability vs. security.
61 | * Plan and manage changes, e.g. migrate to new versions of the application or other components like OS, middleware, and libraries.
62 | * Update all documentation, including in the CMDB and the security architecture, controls, and countermeasures, including any runbooks or project documentation." 63 | %} 64 | {% include t10_subsection_inner_round_box.html 65 | topic='**Retiring Systems:**' 66 | description=" 67 | * Any required data should be archived. All other data should be securely wiped.
68 | * Securely retire the application, including deleting unused accounts and roles and permissions.
69 | * Set your application's state to retired in the CMDB." 70 | %} 71 | {%- include t10_subsection_end.html -%} -------------------------------------------------------------------------------- /2017/de/Naechste_Schritte_fuer_Sicherheitstester.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 18 6 | en: What%27s_Next_for_Security_Testers 7 | title: Nächste Schritte für Sicherheitstester 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/What%2527s_Next_for_Security_Testers 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Establish Continuous Application Security Testing / Dauerhafte Tests der Anwendungssicherheit etablieren" -%} 20 | Die Erstellung von sicherem Code ist sehr wichtig. Noch wichtiger jedoch ist die Überprüfung, dass die Sicherheit, die in die Anwendung implementiert werden sollte, auch tatsächlich vorhanden sowie korrekt implementiert ist und an allen vorgesehenen Stellen eingesetzt wird. Das Ziel eines Anwendungssicherheitstest ist es, dies zu belegen. Diese Arbeit ist schwierig und komplex, zusätzlich üben moderne Entwicklungsprozesse, wie agile Entwicklung oder DevOps, einen erheblichen Druck auf traditionelle Vorgehensweisen und Tools aus. Daher empfehlen wir eindringlich, sich ausgiebig Gedanken darüber zu machen, wie man sich auf das Wesentliche und Wichtige innerhalb seines kompletten Anwendungsportfolios konzentrieren und das Testen kosteneffizient durchführen kann. 21 | Die aktuelle Risikolandschaft verändert sich schnell, sodass die Zeiten von einmal jährlich durchgeführten Scans oder Penetrationstests längst vorbei sind. Moderne Softwareentwicklung erfordert kontinuierliche Anwendungssicherheitstests über den gesamten Softwareentwicklungsprozess. Hierbei sollte im Auge behalten werden, wie existierende Entwicklungspipelines mit automatischen Sicherheitstests verbessert werden können, ohne die Entwicklung zu verlangsamen. Unabhängig von dem gewählten Ansatz müssen jährliche Kosten für Testen, Priorisieren (Triage), Korrigieren, erneutes Testen sowie erneutes Ausliefern einer einzelnen Anwendung multipliziert mit der Größe des Anwendungsportfolios berücksichtig werden. 22 |
23 | {% include t10_subsection_inner_round_box.html 24 | topic='**Das Angreifermodell verstehen:**' 25 | description=' 26 | Bevor Sie mit dem Testen beginnen, vergewissern Sie sich, dass Sie wissen, wofür Sie Zeit benötigen. Prioritäten ergeben sich aus dem Bedrohungsmodell. Falls noch kein Modell vorliegt, müssen Sie vor dem Testen ein solches erstellen. Erwägen Sie die Verwendung von [OWASP ASVS](/www-project-application-security-verification-standard) oder des [OWASP Testing Guides](/www-project-web-security-testing-guide) und verlassen Sie sich nicht auf Tool-Anbieter, um zu entscheiden, was für Ihr Unternehmen wichtig ist.' 27 | %} 28 | {% include t10_subsection_inner_round_box.html 29 | topic='**Den eigenen SDLC verstehen:**' 30 | description=' 31 | Ihr Ansatz für die Sicherheitsprüfung von Anwendungen muss mit den Personen, Prozessen und Tools, die Sie in Ihrem Software Development Lifecycle (SDLC) verwenden, in hohem Maße kompatibel sein. Versuche, zusätzliche Schritte, Gatter und Überprüfungen zu erzwingen, verursachen wahrscheinlich Spannungen, werden umgangen und sind schlecht skalierbar. Achten Sie auf natürliche Möglichkeiten, Sicherheitsinformationen zu sammeln und in Ihren Prozess einfließen zu lassen.' 32 | %} 33 | {% include t10_subsection_inner_round_box.html 34 | topic='**Test-Strategien:**' 35 | description=' 36 | Wählen Sie zur Verifikation jeder einzelnen Anforderung die einfachste, schnellste und genaueste Technik. Das [OWASP Security Knowledge Framework](/www-project-security-knowledge-framework) und der [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard) können eine gute Quelle für funktionale und nicht-funktionale Anforderungen für Ihre Unit- und Integrationstests sein. Stellen Sie sicher, dass Sie die erforderlichen Personal-ressourcen für den Umgang mit False-Positives aus der Verwendung automatisierter Werkzeuge sowie die ernsten Gefahren von False-Negatives berücksichtigen.' 37 | %} 38 | {% include t10_subsection_inner_round_box.html 39 | topic='**Abdeckung und Genauigkeit erreichen:**' 40 | description=' 41 | Es ist nicht erforderlich, zu Beginn alles zu testen. Fokussieren Sie sich auf das Wichtigste und erweitern Sie mit der Zeit Ihren Prüfungsplan. Dies beinhaltet sowohl das Erweitern der Sammlung von Sicherheitsmaßnahmen und Risiken, die automatisch verifiziert werden, als auch die Erweiterung der abgedeckten Anwendungen und APIs. Das Ziel ist es einen Status zu erreichen, in dem die essentielle Sicherheit aller Applikationen und APIs kontinuierlich verifiziert wird.' 42 | %} 43 | {% include t10_subsection_inner_round_box.html 44 | topic='**Ergebnisse klar kommunizieren:**' 45 | description=' 46 | Egal wie gut Sie im Testen sind, es macht keinen Unterschied bis Sie es effizient kommunizieren. Bauen Sie Vertrauen auf, indem Sie zeigen, dass Sie verstehen wie die Anwendung funktioniert. Beschreiben Sie klar und ohne Fachsprache, wie man das Gefundene ausnutzen kann und fügen Sie ein Angriffsszenario bei, um die möglichen Angriffe realitätsnah darzustellen. Machen Sie eine realistische Einschätzung, wie schwer es ist, die Schwachstelle zu finden sowie auszunutzen und wie schwerwiegend das wäre. Stellen Sie die Ergebnisse in den Tools bereit, die die Entwicklerteams benutzen, nicht als PDF-Dateien.' 47 | %} 48 | {%- include t10_subsection_end.html -%} 49 | -------------------------------------------------------------------------------- /2017/What%27s_Next_for_Organizations.md: -------------------------------------------------------------------------------- 1 | --- 2 | document: OWASP Top Ten 2017 3 | year: 2017 4 | order: 18 5 | title: What's Next for Organizations 6 | lang: en 7 | layout: full-width-document 8 | author: 9 | contributors: 10 | tags: OWASP Top Ten 2017, Top Ten 11 | redirect_from: 12 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Organizations.html 13 | - OWASP_Top_Ten_2017/Top_10-2017_What%2527s_Next_for_Organizations 14 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Organizations.html 15 | - OWASP_Top_Ten_2017/Top_10-2017_What%252527s_Next_for_Organizations 16 | 17 | --- 18 | 19 | {%- include t10_subsection_begin.html -%} 20 | {%- include t10_subsection.html text="Start Your Application Security Program Now" pos="firstWhole" -%} 21 | Application security is no longer optional. Between increasing attacks and regulatory pressures, organizations must establish effective processes and capabilities for securing their applications and APIs. Given the staggering amount of code in the numerous applications and APIs already in production, many organizations are struggling to get a handle on the enormous volume of vulnerabilities.
22 | OWASP recommends organizations establish an application security program to gain insight and improve security across their applications and APIs. Achieving application security requires many different parts of an organization to work together efficiently, including security and audit, software development, business, and executive management. Security should be visible and measurable, so that all the different players can see and understand the organization’s application security posture. Focus on the activities and outcomes that actually help improve enterprise security by eliminating or reducing risk. [OWASP SAMM](/www-project-samm) and the [OWASP Application Security Guide for CISOs: V1 (old wiki)](https://wiki.owasp.org/index.php/Application_Security_Guide_For_CISOs) is the source of most of the key activities in this list.
23 |
24 | {% include t10_subsection_inner_round_box.html 25 | topic='**Get Started:**' 26 | description=" 27 | * Document all applications and associated data assets. Larger organizations should consider implementing a Configuration Management Database (CMDB) for this purpose.
28 | * Establish an [application security program](/www-project-samm) and drive adoption.
29 | * Conduct a [capability gap analysis](/www-project-samm) comparing your organization to your peers to define key improvement areas and an execution plan.
30 | * Gain management approval and establish an [application security awareness campaign](/www-project-samm) for the entire IT organization." 31 | %} 32 | {% include t10_subsection_inner_round_box.html 33 | topic='**Risk Based Portfolio Approach:**' 34 | description=" 35 | * Identify the [protection needs](/www-project-samm) of your [application portfolio](/www-project-samm) from a business perspective. This should be driven in part by privacy laws and other regulations relevant to the data asset being protected.
36 | * Establish a [common risk rating model](/www-community/OWASP_Risk_Rating_Methodology) with a consistent set of likelihood and impact factors reflective of your organization's tolerance for risk.
37 | * Accordingly measure and prioritize all your applications and APIs. Add the results to your CMDB.
38 | * Establish assurance guidelines to properly define coverage and level of rigor required." 39 | %} 40 | {% include t10_subsection_inner_round_box.html 41 | topic='**Enable with a Strong Foundation:**' 42 | description=" 43 | * Establish a set of focused [policies and standards](/www-project-samm) that provide an application security baseline for all development teams to adhere to.
44 | * Define a [common set of reusable security controls](/www-project-security-knowledge-framework) that complement these policies and standards and provide design and development guidance on their use.
45 | * Establish an [application security training curriculum](/www-project-samm) that is required and targeted to different development roles and topics." 46 | %} 47 | {% include t10_subsection_inner_round_box.html 48 | topic='**Integrate Security into Existing Processes:**' 49 | description=" 50 | * Define and integrate [secure implementation and verification](/www-project-samm) activities into existing development and operational processes.
51 | * Activities include [threat modeling, secure design and design review, secure coding and code review, penetration testing](/www-project-samm), and remediation.
52 | * Provide subject matter experts and [support services for development and project teams](/www-project-samm) to be successful." 53 | %} 54 | {% include t10_subsection_inner_round_box.html 55 | topic='**Provide Management Visibility:**' 56 | description=" 57 | * Manage with metrics. Drive improvement and funding decisions based on the metrics and analysis data captured. Metrics include adherence to security practices and activities, vulnerabilities introduced, vulnerabilities mitigated, application coverage, defect ensity by type and instance counts, etc.
58 | * Analyze data from the implementation and verification activities to look for root cause and vulnerability patterns to drive strategic and systemic improvements across the enterprise. Learn from mistakes and offer positive incentives to promote improvements." 59 | %} 60 | {%- include t10_subsection_end.html -%} -------------------------------------------------------------------------------- /2017/Top_10.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 5 6 | title: 2017 Top 10 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10.html 14 | - OWASP_Top_Ten_2017/Top_10 15 | - OWASP_Top_Ten_2017/Top_10-2017_Top_10.html 16 | - OWASP_Top_Ten_2017/Top_10-2017_Top_10 17 | 18 | --- 19 | 20 | {%- include t10_subsection_begin.html -%} 21 | {%- include t10_subsection.html text="OWASP Top 10 Application Security Risks - 2017" pos="firstWhole" -%} 22 |
23 | {% include t10_subsection_inner_round_box.html 24 | topic='[A1:2017-Injection](A1_2017-Injection)' 25 | description="Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization." 26 | %} 27 | {% include t10_subsection_inner_round_box.html 28 | topic='[A2:2017-Broken Authentication](A2_2017-Broken_Authentication)' 29 | description="Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently." 30 | %} 31 | {% include t10_subsection_inner_round_box.html 32 | topic='[A3:2017-Sensitive Data Exposure](A3_2017-Sensitive_Data_Exposure)' 33 | description="Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser." 34 | %} 35 | {% include t10_subsection_inner_round_box.html 36 | topic='[A4:2017-XML External Entities (XXE)](A4_2017-XML_External_Entities_(XXE))' 37 | description="Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks." 38 | %} 39 | {% include t10_subsection_inner_round_box.html 40 | topic='[A5:2017-Broken Access Control](A5_2017-Broken_Access_Control)' 41 | description="Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc." 42 | %} 43 | {% include t10_subsection_inner_round_box.html 44 | topic='[A6:2017-Security Misconfiguration](A6_2017-Security_Misconfiguration)' 45 | description="Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion." 46 | %} 47 | {% include t10_subsection_inner_round_box.html 48 | topic='[A7:2017-Cross-Site Scripting (XSS)](A7_2017-Cross-Site_Scripting_(XSS))' 49 | description="XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites." 50 | %} 51 | {% include t10_subsection_inner_round_box.html 52 | topic='[A8:2017-Insecure Deserialization](A8_2017-Insecure_Deserialization)' 53 | description="Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks." 54 | %} 55 | {% include t10_subsection_inner_round_box.html 56 | topic='[A9:2017-Using Components with Known Vulnerabilities](A9_2017-Using_Components_with_Known_Vulnerabilities)' 57 | description="Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts." 58 | %} 59 | {% include t10_subsection_inner_round_box.html 60 | topic='[A10:2017-Insufficient Logging & Monitoring](A10_2017-Insufficient_Logging%2526Monitoring)' 61 | description="Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring." 62 | %} 63 | {% include t10_subsection_end.html %} 64 | -------------------------------------------------------------------------------- /2017/de/Naechste_Schritte_fuer_Anwendungs-Verantwortliche.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 20 6 | en: What%27s_Next_for_Application_Managers 7 | title: Nächste Schritte für Anwendungs-Verantwortliche 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/What%2527s_Next_for_Application_Managers 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Regeln Sie den vollständigen Lebenszyklus von Anwendungen" -%} 20 | Anwendungen gehören zu den komplexesten Systemen, die Menschen regelmäßig erschaffen und betreiben. Das IT-Management von Anwendungen sollte von IT-Spezialisten erfolgen, die für den vollständigen Lebenszyklus einer Anwendung verantwortlich sind. Wir empfehlen, die Rolle des Anwendungs-Verantwortlichen (Application Manager) als technisches Pendant zum Anwendungs-Eigentümer (Application Owner) zu etablieren. Der Anwendungs-Verantwortliche ist für den gesamten Lebenszyklus der Anwendung bezüglich der IT-Belange zuständig, von der Erhebung der fachlichen Anforderungen bis hin zur Außerbetriebnahme der Systeme. Letzteres wird häufig übersehen. 21 |
22 |
23 | {% include t10_subsection_inner_round_box.html 24 | topic='**Anforderungs- und Ressourcen-Management:**' 25 | description=' 26 | * Fachliche Anforderungen mit dem Fachbereich aufnehmen und vereinbaren, inkl. dem Schutzbedarf aller Daten-Assets in Bezug auf Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit, sowie der erwarteten Anwendungslogik.
27 | * Zusammenstellen der technischen Anforderungen inkl. funktionalen und nicht-funktionalen Anforderungen an die Sicherheit.
28 | * Planen und vereinbaren des Budgets, das alle Aspekte abdeckt, vom Design, Entwicklung, Testen bis hin zum Betrieb sowie die Sicherheitsmaßnahmen.' 29 | %} 30 | {% include t10_subsection_inner_round_box.html 31 | topic='**Ausschreibung und Vergabe:**' 32 | description=' 33 | * Die Anforderungen mit internen oder externen Entwicklern vereinbaren, inkl. Richtlinien, Sicherheits-Vorgaben und -Prozesse, wie z.B. sicherer Softwareentwicklungsprozess (SDLC), Best Practices.
* Bewerten Sie den Erfüllungsgrad der technischen Anforderungen inkl. Planungs- und Design-Phase.
* Vereinbaren Sie alle technischen Anforderungen inkl. Design, Sicherheit und Service-Level-Agreements (SLAs).
* Nutzen Sie Vorlagen und Checklisten, z.B. den [OWASP Secure Software Contract Annex](/www-community/OWASP_Secure_Software_Contract_Annex) ([deutsch im alten Wiki](https://wiki.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex_German)).
**Hinweis:** Das Dokument ist ausschließlich als Orientierungshilfe anzusehen, es bezieht sich auf US-Recht. Konsultieren Sie in jedem Fall einen spezialisierten Anwalt, bevor Sie es benutzen.' 34 | %} 35 | {% include t10_subsection_inner_round_box.html 36 | topic='**Planung und Design:**' 37 | description=' 38 | * Vereinbaren Sie die Planung und das Design der Anwendung mit den Entwicklern und internen Stakeholdern, z.B. Sicherheits-Spezialisten.
* Definieren Sie, unterstützt von Sicherheits-Spezialisten, die Sicherheits-Architektur, allgemeine vorbeugende Maßnahmen und gezielte Gegenmaßnahmen entsprechend dem Schutzbedarf und dem erwarteten Gefährdungsniveau.
* Stellen Sie sicher, dass der Anwendungseigentümer Restrisiken akzeptiert oder zusätzliches Budget bereitstellt.
* Stellen Sie sicher, dass es in jedem Sprint Sicherheits-Stories enthalten sind, die Auflagen für nicht-funktionale Anforderungen enthalten.' 39 | %} 40 | {% include t10_subsection_inner_round_box.html 41 | topic='**Deployment, Testen und Rollout:**' 42 | description=' 43 | * Automatisieren Sie das Deployment von Anwendungen, Schnittstellen und allen benötigten Komponenten mit sicheren Konfigurationsvoreinstellungen, inkl. der benötigen Berechtigungen.
* Testen Sie die technischen Funktionen und die Integration in die IT-Architektur, koordinieren Sie fachliche Tests.
* Erzeugen Sie “Use-" und “Abuse-Testfälle” aus technischer und fachlicher Sicht.
* Koordinieren Sie Sicherheits-Tests gemäß den internen Prozessen, dem Schutzbedarf und dem angenommenen Gefährdungsniveau der Anwendung.
* Nehmen Sie die Anwendung in Betrieb und übernehmen Sie ggf. Daten aus Altanwendungen.
* Vervollständigen Sie die Dokumentation, inkl. in der Configuration Management Data Base (CMDB) und die Sicherheitsarchitektur.' 44 | %} 45 | {% include t10_subsection_inner_round_box.html 46 | topic='**Betrieb und Change-Management:**' 47 | description=' 48 | * Das Betriebshandhandbuch muss Vorgaben für den sicheren Betrieb der Anwendung enthalten, z.B. Patchmanagement.
* Sensibilisieren Sie die Anwender für Sicherheitsaspekte und lösen Sie Konflikte zwischen Benutzbarkeit und Sicherheit.
* Planen und begleiten Sie Changes, z.B. Versionswechsel der Anwendung oder anderer Komponenten wie das Betriebssystem, Middleware und Bibliotheken.
* Aktualisieren Sie die vollständige Dokumentation, inkl. der CMDB, der Sicherheitsarchitektur, vorbeugende Maßnahmen, Gegenmaßnahmen und das Betriebshandbuch.' 49 | %} 50 | {% include t10_subsection_inner_round_box.html 51 | topic='**Außerbetriebnahme von Anwendungen:**' 52 | description=' 53 | * Weiterhin benötigte Daten sollten archiviert werden, alle anderen Daten sollten sicher gelöscht werden.
* Nehmen Sie die Anwendung auf sichere Weise außer Betrieb, inkl. dem Löschen von nicht mehr benötigten Benutzerkonten, Rollen und Rechten.
* Ändern Sie den Zustand der Anwendung in der CMDB auf "außer Betrieb".' 54 | %} 55 | {%- include t10_subsection_end.html -%} 56 | -------------------------------------------------------------------------------- /_includes/changes_from_2013_to_2017_table.html: -------------------------------------------------------------------------------- 1 | {%- comment -%} --------------------------------------------------------------------------- 2 | include: changes_from_2013_to_2017_table.html 3 | description: Table is included by the page '2017/Release_Notes.md' 4 | usage: {%- include changes_from_2013_to_2017_table.html -%} 5 | parameters: (none) 6 | ------------------------------------------------------------------------ {%- endcomment -%} 7 | 8 | 9 | 10 | 11 | 12 | 14 | 15 | 17 | 19 | 21 | 22 | 24 | 26 | 28 | 29 | 31 | 33 | 35 | 36 | 38 | 40 | 42 | 43 | 45 | 47 | 49 | 50 | 52 | 54 | 56 | 57 | 59 | 61 | 63 | 64 | 66 | 68 | 70 | 71 | 73 | 75 | 77 | 78 | 80 | 82 | 84 |

OWASP Top 10 - 2013 (Previous Version)	⇒	OWASP Top 10 - 2017 (Current Version) 13 \|
A1-Injection 16 \|	⇒ 18 \|	A1:2017-Injection 20 \|
A2-Broken Authentication and Session Management 23 \|	⇒ 25 \|	A2:2017-Broken Authentication 27 \|
A3-Cross-Site Scripting (XSS) 30 \|	⇘ 32 \|	A3:2017-Sensitive Data Exposure 34 \|
A4-Insecure Direct Object References - [Merged + A7] 37 \|	∪ 39 \|	A4:2017-XML External Entities (XXE) [NEW] 41 \|
A5-Security Misconfiguration 44 \|	⇘ 46 \|	A5:2017-Broken Access Control [Merged] 48 \|
A6-Sensitive Data Exposure 51 \|	⇗ 53 \|	A6:2017-Security Misconfiguration 55 \|
A7-Missing Function Level Access Control - [Merged + A4] 58 \|	∪ 60 \|	A7:2017-Cross-Site Scripting (XSS) 62 \|
A8-Cross-Site Request Forgery (CSRF) [Dropped] 65 \|	☒ 67 \|	A8:2017-Insecure Deserialization [NEW, Community] 69 \|
A9-Using Components with Known Vulnerabilities 72 \|	⇒ 74 \|	A9:2017-Using Components with Known Vulnerabilities 76 \|
A10-Unvalidated Redirects and Forwards [Dropped] 79 \|	☒ 81 \|	A10:2017-Insufficient Logging&Monitoring [NEW, Community] 83 \|

-------------------------------------------------------------------------------- /tab_data_2025.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Data_2025 3 | displaytext: Data 2025 4 | layout: col-sidebar 5 | tab: true 6 | order: 4 7 | tags: top10 8 | --- 9 | 10 | # OWASP Top 10 2025 Data Analysis Plan 11 | 12 | ## Goals 13 | To collect the most comprehensive dataset related to identified application vulnerabilities to-date to enable analysis for the Top 10 and other future research as well. This data should come from a variety of sources; security vendors and consultancies, bug bounties, along with company/organizational contributions. Data will be normalized to allow for level comparison between Human assisted Tooling and Tooling assisted Humans. 14 | 15 |
16 | 17 | ## Analysis Infrastructure 18 | Plan to leverage the OWASP Azure Cloud Infrastructure to collect, analyze, and store the data contributed. 19 | 20 |
21 | 22 | ## Contributions 23 | We plan to support both known and pseudo-anonymous contributions. The preference is for contributions to be known; this immensely helps with the validation/quality/confidence of the data submitted. If the submitter prefers to have their data stored anonymously and even go as far as submitting the data anonymously, then it will have to be classified as "unverified" vs. "verified". 24 | 25 | ### Verified Data Contribution 26 | Scenario 1: The submitter is known and has agreed to be identified as a contributing party.
27 | Scenario 2: The submitter is known but would rather not be publicly identified.
28 | Scenario 3: The submitter is known but does not want it recorded in the dataset.
29 | 30 | ### Unverified Data Contribution 31 | Scenario 4: The submitter is anonymous. (Should we support?) 32 | 33 | The analysis of the data will be conducted with a careful distinction when the unverified data is part of the dataset that was analyzed. 34 | 35 |
36 | 37 | ## Contribution Process 38 | There are a few ways that data can be contributed: 39 | 1. Email a CSV/Excel file with the dataset(s) to brian.glas@owasp.org 40 | 2. Upload a CSV/Excel file to [https://bit.ly/OWASPTop10Data](https://bit.ly/OWASPTop10Data) 41 | 42 | Template examples can be found in GitHub: [https://github.com/OWASP/Top10/tree/master/2025/Data](https://github.com/OWASP/Top10/tree/master/2025/Data) 43 | 44 |
45 | 46 | ## Contribution Period 47 | We plan to accept contributions to the new Top 10 until July 31, 2025, for data dating from 2021 to 2024. 48 | 49 |
50 | 51 | ## Data Structure 52 | The following data elements are **required** or optional.
53 | The more information provided the more accurate our analysis can be.
54 | At a bare minimum, we need the time period, total number of applications tested in the dataset, and the list of CWEs and counts of how many applications contained that CWE.
55 | If at all possible, please provide the additional metadata, because that will greatly help us gain more insights into the current state of testing and vulnerabilities.
56 | 57 | 58 | ### Metadata 59 | * Contributor Name (org or anon)
60 | * Contributor Contact Email
61 | * **Time period (2024, 2023, 2022, 2021)**
62 | * **Number of applications tested**
63 | * Type of testing (TaH, HaT, Tools)
64 | * Primary Language (code)
65 | * Geographic Region (Global, North America, EU, Asia, other)
66 | * Primary Industry (Multiple, Financial, Industrial, Software, ??)
67 | * Whether or not data contains retests or the same applications multiple times (T/F)
68 | 69 | ### CWE Data 70 | * **A list of CWEs w/ count of applications found to contain that CWE**
71 | 72 | _If at all possible, please provide core CWEs in the data, not CWE categories._
73 | _This will help with the analysis, any normalization/aggregation done as a part of this analysis will be well documented._ 74 | 75 | 76 | #### Note: 77 | If a contributor has two types of datasets, one from HaT and one from TaH sources, then it is recommended to submit them as two separate datasets.
78 | *HaT = Human assisted Tools (higher volume/frequency, primarily from tooling)*
79 | *TaH = Tool assisted Human (lower volume/frequency, primarily from human testing)*
80 | 81 |
82 | 83 | ## Survey 84 | Similarly to the Top Ten 2021, we plan to conduct a survey to identify up to two categories of the Top Ten that the community believes are important, but may not be reflected in the data yet. We plan to conduct the survey in early 2025, and will be utilizing Google forms in a similar manner as last time. The CWEs on the survey will come from current trending findings, CWEs that are outside the Top Ten in data, and other potential sources. 85 | 86 | 87 |
88 | 89 | ## Process 90 | At a high level, we plan to perform a level of data normalization; however, we will keep a version of the raw data contributed for future analysis. We will analyze the CWE distribution of the datasets and potentially reclassify some CWEs to consolidate them into larger buckets. We will carefully document all normalization actions taken so it is clear what has been done. 91 | 92 | We plan to calculate likelihood following the model we continued in 2021 to determine incidence rate instead of frequency to rate how likely a given app may contain at least one instance of a CWE. This means we aren't looking for the frequency rate (number of findings) in an app, rather, we are looking for the number of applications that had one or more instances of a CWE. We can calculate the incidence rate based on the total number of applications tested in the dataset compared to how many applications each CWE was found in. 93 | 94 | In addition, we will be developing base CWSS scores for the top 20-30 CWEs and include potential impact into the Top 10 weighting. 95 | 96 | Also, would like to explore additional insights that could be gleaned from the contributed dataset to see what else can be learned that could be of use to the security and development communities. 97 | -------------------------------------------------------------------------------- /2017/Introduction.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 2 6 | layout: full-width-document 7 | lang: en 8 | title: Introduction 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten 12 | redirect_from: 13 | - OWASP_Top_Ten_2017/Top_10-2017_Introduction.html 14 | - OWASP_Top_Ten_2017/Top_10-2017_Introduction 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html text="Welcome to the OWASP Top 10 - 2017!" pos="firstWhole" -%} 20 | This major update adds several new issues, including two issues selected by the community - [A8:2017-Insecure Deserialization](A8_2017-Insecure_Deserialization) and [A10:2017-Insufficient Logging & Monitoring](A10_2017-Insufficient_Logging%2526Monitoring). Two key differentiators from previous OWASP Top 10 releases are the substantial community feedback and extensive data assembled from dozens of organizations, possibly the largest amount of data ever assembled in the preparation of an application security standard. This provides us with confidence that the new OWASP Top 10 addresses the most impactful application security risks currently facing organizations.
21 | The OWASP Top 10-2017 is based primarily on 40+ data submissions from firms that specialize in application security and an industry survey that was completed by over 500 individuals. This data spans vulnerabilities gathered from hundreds of organizations and over 100,000 real-world applications and APIs. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact.
22 | A primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas, and provides guidance on where to go from here. 23 | 24 | {%- include t10_subsection.html text="Roadmap for future activities" pos="left" -%} 25 | **Don't stop at 10**. There are hundreds of issues that could affect the overall security of a web application as discussed in the [OWASP Developer's Guide](https://wiki.owasp.org/index.php/OWASP_Guide_Project) and the [OWASP Cheat Sheet Series](/www-project-cheat-sheets). These are essential reading for anyone developing web applications and APIs. Guidance on how to effectively find vulnerabilities in web applications and APIs is provided in the OWASP Testing Guide.
26 | **Constant change**. The OWASP Top 10 will continue to change. Even without changing a single line of your application's code, you may become vulnerable as new flaws are discovered and attack methods are refined. Please review the advice at the end of the Top 10 in What's Next For [Developers](What%2527s_Next_for_Developers), [Security Testers](What%2527s_Next_for_Security_Testers), [Organizations](What%2527s_Next_for_Organizations) and [Application Managers](What%2527s_Next_for_Application_Managers) for more information.
27 | **Think positive**. When you're ready to stop chasing vulnerabilities and focus on establishing strong application security controls, the [OWASP Proactive Controls](/www-project-proactive-controls) project provides a starting point to help developers build security into their applications and the [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) is a guide for organizations and application reviewers on what to verify.
28 | **Use tools wisely**. Security vulnerabilities can be quite complex and deeply buried in code. In many cases, the most cost-effective approach for finding and eliminating these weaknesses is human experts armed with advanced tools. Relying on tools alone provides a false sense of security and is not recommended.
29 | **Push left, right, and everywhere**. Focus on making security an integral part of your culture throughout your development organization. Find out more in the [OWASP Software Assurance Maturity Model (SAMM)](/www-project-samm).
30 | 31 | {%- include t10_subsection.html text="Attribution" pos="right" -%} 32 | We'd like to thank the organizations that contributed their vulnerability data to support the 2017 update. We received more than 40 responses to the call for data. For the first time, all the data contributed to a Top 10 release, and the full list of contributors, is publicly available. We believe this is one of the larger, more diverse collections of vulnerability data ever collected publicly.
33 | As there are more contributors than space here, we have created a [dedicated page](Acknowledgements) to recognize the contributions made. We wish to give heartfelt thanks to these organizations for being willing to be on the front lines by publicly sharing vulnerability data from their efforts. We hope this will continue to grow and encourage more organizations to do the same and possibly be seen as one of the key milestones of evidence based security. The OWASP Top 10 would not be possible without these amazing contributions.
34 | A big thank you to the more than 500 individuals who took the time to complete the industry ranked survey. Your voice helped determine two new additions to the Top 10. The additional comments, notes of encouragement, and criticisms were all appreciated. We know your time is valuable and we wanted to say thanks.
35 | We would like to thank those individuals who contributed significant constructive comments and time reviewing this update to the Top 10. As much as possible, we have listed them on the [Acknowledgements](Acknowledgements) page.
36 | And finally, we'd like to thank in advance all the translators out there who will translate this release of the Top 10 into numerous different languages, helping to make the OWASP Top 10 more accessible to the entire planet. 37 | {% include t10_subsection_end.html %} 38 | -------------------------------------------------------------------------------- /_includes/2017/de/changes_from_2013_to_2017_table.html: -------------------------------------------------------------------------------- 1 | {%- comment -%} --------------------------------------------------------------------------- 2 | include: 2017_changes_from_2013_to_2017_table_de.html 3 | description: Table is included by the page '2017/de/Neuerungen.md' 4 | usage: {%- include 2017_changes_from_2013_to_2017_table_de.html -%} 5 | parameters: (none) 6 | ------------------------------------------------------------------------ {%- endcomment -%} 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 17 | 19 | 21 | 22 | 24 | 26 | 28 | 29 | 31 | 33 | 35 | 36 | 38 | 40 | 42 | 43 | 45 | 47 | 49 | 50 | 52 | 54 | 56 | 57 | 59 | 61 | 63 | 64 | 66 | 68 | 70 | 71 | 73 | 75 | 77 | 78 | 80 | 82 | 84 |

OWASP Top 10 - 2013	⇒	OWASP Top 10 - 2017
A1-Injection 16 \|	⇒ 18 \|	A1:2017-Injection 20 \|
A2-Fehler in Authentifizierung und Session-Management 23 \|	⇒ 25 \|	A2:2017-Fehler in der Authentifizierung 27 \|
A3-Cross-Site Scripting (XSS) 30 \|	⇘ 32 \|	A3:2017-Verlust der Vertraulichkeit sensibler Daten 34 \|
A4-Unsichere direkte Objektreferenzen [mit A7] 37 \|	∪ 39 \|	A4:2017-XML External Entities (XXE) [NEU] 41 \|
A5-Sicherheitsrelevante Fehlkonfiguration 44 \|	⇘ 46 \|	A5:2017-Fehler in der Zugriffskontrolle [vereint] 48 \|
A6-Verlust der Vertraulichkeit sensibler Daten 51 \|	⇗ 53 \|	A6:2017-Sicherheitsrelevante Fehlkonfiguration 55 \|
A7-Fehlerhafte Autorisierung auf Anwendungsebene [mit A4] 58 \|	∪ 60 \|	A7:2017-Cross-Site Scripting (XSS) 62 \|
A8-Cross-Site Request Forgery (CSRF) 65 \|	☒ 67 \|	A8:2017-Unsichere Deserialisierung [NEU, Community] 69 \|
A9-Nutzung von Komponenten mit bekannten Schwachstellen 72 \|	⇒ 74 \|	A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen 76 \|
A10-Ungeprüfte Um- und Weiterleitungen 79 \|	☒ 81 \|	A10:2017-Unzureichendes Logging & Monitoring [NEU, Community] 83 \|

-------------------------------------------------------------------------------- /2017/A8_2017-Insecure_Deserialization.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 13 6 | title: A8:2017-Insecure Deserialization 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten, A8:2017 12 | exploitability: 1 13 | prevalence: 2 14 | detectability: 2 15 | technical: 3 16 | redirect_from: 17 | - OWASP_Top_Ten_2017/Top_10-2017_A8-Insecure_Deserialization.html 18 | - OWASP_Top_Ten_2017/Top_10-2017_A8-Insecure_Deserialization 19 | 20 | --- 21 | 22 | {% include risk_begin.html %} 23 | {%- include risk_description.html pos="firstLeft" -%} 24 | Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code. 25 | {%- include risk_description.html pos="mid" -%} 26 | This issue is included in the Top 10 based on an [industry survey](https://owasp.blogspot.com/2017/08/owasp-top-10-2017-project-update.html) and not on quantifiable data.
27 | Some tools can discover deserialization flaws, but human assistance is frequently needed to validate the problem. It is expected that prevalence data for deserialization flaws will increase as tooling is developed to help identify and address it. 28 | {%- include risk_description.html pos="right" -%} 29 | The impact of deserialization flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible.
30 | The business impact depends on the protection needs of the application and data. 31 | {%- include risk_end.html -%} 32 | 33 | {%- include t10_subsection_begin.html -%} 34 | {%- include t10_subsection.html token="isTheApplicationVulnerable" pos="firstLeft" -%} 35 | Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. This can result in two primary types of attacks:
36 | * Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.
37 | * Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.
38 | 39 | Serialization may be used in applications for:
40 | * Remote- and inter-process communication (RPC/IPC)
41 | * Wire protocols, web services, message brokers
42 | * Caching/Persistence
43 | * Databases, cache servers, file systems
44 | * HTTP cookies, HTML form parameters, API authentication tokens
45 | 46 | {%- include t10_subsection.html token="howToPrevent" pos="right" -%} 47 | The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following:
48 | * Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
49 | * Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
50 | * Isolating and running code that deserializes in low privilege environments when possible.
51 | * Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
52 | * Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
53 | * Monitoring deserialization, alerting if a user deserializes constantly.
54 | 55 | {%- include t10_subsection.html token="exampleAttackScenarios" pos="left" -%} 56 | **Scenario #1**: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the "R00" Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.
57 | 58 | **Scenario #2**: A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state:
59 | 60 | {% include code_red_begin.html -%} a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; {%- include code_red_end.html %} 61 | {% include code_red_begin.html -%} i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} {%- include code_red_end.html %} 62 | 63 | An attacker changes the serialized object to give themselves admin privileges:
64 | 65 | {% include code_red_begin.html -%} a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; {%- include code_red_end.html %} 66 | {% include code_red_begin.html -%} i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} {%- include code_red_end.html %} 67 | 68 | {%- include t10_subsection.html token="references" pos="right" -%} 69 | **OWASP**
70 | * [OWASP Cheat Sheet: Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)
71 | * [OWASP Proactive Controls: Validate All Inputs](/www-project-proactive-controls/v3/en/c5-validate-inputs)
72 | * [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard)
73 | * [OWASP AppSecEU 2016: Surviving the Java Deserialization Apocalypse](https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse)
74 | * [OWASP AppSecUSA 2017: Friday the 13th JSON Attacks](https://speakerdeck.com/pwntester/friday-the-13th-json-attacks)
75 |
76 | **External**
77 | * [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html)
78 | * [Java Unmarshaller Security](https://github.com/mbechler/marshalsec)
79 | * [OWASP AppSec Cali 2015: Marshalling Pickles](http://frohoff.github.io/appseccali-marshalling-pickles/) 80 | {% include t10_subsection_end.html %} 81 | -------------------------------------------------------------------------------- /2017/de/Einleitung.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 3 6 | en: Introduction 7 | title: Einleitung 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/Introduction 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Herzlich Willkommen zu OWASP Top 10 - 2017!" -%} 20 | Diese große Überarbeitung bringt mehrere neue Themen, darunter zwei von der OWASP-Community ausgewählte Aspekte – [A8:2017-Unsichere Deserialisierung](A8_2017-Unsichere_Deserialisierung) und [A10:2017-Unzureichendes Logging & Monitoring](A10_2017-Unzureichendes_Logging%2526Monitoring). Zwei wesentliche Unterschiede zu früheren OWASP Top 10-Ausgaben sind das starke Feedback durch die Community und eine umfangreiche Datenerhebung durch dutzende von Organisationen, vermutlich die größte die je für die Vorbereitung von Best-Practices für Anwendungssicherheit erhoben wurde. Dies gibt uns das Vertrauen, dass die neuen OWASP Top10 die Sicherheitsrisiken in Anwendungen mit den größten Auswirkungen für Organisationen adressiert.
21 | In erster Linie basiert OWASP Top 10 – 2017 auf über 40 Datenzulieferungen von auf Anwendungssicherheit spezialisierten Firmen und auf einer Befragung von über 500 Sicherheitsexperten. Die Datenzulieferung umfasst die Schwachstellen von hunderten von Firmen mit insgesamt über 100.000 existierenden Anwendungen und APIs. Die Top 10 Rangliste ergibt sich aus den Verbreitungsdaten in Verbindung mit abgestimmten Abschätzungen zu Ausnutzbarkeit, Nachweisbarkeit und Auswirkungen.
22 | Es ist ein wesentliches Ziel der OWASP Top 10, Entwickler, Designer, Architekten und Führungskräfte von Organisationen und Unternehmen über die Risiken der wichtigsten Schwachstellen von Webanwendungen aufzuklären. Die Top 10 stellen grundlegende Techniken zum Schutz gegen diese hochriskanten Probleme vor. Sie zeigen auch auf, wie es danach weitergeht.
23 | 24 | {%- include t10_subsection.html pos="left" text="Roadmap für weitere Aktivitäten" -%} 25 | **Hören Sie nicht bei 10 auf!** Es gibt hunderte von Problemen, die Auswirkungen auf die Gesamtsicherheit einer Webanwendung haben wie im [OWASP Developer's Guide](https://wiki.owasp.org/index.php/OWASP_Guide_Project) und in der [OWASP Cheat Sheet Series](/www-project-cheat-sheets). dargestellt. Diese sollten von jedem Entwickler von Webanwendungen und APIs gelesen werden. Ein Leitfaden zum effizienten Finden von Schwachstellen in Webanwendungen uns APIs liefert der [OWASP Security Testing Guide](/www-project-web-security-testing-guide).
26 |
27 | **Ständiger Wandel!** Die OWASP Top 10 befinden sich in stetem Wandel. Ohne eine einzige Codezeile in der Anwendung zu ändern kann sie angreifbar werden sobald neue Schwachstellen aufgedeckt und Angriffsmethoden verfeinert werden. Bitte berücksichtigen Sie die Ratschläge am Ende der Top 10 unter Nächste Schritte für [Entwickler](Naechste_Schritte_fuer_Software-Entwickler), [Sicherheitstester](Naechste_Schritte_fuer_Sicherheitstester), [Organisationen](Naechste_Schritte_fuer_Organisationen) und [Anwendungs-Verantwortliche](Naechste_Schritte_fuer_Anwendungs-Verantwortliche) für mehr Informationen.
28 |
29 | **Denke positiv!** Wenn Sie bereit sind, das bloße Reagieren auf Schwachstellen zu beenden und stattdessen den Fokus auf die Implementierung von starken Sicherheitsfunktionen in der Anwendung legen wollen, ist das [OWASP Proactive Controls](/www-project-proactive-controls)-Projekt ein guter Startpunkt für Entwickler, um Sicherheit in ihre Anwendungen einzubauen. Der [OWASP Application Security Verification Standard (ASVS)](/www-project-application-security-verification-standard) ist ein Leitfaden für Organisationen und Prüfer von Anwendungen.
30 |
31 | **Nutze Tools mit Bedacht!** Sicherheitslücken können sehr komplex und versteckt im Code sein. Oft ist zum Finden und Beseitigen dieser Lücken der Einsatz von Experten mit Profi-Tools am kosteneffektivsten. Das alleinige Vertrauen auf Tools gibt ein trügerisches Sicherheitsgefühl und wird nicht empfohlen.
32 |
33 | **Schauen Sie über den Tellerrand!** Machen Sie Sicherheit zu einem integrierten Bestandteil Ihrer IT-Organisation. Informieren Sie sich über das [OWASP Software Assurance Maturity Model (SAMM)](/www-project-samm). 34 | 35 | {%- include t10_subsection.html pos="right" text="Danksagung" -%} 36 | Unser Dank gilt den Firmen für das Bereitstellen der Daten über Sicherheitslücken für die 2017-Aktualisierung. Wir erhielten mehr als 40 Antworten auf unseren Aufruf zur Datenerhebung. Zum ersten Mal sind alle zu dem neuen Release beigesteuerten Daten und die vollständige Liste der Mitwirkenden öffentlich einsehbar. Wir denken, dass dies eine der größeren vielfältigeren Schwachstellensammlungen ist, die je öffentlich gesammelt wurden.
37 |
38 | Aus Platzgründen werden die beitragenden Firmen auf einer [eigenen Seite](Danksagung) gewürdigt. Wir möchten diesen 39 | Organisationen herzlichst dafür danken, dass sie ganz vorne dabei sind und die gesammelten Schwachstellen öffentlich zur Verfügung gestellt haben. Wir hoffen, das wird sich weiterentwickeln und weitere Organisationen ermutigen diese Richtung zu gehen mit dem Ziel eine nachweisbaren Sicherheit. OWASP Top 10 wäre nicht möglich ohne diese fantastischen Beiträge.
40 |
41 | Ein großer Dank geht an über 500 Einzelpersonen die sich die Zeit für die Expertenumfrage nahmen. Ihre Stimme half bei der Aufnahme von zwei neuen Risiken in die OWASP Top 10. Die Kommentare, Ermutigungen und Kritikpunkte waren durchgehend willkommen. Wir wissen Ihre Zeit ist wertvoll und wir möchten Ihnen dafür danken.
42 |
43 | Wir wollen uns bei jenen Personen bedanken, die in besonderem Maße konstruktive Kommentare und Zeit für den Review dieses Updates beigesteuert haben. So weit wie möglich sind sie auf der Seite ['Danksagung'](Danksagung) aufgeführt.
44 |
45 | Abschließend danken wir im Voraus allen Übersetzern dort draußen, die auf Grundlage diese Ausgabe eine neue Version der [Top 10 in zahlreichen Sprachen](/www-project-top-ten/#div-translation_efforts) erstellen, um die OWASP Top 10 auf dem ganzen Planet leichter zugänglich zu machen.
46 | {%- include t10_subsection_end.html -%} 47 | -------------------------------------------------------------------------------- /2017/de/Top_10.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 6 6 | en: Top_10 7 | title: 2017 Top 10 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | 14 | --- 15 | 16 | {%- include t10_subsection_begin.html -%} 17 | {%- include t10_subsection.html pos="firstWhole" text="OWASP Top 10 Risiken für die Anwendungssicherheit – 2017" -%} 18 |
19 | 20 | {% include t10_subsection_inner_round_box.html 21 | topic='**[A1:2017-Injection](A1_2017-Injection):**' 22 | description=' 23 | Injection-Schwachstellen, wie beispielsweise SQL-, OS- oder LDAP-Injection, treten auf, wenn nicht vertrauenswürdige Daten von einem Interpreter als Teil eines Kommandos oder einer Abfrage verarbeitet werden. Ein Angreifer kann Eingabedaten dann so manipulieren, dass er nicht vorgesehene Kommandos ausführen oder unautorisiert auf Daten zugreifen kann.' 24 | %} 25 | {% include t10_subsection_inner_round_box.html 26 | topic='**[A2:2017-Fehler in der Authentifizierung](A2_2017-Fehler_in_der_Authentifizierung):**' 27 | description=' 28 | Anwendungsfunktionen, die im Zusammenhang mit Authentifizierung und Session-Management stehen, werden häufig fehlerhaft implementiert. Dies erlaubt es Angreifern, Passwörter oder Session-Token zu kompromittieren oder die entsprechenden Schwachstellen so auszunutzen, dass sie die Identität anderer Benutzer vorübergehend oder dauerhaft annehmen können.' 29 | %} 30 | {% include t10_subsection_inner_round_box.html 31 | topic='**[A3:2017-Verlust der Vertraulichkeit sensibler Daten](A3_2017-Verlust_der_Vertraulichkeit_sensibler_Daten):**' 32 | description=' 33 | Viele Anwendungen schützen sensible Daten, wie personenbezogene Informationen und Finanz- oder Gesundheitsdaten, nicht ausreichend. Angreifer können diese Daten auslesen oder modifizieren und mit ihnen weitere Straftaten begehen (Kreditkartenbetrug, Identitätsdiebstahl etc.). Vertrauliche Daten können kompromittiert werden, wenn sie nicht durch Maßnahmen, wie Verschlüsselung gespeicherter Daten und verschlüsselte Datenübertragung, zusätzlich geschützt werden. Besondere Vorsicht ist beim Datenaustausch mit Browsern angeraten.' 34 | %} 35 | {% include t10_subsection_inner_round_box.html 36 | topic='**[A4:2017-XML External Entities (XXE)](A4_2017-XML_External_Entities_(XXE)):**' 37 | description=' 38 | Viele veraltete oder schlecht konfigurierte XML Prozessoren berücksichtigen Referenzen auf externe Entitäten innerhalb von XML-Dokumenten. Dadurch können solche externen Entitäten dazu eingesetzt werden, um mittels URI Datei-Handlern interne Dateien oder File-Shares offen-zulegen oder interne Port-Scans, Remote-Code-Executions oder Denial-of-Service Angriffe auszuführen.' 39 | %} 40 | {% include t10_subsection_inner_round_box.html 41 | topic='**[A5:2017-Fehler in der Zugriffskontrolle](A5_2017-Fehler_in_der_Zugriffskontrolle):**' 42 | description=' 43 | Häufig werden die Zugriffsrechte für authentifizierte Nutzer nicht korrekt um- bzw. durchgesetzt. Angreifer können entsprechende Schwachstellen ausnutzen, um auf Funktionen oder Daten zuzugreifen, für die sie keine Zugriffsberechtigung haben. Dies kann Zugriffe auf Accounts anderer Nutzer sowie auf vertrauliche Daten oder aber die Manipulation von Nutzerdaten, Zugriffsrechten etc. zur Folge haben.' 44 | %} 45 | {% include t10_subsection_inner_round_box.html 46 | topic='**[A6:2017-Sicherheitsrelevante Fehlkonfiguration](A6_2017-Sicherheitsrelevante_Fehlkonfiguration):**' 47 | description=' 48 | Fehlkonfigurationen von Sicherheitseinstellungen sind das am häufigsten auftretende Problem. Ursachen sind unsichere Standardkonfigurationen, unvollständige oder ad-hoc durchgeführte Konfigurationen, ungeschützte Cloud-Speicher, fehlkonfigurierte HTTP-Header und Fehleraus-gaben, die vertrauliche Daten enthalten. Betriebssysteme, Frameworks, Bibliotheken und Anwen-dungen müssen sicher konfiguriert werden und zeitnah Patches und Updates erhalten.' 49 | %} 50 | {% include t10_subsection_inner_round_box.html 51 | topic='**[A7:2017-Cross-Site Scripting (XSS)](A7_2017-Cross-Site_Scripting_(XSS)):**' 52 | description=' 53 | XSS tritt auf, wenn Anwendungen nicht vertrauenswürdige Daten entgegennehmen und ohne Validierung oder Umkodierung an einen Webbrowser senden. XSS tritt auch auf, wenn eine Anwendung HTML- oder JavaScript-Code auf Basis von Nutzereingaben erzeugt. XSS erlaubt es einem Angreifer, Scriptcode im Browser eines Opfers auszuführen und so Benutzersitzungen zu übernehmen, Seiteninhalte verändert anzuzeigen oder den Benutzer auf bösartige Seiten umzuleiten.' 54 | %} 55 | {% include t10_subsection_inner_round_box.html 56 | topic='**[A8:2017-Unsichere Deserialisierung](A8_2017-Unsichere_Deserialisierung):**' 57 | description=' 58 | Unsichere, weil unzureichend geprüfte Deserialisierungen können zu Remote-Code-Execution-Schwachstellen führen. Aber auch wenn das nicht der Fall ist, können Deserialisierungsfehler Angriffsmuster wie Replay-Angriffe, Injections und Erschleichung erweiterter Zugriffsrechte ermöglichen.' 59 | %} 60 | {% include t10_subsection_inner_round_box.html 61 | topic='**[A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen](A9_2017-Nutzung_von_Komponenten_mit_bekannten_Schwachstellen):**' 62 | description=' 63 | Komponenten wie Bibliotheken, Frameworks etc. werden mit den Berechtigungen der zugehöri-gen Anwendung ausgeführt. Wird eine verwundbare Komponente ausgenutzt, kann ein solcher Angriff von Datenverlusten bis hin zu einer Übernahme des Systems führen. Applikationen und APIs, die Komponenten mit bekannten Schwachstellen einsetzen, können Schutzmaßnahmen unterlaufen und so Angriffe mit schwerwiegenden Auswirkungen verursachen.' 64 | %} 65 | {% include t10_subsection_inner_round_box.html 66 | topic='**[A10:2017-Unzureichendes Logging & Monitoring](A10_2017-Unzureichendes_Logging%2526Monitoring):**' 67 | description=' 68 | Unzureichendes Logging und Monitoring führt zusammen mit fehlender oder uneffektiver Reaktion auf Vorfälle zu andauernden oder wiederholten Angriffen. Auch können Angreifer dadurch in Netzwerken weiter vordringen und Daten entwenden, verändern oder zerstören. Viele Studien zeigen, dass die Zeit bis zur Aufdeckung eines Angriffs bei ca. 200 Tagen liegt sowie typischer-weise durch Dritte entdeckt wird und nicht durch interne Überwachungs- und Kontrollmaßnahmen.' 69 | %} 70 | {%- include t10_subsection_end.html -%} 71 | -------------------------------------------------------------------------------- /2017/A10_2017-Insufficient_Logging%26Monitoring.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 4 | year: 2017 5 | order: 15 6 | title: A10:2017-Insufficient Logging & Monitoring 7 | lang: en 8 | layout: full-width-document 9 | author: 10 | contributors: 11 | tags: OWASP Top Ten 2017, Top Ten, A10:2017 12 | exploitability: 2 13 | prevalence: 3 14 | detectability: 1 15 | technical: 2 16 | redirect_from: 17 | - OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging%2526Monitoring.html 18 | - OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging%2526Monitoring 19 | - OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging%252526Monitoring.html 20 | - OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging%252526Monitoring 21 | 22 | --- 23 | 24 | {% include risk_begin.html %} 25 | {%- include risk_description.html pos="firstLeft" -%} 26 | Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.
27 | Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. 28 | {%- include risk_description.html pos="mid" -%} 29 | This issue is included in the Top 10 based on an [industry survey](https://owasp.blogspot.com/2017/08/owasp-top-10-2017-project-update.html).
30 | One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The testers' actions should be recorded sufficiently to understand what damages they may have inflicted. 31 | {%- include risk_description.html pos="right" -%} 32 | Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%.
33 | In 2016, identifying a breach took an [average of 191 days](https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=SEL03130WWEN&) – plenty of time for damage to be inflicted. 34 | {%- include risk_end.html -%} 35 | 36 | {%- include t10_subsection_begin.html -%} 37 | {%- include t10_subsection.html token="isTheApplicationVulnerable" pos="firstLeft" -%} 38 | Insufficient logging, detection, monitoring and active response occurs any time:
39 | * Auditable events, such as logins, failed logins, and high-value transactions are not logged.
40 | * Warnings and errors generate no, inadequate, or unclear log messages.
41 | * Logs of applications and APIs are not monitored for suspicious activity.
42 | * Logs are only stored locally.
43 | * Appropriate alerting thresholds and response escalation processes are not in place or effective.
44 | * Penetration testing and scans by [DAST](/www-community/Vulnerability_Scanning_Tools) tools (such as [OWASP ZAP](/www-project-zap)) do not trigger alerts.
45 | * The application is unable to detect, escalate, or alert for active attacks in real time or near real time.
46 | 47 | You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see [A3:2017-Sensitive Data Exposure](A3_2017-Sensitive_Data_Exposure)). 48 | 49 | {%- include t10_subsection.html token="howToPrevent" pos="right" -%} 50 | As per the risk of the data stored or processed by the application:
51 | * Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis.
52 | * Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
53 | * Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
54 | * Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
55 | * Establish or adopt an incident response and recovery plan, such as [NIST 800-61 rev 2](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final) or later.
56 | 57 | There are commercial and open source application protection frameworks such as [OWASP AppSensor](/www-project-appsensor) ([old wiki](https://wiki.owasp.org/index.php/OWASP_AppSensor_Project)), web application firewalls such as ModSecurity with the [OWASP ModSecurity Core Rule Set](/www-project-modsecurity-core-rule-set), and log correlation software with custom dashboards and alerting. 58 | 59 | {%- include t10_subsection.html token="exampleAttackScenarios" pos="left" -%} 60 | **Scenario #1**: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.
61 | 62 | **Scenario #2**: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
63 | 64 | **Scenario #3**: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank. 65 | 66 | {%- include t10_subsection.html token="references" pos="right" -%} 67 | **OWASP**
68 | * [OWASP Proactive Controls: Implement Logging and Monitoring](/www-project-proactive-controls/v3/en/c9-security-logging.html)
69 | * [OWASP Application Security Verification Standard: V8 Logging and Monitoring](/www-project-application-security-verification-standard)
70 | * [OWASP Testing Guide: Testing for Detailed Error Code](/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code)
71 | * [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
72 |
73 | **External**
74 | * [CWE-223: Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html)
75 | * [CWE-778: Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) 76 | {% include t10_subsection_end.html %} -------------------------------------------------------------------------------- /2017/de/Naechste_Schritte_fuer_Organisationen.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 19 6 | en: What%27s_Next_for_Organizations 7 | title: Nächste Schritte für Organisationen 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, de 13 | redirect_from: 14 | - 2017/de/What%2527s_Next_for_Organizations 15 | 16 | --- 17 | 18 | {%- include t10_subsection_begin.html -%} 19 | {%- include t10_subsection.html pos="firstWhole" text="Starten Sie jetzt Ihre Offensive zur Anwendungssicherheit!" -%} 20 | Anwendungssicherheit ist nicht mehr länger optional. Organisationen müssen leistungsfähige Prozesse und Ressourcen zur Absicherung ihrer Anwendungen und APIs schaffen, um im Umfeld einer steigenden Zahl von Angriffen einerseits und regulatorischen Vorschriften andererseits bestehen zu können. Auf Grund der atemberaubenden Mengen an Code in zahlreichen Anwendungen und APIs haben viele Organisationen Probleme, mit dem enormen Umfang an Sicherheitslücken zurecht zu kommen. OWASP empfiehlt den Aufbau eines Programms zur Anwendungssicherheit, um einen Überblick über die Sicherheitslage ihrer Anwendungen und APIs zu erhalten und diese zu verbessern. Um das Sicherheitsniveau zu erhöhen, müssen viele Unternehmensbereiche effizient zusammenarbeiten, von Security und Audit über die Entwicklungsabteilung und das Business bis hin zum Management. Die Sicherheitsarchitektur muss transparent und messbar sein, damit alle Beteiligten die Ziele der Anwendungssicherheit im Unternehmen nachvollziehen zu können. Konzentrieren Sie sich auf die Aktivitäten und Resultate, die tatsächlich zur Unternehmenssicherheit beitragen, indem Sie Risiken eliminieren oder reduzieren. [OWASP SAMM](/www-project-samm) und der [OWASP Application Security Guide for CISOs (altes Wiki)](https://wiki.owasp.org/index.php/Application_Security_Guide_For_CISOs) sind die Quellen für die meisten der Schlüsselaktivitäten in dieser Liste. 21 |
22 |
23 | {% include t10_subsection_inner_round_box.html 24 | topic='**Start:**' 25 | description=' 26 | * Dokumentieren Sie alle Anwendungen und die zugehörigen Datenbestände. Größere Organisationen sollten die Einführung einer Configuration Management Database (CMDB) in Betracht ziehen.
* Führen Sie einen [Anwendungssicherheits-Leitfaden](https://owaspsamm.org/model/governance/policy-and-compliance/) ein und fördern Sie dessen Akzeptanz.
* Führen Sie eine [Gap-Analyse der Fähigkeiten Ihrer Organisation zu vergleichbaren Organisationen](https://owaspsamm.org/model/governance/strategy-and-metrics/) durch, um wichtige Verbesserungsfelder und einen Maßnahmenplan festzulegen.
* Führen Sie mit Zustimmung der Geschäftsleitung eine [Kampagne zur Sensibilisierung für Fragen der Anwendungssicherheit](https://owaspsamm.org/model/governance/education-and-guidance/) für Ihre gesamte IT-Organisation durch.' 27 | %} 28 | {% include t10_subsection_inner_round_box.html 29 | topic='**Risiko-basierter Ansatz:**' 30 | description=' 31 | * Identifizieren Sie den [Schutzbedarf Ihrer Anwendungen](https://owaspsamm.org/model/governance/strategy-and-metrics/) aus geschäftlicher Sicht. Das sollte zum Teil durch Datenschutzgesetze und andere Vorschriften motiviert sein, die für die zu schützenden Datenbestände gelten.
* Erstellen Sie ein [Risikobewertungsmodell](/www-community/OWASP_Risk_Rating_Methodology) mit einem einheitlichen System von Wahrscheinlichkeiten und Auswirkungen, welches die Bereitschaft Ihrer Organisation berücksichtigt, Risiken einzugehen.
* Messen und priorisieren Sie dementsprechend alle Ihre Anwendungen und APIs. Fügen Sie die Ergebnisse in Ihre CMDB ein.
* Legen Sie Prüfungsrichtlinien fest, um einen angemessenen Abdeckungsgrad und den geforderten Reifegrad festzulegen.' 32 | %} 33 | {% include t10_subsection_inner_round_box.html 34 | topic='**Sorgen Sie für eine stabile Grundlage:**' 35 | description=' 36 | * Erstellen Sie [Richtlinien und Standards](https://owaspsamm.org/model/governance/policy-and-compliance/) für Anwendungssicherheit, die als Basis für alle betroffenen Entwicklungsteams dienen.
* Definieren Sie einen [allgemeingültigen Basissatz wiederverwendbarer Sicherheitsmaßnahmen](/www-project-security-knowledge-framework), die diese Richtlinien und Standards ergänzen und stellen Sie Nutzungshinweise für Design und Entwicklung bereit.
* Etablieren Sie einen [Trainings-Plan für Anwendungssicherheit](https://owaspsamm.org/model/governance/education-and-guidance/) das sich an den verschiedenen Entwicklungsaufgaben und Themenkomplexen orientiert.' 37 | %} 38 | {% include t10_subsection_inner_round_box.html 39 | topic='**Integrieren Sie Sicherheit in Ihre bestehenden Prozesse:**' 40 | description=' 41 | * Legen Sie Ihre Aktivitäten bzgl. [sicherer Implementierung](https://owaspsamm.org/model/implementation/) und [Verifikation](https://owaspsamm.org/model/verification/) fest und integrieren Sie diese in existierende Entwicklungs- und Anwendungsprozesse. Diese umfassen die [Modellierung der Bedrohungen](https://owaspsamm.org/model/design/threat-assessment/), sicheres Design und [Design-Review](https://owaspsamm.org/model/design/security-architecture/), sichere Programmierung und [Code-Review](https://owaspsamm.org/model/implementation/secure-build/), [Penetrationstests](https://owaspsamm.org/model/verification/security-testing/)und [Mängelbeseitigung](https://owaspsamm.org/model/implementation/defect-management/).
* Stellen Sie Experten und [unterstützende Dienste bereit, die die Entwickler und die Projektteams](https://owaspsamm.org/model/governance/education-and-guidance/) bei der erfolgreichen Umsetzung unterstützen.' 42 | %} 43 | {% include t10_subsection_inner_round_box.html 44 | topic='**Sorgen Sie für Sichtbarkeit beim Management:**' 45 | description=' 46 | * Arbeiten Sie mit Metriken. Treiben Sie Verbesserungs- und Budget-Entscheidungen voran, die auf diesen Metriken und Analysedaten beruhen. Solche Metriken umfassen die Beachtung von Sicherheitspraktiken und -aktivitäten, neue oder entschärfte Sicherheitslücken, erfasste Anwendungen, Fehlerdichte nach Art und Anzahl etc.
* Analysieren Sie Ihre Implementierungs- und Prüfungsaktivitäten hinsichtlich der Hauptursachen und Muster für Sicherheitslücken. Treiben Sie so strategische und systemische Verbesserungen in Ihrer Organisation voran. Lernen Sie aus Fehlern und setzen Sie positive Anreize um Verbesserungen zu fördern.' 47 | %} 48 | {%- include t10_subsection_end.html -%} 49 | -------------------------------------------------------------------------------- /2017/de/A8_2017-Unsichere_Deserialisierung.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | document: OWASP Top Ten 2017 (de) 4 | year: 2017 5 | order: 14 6 | en: A8_2017-Insecure_Deserialization 7 | title: A8:2017-Unsichere Deserialisierung 8 | lang: de 9 | layout: full-width-document 10 | author: 11 | contributors: 12 | tags: OWASP Top Ten 2017 (de), Top Ten, A8:2017, de 13 | exploitability: 1 14 | prevalence: 2 15 | detectability: 2 16 | technical: 3 17 | redirect_from: 18 | - 2017/de/A8_2017-Insecure_Deserialization 19 | 20 | --- 21 | 22 | {% include risk_begin.html %} 23 | {%- include risk_description.html pos="firstLeft" -%} 24 | 25 | Das Ausnutzen von Fehlern in der Deserialisierung ist nicht trivial, zumal vorhandener Angriffscode selten ohne weitere Anpassungen einsetzbar ist. 26 | {%- include risk_description.html pos="mid" -%} 27 | 28 | Dieser Eintrag in den Top 10 basiert auf einer [Expertenumfrage in der Community](https://owasp.blogspot.com/2017/08/owasp-top-10-2017-project-update.html) Dieser Eintrag in den Top 10 basiert auf einer Expertenumfrage in der Community und nicht auf messbaren Fallzahlen.
Einige Werkzeuge können Deserialisierungsschwachstellen entdecken, allerdings ist häufig eine manuelle Überprüfung des Fundes nötig. Es ist zu erwarten, dass belastbareres Zahlenmaterial zur Verfügung stehen wird, sobald die Tools zur Erkennung weiter entwickelt sind. 29 | {%- include risk_description.html pos="right" -%} 30 | 31 | Die Auswirkungen von Deserialisierungsfehlern sollten nicht unterschätzt werden. Diese Schwachstelle kann durchaus zu "Remote-Code Execution" führen, einem der schwerwiegendsten Angriffe überhaupt.
Die Auswirkungen auf das Unternehmen hängen vom Schutzbedarf der Anwendung und ihrer Daten ab. 32 | {%- include risk_end.html -%} 33 | 34 | {%- include t10_subsection_begin.html -%} 35 | {%- include t10_subsection.html token="isTheApplicationVulnerable" pos="firstLeft" -%} 36 | Anwendungen oder APIs können verwundbar sein, wenn Sie bösartige oder vom Angreifer manipulierte Objekte deserialisieren.Dies kann zu zwei Hauptangriffsarten führen:
37 | * Angriffe mittels Objekt- und Datenstrukturen, die es Angreifern ermöglichen, die Anwendungslogik zu verändern oder Programmcode auszuführen. Dies ist möglich, sofern die Anwendung auf Klassen zugreifen kann (inkl. Standardklassen), deren Verhalten während oder nach der Deserialisierung manipuliert werden kann.
38 | * Übliche Angriffe mittels Datenmanipulation: dazu zählen Angriffe gegen die Zugriffskontrolle, wobei existierende Datenstrukturen genutzt und deren Inhalt manipuliert werden.
39 | 40 | Serialisierung wird häufig eingesetzt bei:
41 | * Remote- und Inter-Prozess Kommunikation (RPC/IPC)
42 | * Wire-Protokollen, Webservices, Message-Brokern
43 | * Caching/Persistenz
44 | * Datenbanken, Cache-Servern, Dateisystemen
45 | * HTTP-Cookies, HTML-Formular-Parameter oder API-Authentifizierungs-Token. 46 | 47 | {%- include t10_subsection.html token="howToPrevent" pos="right" -%} 48 | Der einzig sichere Weg ist es keine serialisierten Objekte aus nicht vertrauenswürdigen Quellen anzunehmen oder nur serialisierte Datenstrukturen zu nutzen, die ausschließlich einfache Datentypen erlauben.
49 | Andernfalls ziehen Sie folgende Empfehlungen in Betracht:
50 | * Versehen Sie alle serialisierten Objekte mit einer digitalen Signatur, um so zu verhindern, dass bösartige Objekte erzeugt oder Daten manipuliert werden können.
51 | * Achten Sie auf eine strikte Typisierung während der Deserialisierung und bevor Objekte erzeugt werden. Zumeist wird hier nur eine bekannte Menge an Klassen benötigt. Es wurde bereits gezeigt, das diese Maßnahme umgangen werden kann. Es ist daher nicht ratsam, sich alleine hierauf zu verlassen.
52 | * Isolieren Sie den für die Deserialiserung zuständigen Programmcode und führen Sie ihn in einer eigenen Umgebung mit möglichst geringen Berechtigungen aus.
53 | * Protokollieren Sie alle Ausnahmefehler, die bei der Deserialisierung auftreten (z.B. unerwartete Objekt-Typen).
54 | * Begrenzen oder überwachen Sie ein- und ausgehende Netzwerkaktivitäten von Containern oder Servern, die Deserialisierungen ausführen. 55 | * Überwachen und melden Sie, wenn ein Nutzer auffällig häufig eine Deserialisierung nutzt. 56 | 57 | {%- include t10_subsection.html token="exampleAttackScenarios" pos="left" -%} 58 | **Szenario 1**: Eine React basierte Anwendung nutzt einige Spring Boot-Microservices. Die Programmierer dieser funktionalen Sprache haben darauf geachtet, dass ihr Programmcode „unveränderbar“ ist. Daher serialisieren Sie den Benutzerstatus und transferieren diesen so mit jeder Anfrage hin und her. Ein Angreifer entdeckt die „rO0“-Base64-Signatur des Java-Objekts und nutzt das Werkzeug Java Serial Killer, um Remote-Code-Execution auf dem Anwendungsserver auszuführen.
59 |
60 | **Szenario 2**: Ein PHP Forum nutzt die PHP-Objekt-Serialisierung um ein „Super-Cookie“ zu erzeugen, dieses enthält Angaben zur User-ID, Rolle, einen Passwort-Hash und weitere Informationen:
61 | {% include code_red_begin.html -%} a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; {%- include code_red_end.html %} 62 | {% include code_red_begin.html -%} i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} {%- include code_red_end.html %} 63 | 64 | Ein Angreifer verändert nun das serialisierte Objekt, um sich selbst Admin-Rechte zu verschaffen:
65 | {% include code_red_begin.html -%} a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; {%- include code_red_end.html %} 66 | {% include code_red_begin.html -%} i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} {%- include code_red_end.html %} 67 | 68 | {%- include t10_subsection.html token="references" pos="right" -%} 69 | **OWASP**
70 | * [OWASP Cheat Sheet: Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)
71 | * [OWASP Proactive Controls: Validate All Inputs](/www-project-proactive-controls/v3/en/c5-validate-inputs)
72 | * [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard)
73 | * [OWASP AppSecEU 2016: Surviving the Java Deserialization Apocalypse](https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse)
74 | * [OWASP AppSecUSA 2017: Friday the 13th JSON Attacks](https://speakerdeck.com/pwntester/friday-the-13th-json-attacks)
75 |
76 | **Andere**
77 | * [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html)
78 | * [Java Unmarshaller Security](https://github.com/mbechler/marshalsec)
79 | * [OWASP AppSec Cali 2015: Marshalling Pickles](http://frohoff.github.io/appseccali-marshalling-pickles/) 80 | {% include t10_subsection_end.html %} 81 | --------------------------------------------------------------------------------

• ANCAP	• ContextIS	• ITsec Security Services bv	• Paladion Networks
• Aspect Security	• Contrast Security	• Khallagh	• Purpletalk
• AsTech Consulting	• DDoS.com	• Linden Lab	• Secure Network
• Atos	• Derek Weeks	• M. Limacher 14 \| IT Dienstleistungen	• Shape Security
• Branding Brand	• Easybss	• M. Limacher 14 \| IT Dienstleistungen	• SHCP
• Bugcrowd	• Edgescan	• Micro Focus Fortify	• Softtek
• BUGemot	• EVRY	• Minded Security	• Synopsis
• CDAC	• EZI	• National Center for 19 \| Cyber Security 20 \| Technology	• TCS
• Checkmarx	• Hamed		• Vantage Point
23 \| • Colegio LaSalle 24 \| Monteria	• Hidden		• Veracode
23 \| • Colegio LaSalle 24 \| Monteria	• I4 Consulting	• Network Test Labs Inc.	• Web.com
• Company.com	27 \| • iBLISS Seguran̤a 28 \| & Inteligencia	• Osampa
	27 \| • iBLISS Seguran̤a 28 \| & Inteligencia

OWASP Top 10 - 2013 (Previous Version)	⇒	OWASP Top 10 - 2017 (Current Version) 13 \|
A1-Injection 16 \|	⇒ 18 \|	A1:2017-Injection 20 \|
A2-Broken Authentication and Session Management 23 \|	⇒ 25 \|	A2:2017-Broken Authentication 27 \|
A3-Cross-Site Scripting (XSS) 30 \|	⇘ 32 \|	A3:2017-Sensitive Data Exposure 34 \|
A4-Insecure Direct Object References - [Merged + A7] 37 \|	∪ 39 \|	A4:2017-XML External Entities (XXE) [NEW] 41 \|
A5-Security Misconfiguration 44 \|	⇘ 46 \|	A5:2017-Broken Access Control [Merged] 48 \|
A6-Sensitive Data Exposure 51 \|	⇗ 53 \|	A6:2017-Security Misconfiguration 55 \|
A7-Missing Function Level Access Control - [Merged + A4] 58 \|	∪ 60 \|	A7:2017-Cross-Site Scripting (XSS) 62 \|
A8-Cross-Site Request Forgery (CSRF) [Dropped] 65 \|	☒ 67 \|	A8:2017-Insecure Deserialization [NEW, Community] 69 \|
A9-Using Components with Known Vulnerabilities 72 \|	⇒ 74 \|	A9:2017-Using Components with Known Vulnerabilities 76 \|
A10-Unvalidated Redirects and Forwards [Dropped] 79 \|	☒ 81 \|	A10:2017-Insufficient Logging&Monitoring [NEW, Community] 83 \|

OWASP Top 10 - 2013	⇒	OWASP Top 10 - 2017
A1-Injection 16 \|	⇒ 18 \|	A1:2017-Injection 20 \|
A2-Fehler in Authentifizierung und Session-Management 23 \|	⇒ 25 \|	A2:2017-Fehler in der Authentifizierung 27 \|
A3-Cross-Site Scripting (XSS) 30 \|	⇘ 32 \|	A3:2017-Verlust der Vertraulichkeit sensibler Daten 34 \|
A4-Unsichere direkte Objektreferenzen [mit A7] 37 \|	∪ 39 \|	A4:2017-XML External Entities (XXE) [NEU] 41 \|
A5-Sicherheitsrelevante Fehlkonfiguration 44 \|	⇘ 46 \|	A5:2017-Fehler in der Zugriffskontrolle [vereint] 48 \|
A6-Verlust der Vertraulichkeit sensibler Daten 51 \|	⇗ 53 \|	A6:2017-Sicherheitsrelevante Fehlkonfiguration 55 \|
A7-Fehlerhafte Autorisierung auf Anwendungsebene [mit A4] 58 \|	∪ 60 \|	A7:2017-Cross-Site Scripting (XSS) 62 \|
A8-Cross-Site Request Forgery (CSRF) 65 \|	☒ 67 \|	A8:2017-Unsichere Deserialisierung [NEU, Community] 69 \|
A9-Nutzung von Komponenten mit bekannten Schwachstellen 72 \|	⇒ 74 \|	A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen 76 \|
A10-Ungeprüfte Um- und Weiterleitungen 79 \|	☒ 81 \|	A10:2017-Unzureichendes Logging & Monitoring [NEU, Community] 83 \|

WHOA THAT PAGE CANNOT BE FOUND

A selection of our Corporate Supporters

Corporate Supporters