├── .gitignore ├── subproject ├── info.md └── index.md ├── _data ├── ow_attributions.json └── i18n_en.yml ├── _config.yml ├── Gemfile ├── assets ├── css │ └── styles.css └── images │ └── README.md ├── leaders.md ├── _posts ├── 2024-01-08-sample2.md └── 2021-10-04-sample.md ├── cheatsheets ├── info.md ├── index.md ├── HTTP_Strict_Transport_Security_Cheat_Sheet.md ├── AJAX_Security_Cheat_Sheet.md ├── Securing_Cascading_Style_Sheets_Cheat_Sheet.md ├── PHP_Configuration_Cheat_Sheet.md ├── Forgot_Password_Cheat_Sheet.md ├── REST_Assessment_Cheat_Sheet.md ├── LDAP_Injection_Prevention_Cheat_Sheet.md ├── Query_Parameterization_Cheat_Sheet.md ├── Access_Control_Cheat_Sheet.md ├── JAAS_Cheat_Sheet.md ├── Mass_Assignment_Cheat_Sheet.md ├── Web_Service_Security_Cheat_Sheet.md ├── Unvalidated_Redirects_and_Forwards_Cheat_Sheet.md └── Vulnerability_Disclosure_Cheat_Sheet.md ├── info.md ├── OWASP_Top_Ten_2017 ├── info.md ├── Top_10-2017_Details_About_Risk_Factors.md ├── Top_10-2017_Acknowledgements.md ├── Top_10-2017_Note_About_Risks.md ├── Top_10-2017_Forward.md ├── Top_10-2017_What_27s_Next_for_Developers.md ├── Top_10-2017_What_27s_Next_for_Security_Testers.md ├── Top_10-2017_What_27s_Next_for_Application_Managers.md ├── Top_10-2017_Top_10.md ├── Top_10-2017_What_27s_Next_for_Organizations.md ├── Top_10-2017_Methodology_and_Data.md ├── Top_10-2017_Application_Security_Risks.md ├── Top_10-2017_A8-Insecure_Deserialization.md ├── Top_10-2017_A10-Insufficient_Logging_2526Monitoring.md ├── Top_10-2017_Introduction.md ├── Top_10-2017_Release_Notes.md ├── Top_10-2017_A5-Broken_Access_Control.md ├── Top_10-2017_A7-Cross-Site_Scripting_(XSS).md ├── Top_10-2017_A6-Security_Misconfiguration.md ├── Top_10-2017_A4-XML_External_Entities_(XXE).md ├── Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities.md ├── Top_10-2017_A1-Injection.md ├── Top_10-2017_A2-Broken_Authentication.md └── Top_10-2017_A3-Sensitive_Data_Exposure.md ├── tab_example.md ├── _includes └── impacts.html └── index.md /.gitignore: -------------------------------------------------------------------------------- 1 | /Gemfile.lock 2 | /favicon.ico 3 | _site/ 4 | -------------------------------------------------------------------------------- /subproject/info.md: -------------------------------------------------------------------------------- 1 | # My Subdir Info 2 | 3 | * One 4 | * Two 5 | * Three 6 | -------------------------------------------------------------------------------- /_data/ow_attributions.json: -------------------------------------------------------------------------------- 1 | ["Test Donor", "Another Donor", "Another Test", "Testing Again", "Another Test", "Mike"] 2 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | remote_theme: "owasp/www--site-theme@main" 2 | plugins: 3 | - jekyll-include-cache-0.2.0 4 | - jemoji 5 | 6 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | group :jekyll_plugins do 3 | gem "github-pages" 4 | end 5 | 6 | gem "webrick", "~> 1.7" 7 | -------------------------------------------------------------------------------- /assets/css/styles.css: -------------------------------------------------------------------------------- 1 | table { 2 | table-layout: fixed; 3 | width: 90%; 4 | font-size: smaller; 5 | column-width: 200px; 6 | } -------------------------------------------------------------------------------- /assets/images/README.md: -------------------------------------------------------------------------------- 1 | # placeholder 2 | 3 | Put images you wish to link to in this folder 4 | 5 | link would be in form /assets/images/ 6 | -------------------------------------------------------------------------------- /leaders.md: -------------------------------------------------------------------------------- 1 | ### Leaders 2 | * [Harold Blankenship](mailto:harold.blankenship@owasp.com) 3 | * [Ulysses Four Suspender](mailto:ulysses.four.suspender@owasp.org) 4 | * [Email Tester 6](mailto:email.tester6@owasp.org) 5 | * [Email Tester 11](mailto:email.tester11@owasp.org) 6 | * [Email Tester 14](mailto:email.tester14@owasp.org) 7 | -------------------------------------------------------------------------------- /subproject/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: An example subdir 5 | 6 | --- 7 | 8 | * {{ site.url }} 9 | * {{ page.url }} 10 | * {{ site.github.url }} 11 | * {{site.github.url | replace: 'www2.', ''}}{{page.url}} 12 | 13 | # Just an example of a subdirectory using col-sidebar layout. Requires an info.md file within the subdir. 14 | 15 | -------------------------------------------------------------------------------- /_posts/2024-01-08-sample2.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | date: 2024-01-08 13:35:00-0600 4 | categories: projects 5 | author: Harold Blankenship 6 | author_image: https://owasp.org/assets/images/people/staff_harold.png 7 | layout: blogpost 8 | title: OWASP Project Chapter Example Blog Post 9 | excerpt_separator: 10 | 11 | --- 12 | 13 | 14 | This should post after 1:35 pm CST -------------------------------------------------------------------------------- /_posts/2021-10-04-sample.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | date: 2021-10-04 09:00:00 -0700 4 | categories: projects 5 | author: Harold Blankenship 6 | author_image: https://owasp.org/assets/images/people/staff_harold.png 7 | layout: blogpost 8 | title: OWASP Project Chapter Example Blog Post 9 | excerpt_separator: 10 | 11 | --- 12 | 13 | Lots of interseting things to say to see if this works. 14 | 15 | And More stuff. 16 | -------------------------------------------------------------------------------- /cheatsheets/info.md: -------------------------------------------------------------------------------- 1 | {% assign cheatsheets = site.pages | where_exp: "page", "page.tags contains page.document" %} 2 | -------------------------------------------------------------------------------- /info.md: -------------------------------------------------------------------------------- 1 | ### Example Project Information 2 | * [Version 2.8.0](#) 3 | * Flagship Project 4 | * Breaker 5 | * Builder 6 | 7 | * Tool 8 | 9 | ### Downloads or Social Links 10 | * [Download](#) 11 | * [Meetup](#) 12 | 13 | ### Code Repository 14 | * [repo](#) 15 | 16 | ### Change Log 17 | * [changes](#) 18 | 19 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/info.md: -------------------------------------------------------------------------------- 1 | ### Table of Contents 2 | {% assign base_url = '/www-projectchapter-example' %} 3 | {% assign devsite = site.static_files | where: 'name', 'devsite.txt' %} 4 | {% if devsite.size > 0 %} 5 | {% assign base_url = '' %} 6 | {% endif %} 7 | {% assign top_ten_pages = site.pages | where:"document","OWASP Top Ten 2017" | sort: "order" %} 8 | -------------------------------------------------------------------------------- /tab_example.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Example 3 | displaytext: Example Tab 4 | layout: null 5 | tab: true 6 | order: 1 7 | tags: example-tag 8 | --- 9 | 10 | ## Example 11 | ---- 12 | Put whatever you like here: news, screenshots, features, supporters, or remove this file and don't use tabs at all. 13 | 14 | ## Put more here to check layout 15 | 16 | Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quoQuid pro quoQuid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo Quid pro quo 17 | 18 | ## And Done 19 | -------------------------------------------------------------------------------- /_data/i18n_en.yml: -------------------------------------------------------------------------------- 1 | - id: index 2 | title: Project Chapter Example page 3 | intro: "This is an example of a Project or Chapter Page. Please change these items to indicate the actual information you wish to present. In addition to this information, the 'front-matter' above this text should be modified to reflect your actual information. An explanation of each of the front-matter items is below: 4 | 5 | * layout: This is the layout used by project and chapter pages. You should leave this value as col-sidebar 6 | 7 | * title: This is the title of your project or chapter page, usually the name. For example, OWASP Zed Attack Proxy or OWASP Baltimore 8 | 9 | * tags: This is a space-delimited list of tags you associate with your project or chapter. If you are using tabs, at least one of these tags should be unique in order to be used in the tabs files (an example tab is included in this repo) 10 | 11 | * level: For projects, this is your project level (2 - Incubator, 3 - Lab, 4 - Flagship) 12 | 13 | * type: For projects, one of documentation, code, or tool 14 | 15 | A good resource for github markdown tags can be found [here]([https://www2.owasp.org/migration)" 16 | -------------------------------------------------------------------------------- /cheatsheets/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: OWASP Cheat Sheet Series 5 | tags: cheat sheet series, appsec application-security best-practices builders defenders 6 | 7 | --- 8 | 9 | ![OWASPHeader](/www-project-cheat-sheets/assets/images/Preface_Cheatsheet_Header.png) 10 | 11 | ![ProjectLogoOfficial](/www-project-cheat-sheets/assets/images/Preface_Cheatsheet_Logo.png) 12 | 13 | The **OWASP Cheat Sheet Series** was created to provide a concise collection of high value information on specific application security topics. These cheat sheets were created by various application security professionals who have expertise in specific topics. 14 | 15 | We hope that this project provides you with excellent security guidance in an easy to read format. 16 | 17 |
Get Started
18 | 19 | You can download this site [here](bundle.zip). 20 | 21 | An ATOM feed is available [here](News.xml) with the latest updates. 22 | 23 | Project leaders: 24 | - [Jim Manico](https://www.owasp.org/index.php/User:Jmanico) 25 | 26 | Core team: 27 | - [Elie Saad](https://github.com/ThunderSon) 28 | - [Jakub Maćkowski](https://github.com/mackowski) 29 | - [Robin Bailey](https://github.com/rbsec) 30 | - [Jim Manico](https://github.com/jmanico) 31 | 32 | Project links: 33 | - [Homepage](https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series) 34 | - [GitHub repository](https://github.com/OWASP/CheatSheetSeries) 35 | - [How to contribute?](https://github.com/OWASP/CheatSheetSeries#how-to-contribute) 36 | - [Logo](https://github.com/OWASP/owasp-swag/tree/master/projects/cheat-sheet-series) 37 | -------------------------------------------------------------------------------- /_includes/impacts.html: -------------------------------------------------------------------------------- 1 |

2 | {% case page.exploitability %} 3 | {% when 1 %} 4 | Exploitability 5 | {% when 2 %} 6 | Exploitability 7 | {% when 3 %} 8 | Exploitability 9 | {% endcase %} 10 | {% case page.prevalence %} 11 | {% when 1 %} 12 | Prevalence 13 | {% when 2 %} 14 | Prevalence 15 | {% when 3 %} 16 | Prevalence 17 | {% endcase %} 18 | {% case page.detectability %} 19 | {% when 1 %} 20 | Detectability 21 | {% when 2 %} 22 | Detectability 23 | {% when 3 %} 24 | Detectability 25 | {% endcase %} 26 | {% case page.technical %} 27 | {% when 1 %} 28 | Technical 29 | {% when 2 %} 30 | Technical 31 | {% when 3 %} 32 | Technical 33 | {% endcase %} 34 |

35 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Details_About_Risk_Factors.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Details About Risk Factors 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 21 10 | 11 | --- 12 | 13 | ### Top 10 Risk Factor Summary 14 | 15 | The following table presents a summary of the 2017 Top 10 Application Security Risks, and the risk factors we have assigned to each risk. These factors were determined based on the available statistics and the experience of the OWASP Top 10 team. To understand these risks for a particular application or organization, *you must consider your own specific threat agents and business impacts*. Even severe software weaknesses may not present a serious risk if there are no threat agents in a position to perform the necessary attack or the business impact is negligible for the assets involved. 16 | 17 | [Top 10 Risk Factor Summary Image](/www-project-top-ten/assets/images/Top10-Risk-Factor-Summary.png){:width="350px"} 18 | 19 | --- 20 | 21 | ### Additional Risks To Consider 22 | 23 | The Top 10 covers a lot of ground, but there are many other risks you should consider and evaluate in your organization. Some of these have appeared in previous versions of the Top 10, and others have not, including new attack techniques that are being identified all the time. Other important application security risks (ordered by CWE-ID) that you should additionally consider include: 24 | 25 | * [CWE-352: Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) 26 | * [CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion', 'AppDoS')](https://cwe.mitre.org/data/definitions/400.html) 27 | * [CWE-434: Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) 28 | * [CWE-451: User Interface (UI) Misrepresentation of Critical Information (Clickjacking and others)](https://cwe.mitre.org/data/definitions/451.html) 29 | * [CWE-601: Unvalidated Forward and Redirects](https://cwe.mitre.org/data/definitions/601.html) 30 | * [CWE-799: Improper Control of Interaction Frequency (Anti-Automation)](https://cwe.mitre.org/data/definitions/799.html) 31 | * [CWE-829: Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content)](https://cwe.mitre.org/data/definitions/829.html) 32 | * [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) 33 | 34 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Acknowledgements.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Top 10-2017 Acknowledgements 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 23 10 | 11 | --- 12 | 13 | ### Acknowledgements to Data Contributors 14 | 15 | We'd like to thank the many organizations that contributed their vulnerability data to support the 2017 update: 16 | 17 | • ANCAP • ContextIS • ITsec Security Services bv • Paladion Networks 18 | • Aspect Security • Contrast Security • Khallagh • Purpletalk 19 | • AsTech Consulting • DDoS.com • Linden Lab • Secure Network 20 | • Atos • Derek Weeks • M. Limacher 21 | IT Dienstleistungen • Shape Security 22 | • Branding Brand • Easybss • SHCP 23 | • Bugcrowd • Edgescan • Micro Focus Fortify • Softtek 24 | • BUGemot • EVRY • Minded Security • Synopsis 25 | • CDAC • EZI • National Center for 26 | Cyber Security 27 | Technology • TCS 28 | • Checkmarx • Hamed • Vantage Point 29 | • Colegio LaSalle 30 | Monteria • Hidden • Veracode 31 | • I4 Consulting • Network Test Labs Inc. • Web.com 32 | • Company.com • iBLISS Seguran̤a 33 | & Inteligencia • Osampa 34 | 35 | For the first time, all the data contributed to a Top 10 release, and the full list of contributors is [publicly available](https://github.com/OWASP/Top10/tree/master/2017/datacall/submissions). 36 | 37 | --- 38 | 39 | ### Acknowledgements to Individual Contributors 40 | 41 | We’d like to thank the individual contributors who spent many hours collectively contributing to the Top 10 in GitHub. 42 | 43 | • ak47gen • drwetter • ilatypov • neo00 • starbuck3000 44 | • alonergan • dune73 • irbishop • nickthetait • stefanb 45 | • ameft • ecbftw • itscooper • ninedter • sumitagarwalusa 46 | • anantshri • einsweniger • ivanr • ossie-git • taprootsec 47 | • bandrzej • ekobrin • jeremylong • PauloASilva • tghosth 48 | • bchurchill • eoftedal • jhaddix • PeterMosmans • TheJambo 49 | • binarious • frohoff • jmanico • pontocom • thesp0nge 50 | • bkimminich • fzipi • joaomatosf • psiinon • toddgrotenhuis 51 | • Boberski • gebl • jrmithdobbs • pwntester • troymarshall 52 | • borischen • Gilc83 • jsteven • raesene • tsohlacol 53 | • Calico90 • gilzow • jvehent • riramar • vdbaan 54 | • chrish • global4g • katyanton • ruroot • yohgaki 55 | • clerkendweller • grnd • kerberosmansour • securestep9 56 | • D00gs • h3xstream • koto • securitybits 57 | • davewichers • hiralph • m8urnett • SPoint42 58 | • drkknight • HoLyVieR • mwcoates • sreenathsasikumar 59 | And everyone else who provided feedback via Twitter, email, and other means. 60 | 61 | We would be remiss not to mention that Dirk Wetter, Jim Manico, and Osama Elnaggar have provided extensive assistance. Also, Chris Frohoff and Gabriel Lawrence provided invaluable support in the writing of the new [A8:2017-Insecure Deserialization](Top_10-2017_A8-Insecure_Deserialization.md) risk. 62 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-sidebar 4 | title: OWASP Project-Chapter Example 5 | tags: example-tag 6 | level: 2 7 | type: example 8 | altfooter: true 9 | meetup-group: OWASP-Austin-Chapter 10 | country: 11 | postal-code: 12 | 13 | --- 14 | 15 | 16 | 17 | {% include address_multiline.html %} 18 | 19 | {% assign i18n = site.data.i18n_en | where: 'id', 'index' | first %} 20 | 21 | {{ i18n.intro | markdownify }} 22 | 23 | **Quick test - something something - Something else** 24 | 25 | ### A List of Donors 26 | 27 | {% assign individual_supporter = site.data.ow_attributions | uniq %} 28 | {% for supporter in individual_supporter %} 29 | * {{ supporter | strip_html | strip_newlines | strip }} 30 | {% endfor %} 31 | 32 | | Heading 1 | Heading 2 | Heading 3 | 33 | | --- | --- | --- | 34 | | Data | More Data | Even More Data | 35 | | Hello | New | World | 36 | 37 | 38 |
39 | This is a test of the jump here fragment 40 |
41 | 42 | :+1: 43 | 44 | 45 | {% for m in site.data.tstmenu %} 46 | MENU 47 | {% endfor %} 48 | 49 |
50 |

{{ site.posts.first.title }}

51 | image 52 |

{{ site.posts.first.author }}, {{ site.posts.first.date | date: "%B %e, %Y" }}

53 |

{{ site.posts.first.excerpt }}...read more

54 |
55 | 56 | 12:00 - 13:00 - Opening Session 57 | 58 | #### Testing theme data elements 59 | {% for project in site.data.projects %} 60 | {{ project.name }} 61 | {% endfor %} 62 | 63 | {% assign category = site.data.events | where: "category", "Global" | first %} 64 | 69 | 70 | ### Check our Upcoming Meetup Events: 71 | {% include chapter_events.html group=page.meetup-group %} 72 | 73 | 74 | 94 | 95 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Note_About_Risks.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Note About Risks 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 20 10 | 11 | --- 12 | 13 | ### It's About the Risks that Weaknesses Represent 14 | 15 | The Risk Rating methodology for the Top 10 is based on the [OWASP Risk Rating Methodology](/www-project-testing). 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. 16 | 17 | The [OWASP Risk Rating Methodology](/www-project-testing) 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. 18 | 19 | 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. 20 | 21 | **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. 22 | 23 | The following illustrates our calculation of the risk for [A6:2017-Security Misconfiguration](Top_10-2017_A6-Security_Misconfiguration.md) 24 | 25 | ![A6:2017-Security Misconfiguration Image](/www-project-top-ten/assets/images/A6-Risk-Calculation) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Forward.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Foreward 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 1 10 | permalink: OWASP_Top_Ten_2017 11 | 12 | --- 13 | 14 | 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. 15 | 16 | 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. 17 | 18 | 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. 19 | 20 | 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) if a true standard is required, but for most, the OWASP Top 10 is a great start on the application security journey. 21 | 22 | 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's Next for Security Testers, What's Next for Organizations, which is suitable for CIOs and CISOs, and What's Next for Application Managers, which is suitable for application managers or anyone responsible for the lifecycle of the application. 23 | 24 | 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. 25 | 26 | 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: 27 | 28 | [https://github.com/OWASP/Top10/issues](https://github.com/OWASP/Top10/issues) 29 | 30 | 31 | You can find the OWASP Top 10 project and translations here: 32 | 33 | [https://www2.owasp.org/www-project-top-ten](https://www2.owasp.org/www-project-top-ten) 34 | 35 | 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! 36 | 37 | Andrew van der Stock
38 | Brian Glas
39 | Neil Smithline
40 | Torsten Gigler
41 | Project Sponsorship
42 | Thanks to Autodesk for sponsoring the OWASP Top 10 - 2017. 43 | 44 | Organizations and individuals that have provided vulnerability prevalence data or other assistance are listed on the Acknowledgements page. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_What_27s_Next_for_Developers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: What's Next for Developers 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 16 10 | 11 | --- 12 | 13 | ### Establish & Use Repeatable Security Processes and Standard Security Controls 14 | 15 | 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.
16 | 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. 17 | 18 | --- 19 | 20 | #### Application Security Requirements 21 | 22 | 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). 23 | **Note**: The annex is for US contract law, so please consult qualified legal advice before using the sample annex. 24 | 25 | #### Application Security Architecture 26 | 27 | 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. 28 | 29 | #### Security Standard Controls 30 | 31 | 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. 32 | 33 | #### Secure Development Lifecycle 34 | 35 | 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. 36 | 37 | #### Application Security Education 38 | 39 | 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). To stay current, come to an [OWASP AppSec Conference](/events), [OWASP Conference Training](/events), or local [OWASP Chapter meetings](/chapters). 40 | 41 | --- 42 | 43 | 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://www2.owasp.org), and many OWASP documents can be ordered in [hardcopy or as eBooks](https://stores.lulu.com/owasp). -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_What_27s_Next_for_Security_Testers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: What's Next for Security Testers 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 17 10 | 11 | --- 12 | 13 | ### Establish Continuous Application Security Testing 14 | 15 | 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.
16 | 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. 17 | 18 | --- 19 | 20 | #### Understand the Threat Model 21 | 22 | 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 Testing Guide](/www-project-testing) as an input and don’t rely on tool vendors to decide what’s important for your business. 23 | 24 | #### Understand Your SDLC 25 | 26 | 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. 27 | 28 | #### Testing Strategies 29 | 30 | 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. 31 | 32 | #### Achieving Coverage and Accuracy 33 | 34 | 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. 35 | 36 | #### Clearly Communicate Findings 37 | 38 | 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. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_What_27s_Next_for_Application_Managers.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: What's Next for Application Managers 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 19 10 | 11 | --- 12 | 13 | ### Manage the Full Application Lifecycle 14 | 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. 15 | 16 | --- 17 | 18 | #### Requirements and Resource Management 19 | 20 | * 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. 21 | * Compile the technical requirements including functional and nonfunctional security requirements. 22 | * Plan and negotiate the budget that covers all aspects of design, build, testing and operation, including security activities. 23 | 24 | #### Request for Proposals (RFP) and Contracting 25 | 26 | * Negotiate the requirements with internal or external developers, including guidelines and security requirements with respect to your security program, e.g. SDLC, best practices. 27 | * Rate the fulfillment of all technical requirements, including a planning and design phase. 28 | * Negotiate all technical requirements, including design, security, and service level agreements (SLA). 29 | * 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. 30 | 31 | #### Planning and Design 32 | 33 | * Negotiate planning and design with the developers and internal shareholders, e.g. security specialists. 34 | * Define the security architecture, controls, and countermeasures appropriate to the protection needs and the expected threat level. This should be supported by security specialists. 35 | * Ensure that the application owner accepts remaining risks or provides additional resources. 36 | * In each sprint, ensure security stories are created that include constraints added for non-functional requirements. 37 | 38 | #### Deployment, Testing, and Rollout 39 | 40 | * Automate the secure deployment of the application, interfaces and all required components, including needed authorizations. 41 | * Test the technical functions and integration with the IT architecture and coordinate business tests. 42 | * Create "use" and "abuse" test cases from technical and business perspectives. 43 | * Manage security tests according to internal processes, the protection needs, and the assumed threat level by the application. 44 | * Put the application in operation and migrate from previously used applications if needed. 45 | * Finalize all documentation, including the change management data base (CMDB) and security architecture. 46 | 47 | #### Operations and Change Management 48 | 49 | * Operations must include guidelines for the security management of the application (e.g. patch management). 50 | * Raise the security awareness of users and manage conflicts about usability vs. security. 51 | * Plan and manage changes, e.g. migrate to new versions of the application or other components like OS, middleware, and libraries. 52 | * Update all documentation, including in the CMDB and the security architecture, controls, and countermeasures, including any runbooks or project documentation. 53 | 54 | #### Retiring Systems 55 | 56 | * Any required data should be archived. All other data should be securely wiped. 57 | * Securely retire the application, including deleting unused accounts and roles and permissions. 58 | * Set your application's state to retired in the CMDB. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Top_10.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: 2017 Top 10 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 5 10 | 11 | --- 12 | 13 | ## OWASP Top 10 Application Security Risks - 2017 14 | 15 | ### A1:2017-Injection 16 | 17 | 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. 18 | 19 | --- 20 | 21 | ### A2:2017-Broken Authentication 22 | 23 | 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. 24 | 25 | --- 26 | 27 | ### A3:2017-Sensitive Data Exposure 28 | 29 | 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. 30 | 31 | --- 32 | 33 | ### A4:2017-XML External Entities (XXE) 34 | 35 | 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. 36 | 37 | --- 38 | 39 | ### A5:2017-Broken Access Control 40 | 41 | 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 | --- 44 | 45 | ### A6:2017-Security Misconfiguration 46 | 47 | 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. 48 | 49 | --- 50 | 51 | ### A7:2017-Cross-Site Scripting (XSS) 52 | 53 | 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. 54 | 55 | --- 56 | 57 | ### A8:2017-Insecure Deserialization 58 | 59 | 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. 60 | 61 | --- 62 | 63 | ### A9:2017-Using Components with Known Vulnerabilities 64 | 65 | 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. 66 | 67 | --- 68 | 69 | ### A10:2017-Insufficient Logging&Monitoring 70 | 71 | 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. -------------------------------------------------------------------------------- /cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: HTTP Strict Transport Security Cheat Sheet 5 | tags: cheat sheets, HTTP Strict Transport Security 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | HTTP [Strict Transport Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (also named **HSTS**) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers. 13 | 14 | The specification has been released and published end of 2012 as [RFC 6797](http://tools.ietf.org/html/rfc6797) (HTTP Strict Transport Security (HSTS)) by the IETF. 15 | 16 | # Threats 17 | 18 | HSTS addresses the following threats: 19 | 20 | - User bookmarks or manually types `http://example.com` and is subject to a man-in-the-middle attacker 21 | - HSTS automatically redirects HTTP requests to HTTPS for the target domain 22 | - Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP 23 | - HSTS automatically redirects HTTP requests to HTTPS for the target domain 24 | - A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate 25 | - HSTS does not allow a user to override the invalid certificate message 26 | 27 | # Examples 28 | 29 | Simple example, using a long (1 year = 31536000 seconds) max-age. This example is dangerous since it lacks `includeSubDomains`: 30 | 31 | `Strict-Transport-Security: max-age=31536000` 32 | 33 | This example is useful if all present and future subdomains will be HTTPS. This is a more secure option but will block access to certain pages that can only be served over HTTP: 34 | 35 | `Strict-Transport-Security: max-age=31536000; includeSubDomains` 36 | 37 | This example is useful if all present and future subdomains will be HTTPS. In this example we set a very short max-age in case of mistakes during initial rollout: 38 | 39 | `Strict-Transport-Security: max-age=86400; includeSubDomains` 40 | 41 | **Recommended:** 42 | - If the site owner would like their domain to be included in the [HSTS preload list](https://hstspreload.org) maintained by Chrome (and used by Firefox and Safari), then use the header below. 43 | - Sending the `preload` directive from your site can have **PERMANENT CONSEQUENCES** and prevent users from accessing your site and any of its subdomains if you find you need to switch back to HTTP. Please read the details at [preload removal](https://hstspreload.org/#removal) before sending the header with `preload`. 44 | 45 | `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` 46 | 47 | The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list. 48 | 49 | # Problems 50 | 51 | Site owners can use HSTS to identify users without cookies. This can lead to a significant privacy leak. Take a look [here](http://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy) for more details. 52 | 53 | Cookies can be manipulated from sub-domains, so omitting the `includeSubDomains` option permits a broad range of cookie-related attacks that HSTS would otherwise prevent by requiring a valid certificate for a subdomain. Ensuring the `secure` flag is set on all cookies will also prevent, some, but not all, of the same attacks. 54 | 55 | # Browser Support 56 | 57 | As of September 2019 HSTS is supported by [all modern browsers](https://caniuse.com/#feat=stricttransportsecurity), with the only notable exception being Opera Mini. 58 | 59 | # References 60 | 61 | - [Chromium Projects/HSTS](https://www.chromium.org/hsts/) 62 | - [OWASP TLS Protection Cheat Sheet](Transport_Layer_Protection_Cheat_Sheet.md) 63 | - [Moxie Marlinspike's Black Hat 2009 talk on sslstrip, that demonstrates why you need HSTS](https://moxie.org/software/sslstrip/) 64 | - [AppSecTutorial Series - Episode 4](https://www.youtube.com/watch?v=zEV3HOuM_Vw) 65 | - [Nmap NSE script to detect HSTS configuration](https://github.com/icarot/NSE_scripts/blob/master/http-hsts-verify.nse) 66 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_What_27s_Next_for_Organizations.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: What's Next for Organizations 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 18 10 | 11 | --- 12 | 13 | ### Start Your Application Security Program Now 14 | 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.
15 | 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](/www-project-application-security-guide-for-cisos) is the source of most of the key activities in this list. 16 | 17 | --- 18 | 19 | #### Get Started 20 | 21 | * Document all applications and associated data assets. Larger organizations should consider implementing a Configuration Management Database (CMDB) for this purpose. 22 | * Establish an [application security program](/www-project-samm) and drive adoption. 23 | * Conduct a [capability gap analysis](/www-project-samm) comparing your organization to your peers to define key improvement areas and an execution plan. 24 | * Gain management approval and establish an [application security awareness campaign](/www-project-samm) for the entire IT organization. 25 | 26 | #### Risk Based Portfolio Approach 27 | 28 | * 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. 29 | * Establish a [common risk rating model](/www-project-testing) with a consistent set of likelihood and impact factors reflective of your organization's tolerance for risk. 30 | * Accordingly measure and prioritize all your applications and APIs. Add the results to your CMDB. 31 | * Establish assurance guidelines to properly define coverage and level of rigor required. 32 | 33 | #### Enable with a Strong Foundation 34 | 35 | * Establish a set of focused [policies and standards](/www-project-samm) that provide an application security baseline for all development teams to adhere to. 36 | * 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. 37 | * Establish an [application security training curriculum](/www-project-samm) that is required and targeted to different development roles and topics. 38 | 39 | #### Integrate Security into Existing Processes 40 | 41 | * Define and integrate [secure implementation and verification](/www-project-samm) activities into existing development and operational processes. 42 | * Activities include [threat modeling, secure design and design review, secure coding and code review, penetration testing](/www-project-samm), and remediation. 43 | * Provide subject matter experts and [support services for development and project teams](/www-project-samm) to be successful. 44 | 45 | Provide Management Visibility 46 | 47 | * 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 density by type and instance counts, etc. 48 | * 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 -------------------------------------------------------------------------------- /cheatsheets/AJAX_Security_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: AJAX Security Cheat Sheet 5 | tags: cheat sheets, AJAX Security 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies. 13 | 14 | ## Client Side (JavaScript) 15 | 16 | ### Use .innerText instead of .innerHtml 17 | 18 | The use of `.innerText` will prevent most XSS problems as it will automatically encode the text. 19 | 20 | ### Don't use eval 21 | 22 | `eval()` function is evil, never use it. Needing to use eval usually indicates a problem in your design. 23 | 24 | ### Canonicalize data to consumer (read: encode before use) 25 | 26 | When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep its logical meaning. 27 | 28 | Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved. 29 | 30 | [Check out the OWASP Java Encoder Project.](https://www.owasp.org/index.php/OWASP_Java_Encoder_Project) 31 | 32 | ### Don't rely on client logic for security 33 | 34 | Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic. 35 | 36 | ### Don't rely on client business logic 37 | 38 | Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly. 39 | 40 | ### Avoid writing serialization code 41 | 42 | This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality. 43 | 44 | Take a look at the [JSON page](http://www.json.org/) for links. 45 | 46 | ### Avoid building XML or JSON dynamically 47 | 48 | Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library or safe JSON or XML library to make attributes and element data safe. 49 | 50 | - [XSS (Cross Site Scripting) Prevention](Cross_Site_Scripting_Prevention_Cheat_Sheet.md) 51 | - [SQL Injection Prevention](SQL_Injection_Prevention_Cheat_Sheet.md) 52 | 53 | ### Never transmit secrets to the client 54 | 55 | Anything the client knows the user will also know, so keep all that secret stuff on the server please. 56 | 57 | ### Don't perform encryption in client side code 58 | 59 | Use TLS/SSL and encrypt on the server! 60 | 61 | ### Don't perform security impacting logic on client side 62 | 63 | This is the overall one that gets me out of trouble in case I missed something :) 64 | 65 | ## Server Side 66 | 67 | ### Use CSRF Protection 68 | 69 | Take a look at the [Cross-Site Request Forgery (CSRF) Prevention](Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md) cheat sheet. 70 | 71 | ### Protect against JSON Hijacking for Older Browsers 72 | 73 | #### Review AngularJS JSON Hijacking Defense Mechanism 74 | 75 | See the [JSON Vulnerability Protection](https://docs.angularjs.org/api/ng/service/$http) section of the AngularJS documentation. 76 | 77 | #### Always return JSON with an Object on the outside 78 | 79 | Always have the outside primitive be an object for JSON strings: 80 | 81 | **Exploitable:** 82 | 83 | ```json 84 | [{"object": "inside an array"}] 85 | ``` 86 | 87 | **Not exploitable:** 88 | 89 | ```json 90 | {"object": "not inside an array"} 91 | ``` 92 | 93 | **Also not exploitable:** 94 | 95 | ```json 96 | {"result": [{"object": "inside an array"}]} 97 | ``` 98 | 99 | ### Avoid writing serialization code. Remember ref vs. value types! 100 | 101 | Look for an existing library that has been reviewed. 102 | 103 | ### Services can be called by users directly 104 | 105 | Even though you only expect your AJAX client side code to call those services the users can too. 106 | 107 | Make sure you validate inputs and treat them like they are under user control (because they are!). 108 | 109 | ### Avoid building XML or JSON by hand, use the framework 110 | 111 | Use the framework and be safe, do it by hand and have security issues. 112 | 113 | ### Use JSON And XML Schema for Webservices 114 | 115 | You need to use a 3rd party library to validate web services. 116 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Methodology_and_Data.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Top 10-2017 Methodology and Data 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 22 10 | 11 | --- 12 | 13 | ### Overview 14 | 15 | 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. 16 | 17 | ### Industry Ranked Survey 18 | 19 | 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. 20 | 21 | | Rank | Survey Vulnerability Categories | Score | 22 | | :---: | :------ | --- | 23 | | 1 | Exposure of Private Information ('Privacy Violation') [CWE-359] | 748 | 24 | | 2 | Cryptographic Failures [CWE-310/311/312/326/327] | 584 | 25 | | 3 | Deserialization of Untrusted Data [CWE-502] | 514 | 26 | | 4 | Authorization Bypass Through User-Controlled Key
(IDOR & Path Traversal) [CWE-639] | 493 | 27 | | 5 | Insufficient Logging and Monitoring [CWE-223 / CWE-778] | 440 | 28 | 29 | 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](Top_10-2017_A3-Sensitive_Data_Exposure.md). 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.md) after risk rating. The fourth ranked User-Controlled Key is included in [A5:2017-Broken Access Control](Top_10-2017_A5-Broken_Access_Control.md); 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](Top_10-2017_A10-Insufficient_Logging%2526Monitoring.md). 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. 30 | 31 | ### Public Data Call 32 | 33 | 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. 34 | 35 | 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. 36 | 37 | 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. 38 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Application_Security_Risks.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Application Security Risks 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 4 10 | 11 | --- 12 | 13 | ## What are Application Security Risks? 14 | 15 | 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. 16 | 17 | ![Risks 2017 Image](/www-project-top-ten/assets/images/Risks-2017.png) 18 | 19 | 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. 20 | 21 | ### What is My Risk? 22 | 23 | The [OWASP Top 10](https://www2.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](). 24 | 25 | 26 | #### Thread Agents 27 | * App Specific 28 | 29 | #### Exploitability 30 | * Easy: 3 31 | * Average: 2 32 | * Difficult: 1 33 | 34 | #### Weakness Prevalence 35 | * Widespread: 3 36 | * Common: 2 37 | * Uncommon: 1 38 | 39 | #### Weakness Detectability 40 | * Easy: 3 41 | * Average: 2 42 | * Difficult: 1 43 | 44 | #### Technical Impacts 45 | * Severe: 3 46 | * Moderate: 2 47 | * Minor: 1 48 | 49 | #### Business Impacts 50 | * App/Business Specific 51 | 52 | 53 | 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). 54 | 55 | 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. 56 | 57 | 58 | 59 | 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. 60 | 61 | 62 | #### References 63 | 64 | **OWASP** 65 | 66 | * [OWASP Risk Rating Methodology]() 67 | * [Article on Threat/Risk Modeling]() 68 | 69 | **External** 70 | 71 | * [ISO 31000: Risk Management Std](https://www.iso.org/iso-31000-risk-management.html) 72 | * [ISO 27001: ISMS](https://www.iso.org/isoiec-27001-information-security.html) 73 | * [NIST Cyber Framework (US)](https://www.nist.gov/cyberframework) 74 | * [ASD Strategic Mitigations (AU)](https://www.asd.gov.au/infosec/mitigationstrategies.htm) 75 | * [NIST CVSS 3.0](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) 76 | * [Microsoft Threat Modelling Tool](https://www.microsoft.com/en-us/download/details.aspx?id=49168) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A8-Insecure_Deserialization.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A8-Insecure Deserialization 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A8 8 | document: OWASP Top Ten 2017 9 | order: 13 10 | exploitability: 1 11 | prevalence: 2 12 | detectability: 2 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or tweaks to the underlying exploit code. 20 | * **Security Weakness**: 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. 21 | 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. 22 | * **Impacts**: The impact of deserialization flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible. 23 | The business impact depends on the protection needs of the application and data. 24 | 25 | --- 26 | 27 | ### Is the Application Vulnerable? 28 | 29 | 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: 30 | 31 | * 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. 32 | * Typical data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed. 33 | 34 | Serialization may be used in applications for: 35 | 36 | * Remote- and inter-process communication (RPC/IPC) 37 | * Wire protocols, web services, message brokers 38 | * Caching/Persistence 39 | * Databases, cache servers, file systems 40 | * HTTP cookies, HTML form parameters, API authentication tokens 41 | 42 | ### How to Prevent 43 | 44 | 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: 45 | 46 | * Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering. 47 | * 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. 48 | * Isolating and running code that deserializes in low privilege environments when possible. 49 | * Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions. 50 | * Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize. 51 | * Monitoring deserialization, alerting if a user deserializes constantly. 52 | 53 | ### Example Attack Scenarios 54 | 55 | **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. 56 | 57 | **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: 58 | 59 | a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; 60 | i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} 61 | 62 | An attacker changes the serialized object to give themselves admin privileges: 63 | 64 | a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; 65 | i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} 66 | 67 | ### References 68 | 69 | #### OWASP 70 | 71 | * [OWASP Cheat Sheet: Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) 72 | * [OWASP Proactive Controls: Validate All Inputs](/www-project-proactive-controls) 73 | * [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard) 74 | * [OWASP AppSecEU 2016: Surviving the Java Deserialization Apocalypse](https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse) 75 | * [OWASP AppSecUSA 2017: Friday the 13th JSON Attacks](https://speakerdeck.com/pwntester/friday-the-13th-json-attacks) 76 | 77 | #### External 78 | 79 | * [CWE-502: Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) 80 | * [Java Unmarshaller Security](https://github.com/mbechler/marshalsec) 81 | * [OWASP AppSec Cali 2015: Marshalling Pickles](http://frohoff.github.io/appseccali-marshalling-pickles/) -------------------------------------------------------------------------------- /cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Securing Cascading Style Sheets Cheat Sheet 5 | tags: cheat sheets, Securing Cascading Style Sheets 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | The goal of this `CSS` (Not [XSS](Cross_Site_Scripting_Prevention_Cheat_Sheet.md), but [Cascading Style Sheet](https://www.w3schools.com/css/css_intro.asp)) Cheat Sheet is to inform Programmers, Testers, Security Analysts, Front-End Developers and anyone who is interested in Web Application Security to use these recommendations or requirements in order to achieve better security when authoring `Cascading Style Sheets`. 13 | 14 | Let's demonstrate this risk with an example: 15 | 16 | Santhosh is a programmer who works for a company called **X** and authors a Cascading Style Sheet to implement styling of the web application. The application for which he is writing CSS Code has various roles like **Student**, **Teacher**, **Super User** & **Administrator** and these roles have different permissions (PBAC - [Permission Based Access Control](Access_Control_Cheat_Sheet.md)) and Roles (RBAC - [Role Based Access Control](Access_Control_Cheat_Sheet.md)). Not only do these roles have different access controls, but these roles could also have different styling for webpages that might be specific to an individual or group of roles. 17 | 18 | Santhosh thinks that it would a great optimized idea to create a "global styling" css file which has all the CSS styling/selectors for all of the roles. According to their role, a specific feature or user interface element will be rendered. For instance, Administrator will have different features compared to **Student** or **Teacher** or **SuperUser**. However, some permissions or features maybe common to some roles. 19 | 20 | Example: Profile Settings will be applicable to all the users here while *Adding Users* or *Deleting Users* is only applicable for **Administrator**. 21 | 22 | Example: 23 | 24 | - `.login` 25 | - `.profileStudent` 26 | - `.changePassword` 27 | - `.addUsers` 28 | - `.deleteUsers` 29 | - `.addNewAdmin` 30 | - `.deleteAdmin` 31 | - `.exportUserData` 32 | - `.exportProfileData` 33 | - ... 34 | 35 | Now, let's examine what are the risks associated with this style of coding. 36 | 37 | ## Risk \#1 38 | 39 | Motivated Attackers always take a look at `*.CSS` files to learn the features of the application even without being logged in. 40 | 41 | For instance: Jim is a motivated attacker and always tries to look into CSS files from the View-Source even before other attacks. When Jim looks into the CSS file, he sees that there are different features and different roles based on the CSS selectors like `.profileSettings,` `.editUser,` `.addUser,` `.deleteUser` and so on. Jim can use the CSS for intel gathering to help gain access to sensitive roles.This isa form of attacker due diligence even before trying to perform dangerous attacks to gain access to the web application. 42 | 43 | In a nutshell, having global styling could reveal sensitive information that could be beneficial to the attacker. 44 | 45 | ## Risk \#2 46 | 47 | Let's say, Santhosh has this habit of writing the descriptive selector names like `.profileSettings,` `exportUserData,` `.changePassword,` `.oldPassword,` `.newPassword,` `.confirmNewPassword` etc. Good programmers like to keep code readable and usable by other Code Reviewers of the team. The risk is that attackers could map these selectors to actual features of a web application. 48 | 49 | # Defensive Mechanisms to Mitigate Attacker's Motivation 50 | 51 | ## Defense Mechanism 52 | 53 | As a CSS Coder / Programmer, always keep the CSS isolated by access control level. By this, it means **Student** will have a different CSS file called as `StudentStyling.CSS` while **Administrator** has `AdministratorStyling.CSS` and so on. Make sure these `*.CSS` files are accessed only for a user with the proper access control level. Only users with the proper access control level should be able to access their `*.CSS` file. 54 | 55 | If an authenticated user with the **Student** Role tries to access `AdministratorStyling.CSS` through forced browsing, an alert that an intrusion is occurring should be recorded. 56 | 57 | ## Defense Mechanism \#2 58 | 59 | Being a programmer or a tester, take care of the naming conventions of your CSS (Cascading Style Sheet) Selectors. Obfuscate the selector names in such a fashion that attackers are not informed what a specific selector is linking to. 60 | 61 | Example: CSS Selectors for `addUser,` `addAdmin,` `profileSettings,` `changePassword` could be named `aHj879JK,` `bHjsU,` `ahkrrE,` `lOiksn` respectively. These names could be randomly generated per user as well. 62 | 63 | This [NPM package](https://www.npmjs.com/package/rename-css-selectors) can be used to perform the renaming of the CSS selector. 64 | 65 | ## Defense Mechanism \#3 66 | 67 | Web applications that allow users to author content via HTML input could be vulnerable to malicious use of CSS. Uploaded HTML could use styles that are allowed by the web application but could be used for purposes other than intended which could lead to security risks. 68 | 69 | Example: You can read about how [LinkedIn](https://www.scmagazineuk.com/style-sheet-vulnerability-allowed-attacker-hijack-linkedin-pages/article/1479529) had a vulnerability which allowed malicious use of CSS that lead to the authoring of a page where the entire page was clickable including overwriting LinkedIn's standard navigation elements. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging_2526Monitoring.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A10-Insufficient Logging & Monitoring 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A10 8 | document: OWASP Top Ten 2017 9 | order: 15 10 | exploitability: 2 11 | prevalence: 3 12 | detectability: 1 13 | technical: 2 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. 20 | Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. 21 | * **Security Weakness**: 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). 22 | 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. 23 | * **Impacts**: Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%. 24 | 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. 25 | 26 | --- 27 | 28 | ### Is the Application Vulnerable? 29 | 30 | Insufficient logging, detection, monitoring and active response occurs any time: 31 | 32 | * Auditable events, such as logins, failed logins, and high-value transactions are not logged. 33 | * Warnings and errors generate no, inadequate, or unclear log messages. 34 | * Logs of applications and APIs are not monitored for suspicious activity. 35 | * Logs are only stored locally. 36 | * Appropriate alerting thresholds and response escalation processes are not in place or effective. 37 | * Penetration testing and scans by [DAST](/www-community/Vulnerability_Scanning_Tools) tools (such as [OWASP ZAP](/www-project-zap)) do not trigger alerts. 38 | * The application is unable to detect, escalate, or alert for active attacks in real time or near real time. 39 | 40 | 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](Top_10-2017_A3-Sensitive_Data_Exposure)). 41 | 42 | ### How to Prevent 43 | 44 | As per the risk of the data stored or processed by the application: 45 | 46 | * 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. 47 | * Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions. 48 | * Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar. 49 | * Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion. 50 | * 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. 51 | 52 | There are commercial and open source application protection frameworks such as [OWASP AppSensor](/www-project-appsensor), 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. 53 | 54 | ### Example Attack Scenarios 55 | 56 | **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. 57 | 58 | **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. 59 | 60 | **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. 61 | 62 | ### References 63 | 64 | #### OWASP 65 | 66 | * [OWASP Proactive Controls: Implement Logging and Intrusion Detection](/www-project-proactive-controls) 67 | * [OWASP Application Security Verification Standard: V8 Logging and Monitoring](/www-project-application-security-verification-standard) 68 | * [OWASP Testing Guide: Testing for Detailed Error Code](/www-project-testing) 69 | * [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) 70 | 71 | #### External 72 | 73 | * [CWE-223: Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) 74 | * [CWE-778: Insufficient Logging](https://cwe.mitre.org/data/definitions/223.html) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Introduction.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Introduction 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 2 10 | 11 | --- 12 | 13 | ## Welcome to the OWASP Top 10 - 2017! 14 | 15 | This major update adds several new issues, including two issues selected by the community - [A8:2017-Insecure Deserialization](Top_10-2017_A8-Insecure_Deserialization) and [A10:2017-Insufficient Logging&Monitoring](Top_10-2017_A10-Insufficient_Logging%26Monitoring). 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. 16 | 17 | 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. 18 | 19 | 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. 20 | 21 | 22 | ## Roadmap for future activities 23 | 24 | **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]() and the [OWASP Cheat Sheet Series](https://wwww2.owasp.org/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. 25 | 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](Top_10-2017_What%27s_Next_for_Developers), [Security Testers](Top_10-2017_What%27s_Next_for_Security_Testers), [Organizations](Top_10-2017_What%27s_Next_for_Organizations) and [Application Managers](Top_10-2017_What%27s_Next_for_Application_Managers) for more information. 27 | 28 | **Think positive**. When you're ready to stop chasing vulnerabilities and focus on establishing strong application security controls, the [OWASP Proactive Controls](https://www2.owasp.org/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) is a guide for organizations and application reviewers on what to verify. 29 | 30 | **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. 31 | 32 | **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)](https://www2.owasp.org/www-project-samm). 33 | 34 | ## Attribution 35 | 36 | 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. 37 | 38 | As there are more contributors than space here, we have created a [dedicated page](Top_10-2017_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. 39 | 40 | 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. 41 | 42 | 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](Top_10-2017_Acknowledgements) page. 43 | 44 | 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. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_Release_Notes.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Release Notes 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten 8 | document: OWASP Top Ten 2017 9 | order: 3 10 | 11 | --- 12 | 13 | ## What changed from 2013 to 2017? 14 | 15 | 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: 16 | 17 | * 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. 18 | * 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. 19 | * 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. 20 | 21 | ### New issues, supported by data 22 | 23 | [A4:2017-XML External Entities (XXE)](Top_10-2017_A4-XML_External_Entities_(XXE)) is a new category primarily supported by [source code analysis security testing tools(SAST)](https://www2.owasp.org/www-community/Source_Code_Analysis_Tools) data sets. 24 | 25 | ### New issues, supported by the community 26 | 27 | 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: 28 | 29 | [A8:2017-Insecure Deserialization](https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization), which permits remote code execution or sensitive object manipulation on affected platforms. 30 | [A10:2107-Insufficient Logging&Monitoring](https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring), 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 | 34 | * [A4-Insecure Direct Object References](OWASP_Top_Ten_2013/Top_10_2013-A4-Insecure_Direct_Object_References) and [A7-Missing Function Level Access Control](OWASP_Top_Ten_2013/Top_10_2013-A7-Missing_Function_Level_Access_Control) merged into [A5:2017-Broken Access Control](OWASP_Top_Ten_2013/Top_10-2017_A5-Broken_Access_Control). 35 | * [A8-Cross-Site Request Forgery (CSRF)](OWASP_Top_Ten_2013/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)), as many frameworks include CSRF defenses, it was found in only 5% of applications. 36 | * [A10-Unvalidated Redirects and Forwards](OWASP_Top_Ten_2013/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards), while found in approximately in 8% of applications, it was edged out overall by XXE. 37 | 38 | 39 | | OWASP Top 10 - 2013 | ⇒ | OWASP Top 10 - 2017 | 40 | |:---| :------: |:---| 41 | | [A1-Injection](OWASP_Top_Ten_2013/Top_10-2013_A1-Injection) | ⇒ | [A1:2017-Injection](Top_10-2017_A1-Injection) | 42 | | [A2-Broken Authentication and Session Management](OWASP_Top_Ten_2013/Top_10_2013-A2-Broken_Authentication_and_Session_Management) | ⇒ | [A2:2017-Broken Authentication](Top_10-2017_A2-Injection) | 43 | | [A3-Cross-Site Scripting (XSS)](OWASP_Top_Ten_2013/Top_10_2013-A3-Cross-Site_Scripting_(XSS)) | ⇘ | [A3:2017-Sensitive Data Exposure](Top_10-2017_A3-Sensitive_Data_Exposure) | 44 | | [A4-Insecure Direct Object References](OWASP_Top_Ten_2013/Top_10_2013-A4-Insecure_Direct_Object_References)- [Merged + A7] | ∪ | [A4:2017-XML External Entities (XXE)](Top_10-2017_A4-XML_External_Entities_(XXE)) [NEW] | 45 | | [A5-Security Misconfiguration](OWASP_Top_Ten_2013/Top_10-2013_A5-Security_Misconfiguration) | ⇘ | [A5:2017-Broken Access Control](Top_10-2017_A5-Broken_Access_Control) [Merged] | 46 | | [A6-Sensitive Data Exposure](OWASP_Top_Ten_2013/Top_10-2013_A6-Sensitive_Data_Exposure) | ⇗ | [A6:2017-Security_Misconfiguration](Top_10-2017_A6-Security_Misconfiguration) | 47 | | [A7-Missing Function Level Access Control](OWASP_Top_Ten_2013/Top_10-2013_A7-Missing_Function_Level_Access_Control) [Merged + A4] | ∪ | [A7:2017-Cross-Site Scripting (XSS)](Top_10-2017_A7-Cross-Site_Scriting_(XSS)) | 48 | | [A8-Cross-Site Request Forgery (CSRF)](OWASP_Top_Ten_2013/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)) [Dropped] | ☒ | [ A8:2017-Insecure Deserialization](Top_10-2017_A8-Insecure_Deserialization) [NEW, Community] | 49 | | [A9-Using Components with Known Vulnerabilities](OWASP_Top_Ten_2013/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities) | ⇒ | [A9:2017-Using Components with Known Vulnerabilities](Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities) | 50 | | [A10-Unvalidated Redirects and Forwards](OWASP_Top_Ten_2013/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards) [Dropped] | ☒ | [A10:2017-Insufficient Logging&Monitoring](Top_10-2017_A10-Insufficient_Logging%26Monitoring) [NEW, Community] | 51 | 52 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A5-Broken Access Control 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A5 8 | document: OWASP Top Ten 2017 9 | order: 10 10 | exploitability: 2 11 | prevalence: 2 12 | detectability: 2 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Exploitation of access control is a core skill of attackers. [SAST](/www-community/Source_Code_Analysis_Tools) and [DAST](/www-community/Vulnerability_Scanning_Tools) tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. 20 | * **Security Weakness**: Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. 21 | Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs PUT, etc), controller, direct object references, etc. 22 | * **Impacts**: The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record. 23 | The business impact depends on the protection needs of the application and data. 24 | 25 | --- 26 | 27 | ### Is the Application Vulnerable? 28 | 29 | Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include: 30 | 31 | * Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool. 32 | * Allowing the primary key to be changed to another's users record, permitting viewing or editing someone else's account. 33 | * Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user. 34 | * Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation 35 | * CORS misconfiguration allows unauthorized API access. 36 | * Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE. 37 | 38 | ### How to Prevent 39 | 40 | Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. 41 | 42 | * With the exception of public resources, deny by default. 43 | * Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage. 44 | * Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. 45 | * Unique application business limit requirements should be enforced by domain models. 46 | * Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots. 47 | * Log access control failures, alert admins when appropriate (e.g. repeated failures). 48 | * Rate limit API and controller access to minimize the harm from automated attack tooling. 49 | * JWT tokens should be invalidated on the server after logout. 50 | 51 | Developers and QA staff should include functional access control unit and integration tests. 52 | 53 | ### Example Attack Scenarios 54 | 55 | **Scenario #1**: The application uses unverified data in a SQL call that is accessing account information: 56 | 57 | pstmt.setString(1, request.getParameter("acct")); 58 | ResultSet results = pstmt.executeQuery( ); 59 | 60 | An attacker simply modifies the 'acct' parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user's account. 61 | 62 | http://example.com/app/accountInfo?acct=notmyacct 63 | 64 | **Scenario #2**: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page. 65 | 66 | http://example.com/app/getappInfo 67 | http://example.com/app/admin_getappInfo 68 | 69 | If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw. 70 | 71 | ### References 72 | 73 | #### OWASP 74 | 75 | [OWASP Proactive Controls: Access Controls](/www-project-proactive-controls) 76 | [OWASP Application Security Verification Standard: V4 Access Control](/www-project-application-security-verification-standard) 77 | [OWASP Testing Guide: Authorization Testing](/www-project-testing) 78 | [OWASP Cheat Sheet: Access Control](https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html) 79 | 80 | #### External 81 | 82 | [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) 83 | [CWE-284: Improper Access Control (Authorization)](https://cwe.mitre.org/data/definitions/284.html) 84 | [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) 85 | [CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) 86 | [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) -------------------------------------------------------------------------------- /cheatsheets/PHP_Configuration_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: PHP Configuration Cheat Sheet 5 | tags: cheat sheets, PHP Configuration 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | This page is meant to help those configuring PHP and the web server it is running on to be very secure. 13 | 14 | Below you will find information on the proper settings for the `php.ini` file and instructions on configuring Apache, Nginx, and Caddy web servers. 15 | 16 | For general PHP codebase security please refer to the two following great guides: 17 | - [Paragonie's 2018 PHP Security Guide](https://paragonie.com/blog/2017/12/2018-guide-building-secure-php-software) 18 | - [Awesome PHP Security](https://github.com/guardrailsio/awesome-php-security) 19 | 20 | # PHP Configuration and Deployment 21 | 22 | ## php.ini 23 | 24 | Some of following settings need to be adapted to your system, in particular `session.save_path`, `session.cookie_path` (e.g. `/var/www/mysite`), and `session.cookie_domain` (e.g. `ExampleSite.com`). 25 | 26 | You should also be running PHP 7.2 or later. If running PHP 7.0 and 7.1, you will use slightly different values in a couple of places below (see inline comments). Finally look through the [PHP Manual](http://www.php.net/manual/ini.core.php) for a complete reference on every value in the php.ini configuration file. 27 | 28 | You can find a copy of the following values in a ready-to-go php.ini file [here](https://github.com/danehrlich1/very-secure-php-ini). 29 | 30 | #### PHP error handling 31 | 32 | ```text 33 | expose_php              = Off 34 | error_reporting         = E_ALL 35 | display_errors          = Off 36 | display_startup_errors  = Off 37 | log_errors              = On 38 | error_log               = /valid_path/PHP-logs/php_error.log 39 | ignore_repeated_errors  = Off 40 | ``` 41 | 42 | Keep in mind that you need to have `display_errors` to `Off` on a production server and it's a good idea to frequently notice the logs. 43 | 44 | #### PHP general settings 45 | 46 | ```text 47 | doc_root                = /path/DocumentRoot/PHP-scripts/ 48 | open_basedir            = /path/DocumentRoot/PHP-scripts/ 49 | include_path            = /path/PHP-pear/ 50 | extension_dir           = /path/PHP-extensions/ 51 | mime_magic.magicfile    = /path/PHP-magic.mime 52 | allow_url_fopen         = Off 53 | allow_url_include       = Off 54 | variables_order         = "GPCS" 55 | allow_webdav_methods    = Off 56 | session.gc_maxlifetime  = 600 57 | ``` 58 | 59 | `allow_url_*` prevents [LFI](https://www.acunetix.com/blog/articles/local-file-inclusion-lfi/)s to be easily escalated to [RFI](https://www.acunetix.com/blog/articles/remote-file-inclusion-rfi/)s. 60 | 61 | #### PHP file upload handling 62 | 63 | ```text 64 | file_uploads            = On 65 | upload_tmp_dir          = /path/PHP-uploads/ 66 | upload_max_filesize     = 2M 67 | max_file_uploads        = 2 68 | ``` 69 | 70 | If your application is not using file uploads, and say the only data the user will enter / upload is forms that do not require any document attachments, `file_uploads` should be turned `Off`. 71 | 72 | #### PHP executable handling 73 | 74 | ```text 75 | enable_dl               = Off 76 | disable_functions       = system, exec, shell_exec, passthru, phpinfo, show_source, highlight_file, popen, proc_open, fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file, chdir, mkdir, rmdir, chmod, rename, filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo 77 | # see also: http://ir.php.net/features.safe-mode 78 | disable_classes         =  79 | ``` 80 | 81 | These are dangerous PHP functions. You should disable all that you don't use. 82 | 83 | #### PHP session handling 84 | 85 | Session settings are some of the MOST important values to concentrate on in configuring. It is a good practice to change `session.name` to something new. 86 | 87 | ```text 88 | session.save_path = /path/PHP-session/ 89 | session.name = myPHPSESSID 90 | session.auto_start = Off 91 | session.use_trans_sid = 0 92 | session.cookie_domain = full.qualified.domain.name 93 | #session.cookie_path = /application/path/ 94 | session.use_strict_mode = 1 95 | session.use_cookies = 1 96 | session.use_only_cookies = 1 97 | session.cookie_lifetime = 14400 # 4 hours 98 | session.cookie_secure = 1 99 | session.cookie_httponly = 1 100 | session.cookie_samesite = Strict 101 | session.cache_expire = 30 102 | session.sid_length = 256 103 | session.sid_bits_per_character = 6 # PHP 7.2+ 104 | session.hash_function    = 1 # PHP 7.0-7.1 105 | session.hash_bits_per_character  = 6 # PHP 7.0-7.1 106 | ``` 107 | 108 | #### Some more security paranoid checks 109 | 110 | ```text 111 | session.referer_check   = /application/path 112 | memory_limit            = 50M 113 | post_max_size           = 20M 114 | max_execution_time      = 60 115 | report_memleaks         = On 116 | track_errors            = Off 117 | html_errors             = Off 118 | ``` 119 | 120 | ## Suhosin 121 | 122 | [Suhosin](http://www.hardened-php.net/suhosin/index.html) is a patch to PHP which provides a number of hardening and security features that are not available in the default PHP build. However, Suhosin only works with PHP 5, which is **unsupported** and **should not be used**. 123 | 124 | There are a number of projects that have attempted to implement similar features for PHP 7 such as [Snuffleupagus](https://snuffleupagus.readthedocs.io/) and [Suhosin-ng](https://github.com/sektioneins/suhosin-ng/wiki/News), but these are both in the pre-release stage, and as such **should not be used in production**. 125 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS).md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A7-Cross-Site Scripting (XSS) 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A7, xss 8 | document: OWASP Top Ten 2017 9 | order: 12 10 | exploitability: 3 11 | prevalence: 3 12 | detectability: 3 13 | technical: 2 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks. 20 | * **Security Weakness**: XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications. 21 | Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET. 22 | * **Impacts**: The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | There are three forms of XSS, usually targeting users' browsers: 29 | 30 | * **Reflected XSS**: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar. 31 | * **Stored XSS**: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk. 32 | * **DOM XSS**: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs. 33 | 34 | Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user's browser such as malicious software downloads, key logging, and other client-side attacks. 35 | 36 | ### How to Prevent 37 | 38 | Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by: 39 | 40 | * Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework's XSS protection and appropriately handle the use cases which are not covered. 41 | * Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The [OWASP Cheat Sheet 'XSS Prevention'](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) has details on the required data escaping techniques. 42 | * Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the [OWASP Cheat Sheet 'DOM based XSS Prevention'](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html). 43 | * Enabling a [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks). 44 | 45 | ### Example Attack Scenarios 46 | 47 | **Scenario #1**: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping: 48 | 49 | (String) page += ""; 51 | 52 | The attacker modifies the ‘CC’ parameter in the browser to: 53 | 54 | '>'. 57 | 58 | This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session. 59 | 60 | **Note**: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ. 61 | 62 | ### References 63 | 64 | #### OWASP 65 | 66 | * [OWASP Proactive Controls: Encode Data](/www-project-proactive-controls) 67 | * [OWASP Proactive Controls: Validate Data](/www-project-proactive-controls) 68 | * [OWASP Application Security Verification Standard: V5](/www-project-application-security-verification-standard) 69 | * [OWASP Testing Guide: Testing for Reflected XSS](/www-project-testing) 70 | * [OWASP Testing Guide: Testing for Stored XSS](/www-project-testing) 71 | * [OWASP Testing Guide: Testing for DOM XSS](/www-project-testing) 72 | * [OWASP Cheat Sheet: XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) 73 | * [OWASP Cheat Sheet: DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) 74 | * [OWASP Cheat Sheet: XSS Filter Evasion](/www-community//xss-filter-evasion-cheatsheet) 75 | * [OWASP Java Encoder Project](/www-project-java-encoder) 76 | 77 | #### External 78 | 79 | * [CWE-79: Improper neutralization of user supplied input](https://cwe.mitre.org/data/definitions/79.html) 80 | * [PortSwigger: Client-side template injection](https://portswigger.net/kb/issues/00200308_clientsidetemplateinjection) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A6-Security Misconfiguration 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A6 8 | document: OWASP Top Ten 2017 9 | order: 11 10 | exploitability: 3 11 | prevalence: 3 12 | detectability: 3 13 | technical: 2 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system. 20 | * **Security Weakness**: Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc. 21 | * **Impacts**: Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. 22 | The business impact depends on the protection needs of the application and data. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | The application might be vulnerable if the application is: 29 | 30 | * Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services. 31 | * Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges). 32 | * Default accounts and their passwords still enabled and unchanged. 33 | * Error handling reveals stack traces or other overly informative error messages to users. 34 | * For upgraded systems, latest security features are disabled or not configured securely. 35 | * The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values. 36 | * The server does not send security headers or directives or they are not set to secure values. 37 | * The software is out of date or vulnerable (see [A9:2017-Using Components with Known Vulnerabilities](Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities)). 38 | 39 | Without a concerted, repeatable application security configuration process, systems are at a higher risk. 40 | 41 | ### How to Prevent 42 | 43 | Secure installation processes should be implemented, including: 44 | 45 | * A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment. 46 | * A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks. 47 | * A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see [A9:2017-Using Components with Known Vulnerabilities](Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities)). In particular, review cloud storage permissions (e.g. S3 bucket permissions). 48 | * A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs). 49 | * Sending security directives to clients 50 | * An automated process to verify the effectiveness of the configurations and settings in all environments. 51 | 52 | ### Example Attack Scenarios 53 | 54 | **Scenario #1**: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren't changed the attacker logs in with default passwords and takes over. 55 | 56 | **Scenario #2**: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application. 57 | 58 | **Scenario #3**: The application server's configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable. 59 | 60 | **Scenario #4**: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed. 61 | 62 | ### References 63 | 64 | #### OWASP 65 | 66 | * [OWASP Testing Guide: Configuration Management](/www-project-testing) 67 | * [OWASP Testing Guide: Testing for Error Codes](/www-project-testing) 68 | 69 | For additional requirements in this area, see the [Application Security Verification Standard V19 Configuration](/www-project-application-security-verification-standard). 70 | 71 | #### External 72 | 73 | * [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) 74 | * [CWE-2: Environmental Security Flaws](https://cwe.mitre.org/data/definitions/2.html) 75 | * [CWE-16: Configuration](https://cwe.mitre.org/data/definitions/16.html) 76 | * [CWE-388: Error Handling](https://cwe.mitre.org/data/definitions/388.html) 77 | * [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) 78 | * [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A4-XML_External_Entities_(XXE).md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A4-XML External Entities (XXE) 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A4 8 | document: OWASP Top Ten 2017 9 | order: 9 10 | exploitability: 2 11 | prevalence: 2 12 | detectability: 3 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations. 20 | * **Security Weakness**: By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. 21 | [SAST](/www-community/Source_Code_Analysis_Tools) tools can discover this issue by inspecting dependencies and configuration. [DAST](/www-community/Vulnerability_Scanning_Tools) tools require additional manual steps to detect and exploit this issue. Manual testers need to be trained in how to test for XXE, as it not commonly tested as of 2017. 22 | * **Impacts**: These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. The business impact depends on the protection needs of all affected application and data. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if: 29 | 30 | * The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor. 31 | * Any of the XML processors in the application or SOAP based web services has [document type definitions (DTDs)](https://en.wikipedia.org/wiki/Document_type_definition) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the [OWASP Cheat Sheet 'XXE Prevention'](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html). 32 | * If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable. 33 | * If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework. 34 | Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack 35 | 36 | ### How to Prevent 37 | 38 | Developer training is essential to identify and mitigate XXE. Besides that, preventing XXE requires: 39 | 40 | * Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data. 41 | * Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher. 42 | * Disable XML external entity and DTD processing in all XML parsers in the application, as per the [OWASP Cheat Sheet 'XXE Prevention'](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html). 43 | * Implement positive ("whitelisting") server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes. 44 | * Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar. 45 | * [SAST](/www-community/Source_Code_Analysis_Tools) tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations. 46 | 47 | If these controls are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks. 48 | 49 | ### Example Attack Scenarios 50 | 51 | Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a lot of unexpected places, including deeply nested dependencies. The easiest way is to upload a malicious XML file, if accepted: 52 | 53 | **Scenario #1**: The attacker attempts to extract data from the server: 54 | 55 | 56 | 57 | 59 | ]> 60 | &xxe; 61 | 62 | **Scenario #2**: An attacker probes the server's private network by changing the above ENTITY line to: 63 | 64 | ]> 65 | 66 | **Scenario #3**: An attacker attempts a denial-of-service attack by including a potentially endless file: 67 | 68 | ]> 69 | 70 | 71 | ### References 72 | 73 | #### OWASP 74 | 75 | * [OWASP Application Security Verification Standard](/www-project-application-security-verification-standard) 76 | * [OWASP Testing Guide: Testing for XML Injection](/www-project-testing) 77 | * [OWASP XXE Vulnerability](/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing) 78 | * [OWASP Cheat Sheet: XXE Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) 79 | * [OWASP Cheat Sheet: XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) 80 | 81 | #### External 82 | 83 | * [CWE-611: Improper Restriction of XXE](https://cwe.mitre.org/data/definitions/611.html) 84 | * [Billion Laughs Attack](https://en.wikipedia.org/wiki/Billion_laughs_attack) 85 | * [SAML Security XML External Entity Attack](https://secretsofappsecurity.blogspot.tw/2017/01/saml-security-xml-external-entity-attack.html) 86 | * [Detecting and exploiting XXE in SAML Interfaces](https://web-in-security.blogspot.tw/2014/11/detecting-and-exploiting-xxe-in-saml.html) -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A9-Using Components with Known Vulnerabilities 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A9 8 | document: OWASP Top Ten 2017 9 | order: 14 10 | exploitability: 2 11 | prevalence: 3 12 | detectability: 2 13 | technical: 2 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit. 20 | * **Security Weakness**: Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. 21 | Some scanners such as retire.js help in detection, but determining exploitability requires additional effort. 22 | * **Impacts**: While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | You are likely vulnerable: 29 | 30 | * If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies. 31 | * If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries. 32 | * If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use. 33 | * If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities. 34 | * If software developers do not test the compatibility of updated, upgraded, or patched libraries. 35 | * If you do not secure the components' configurations (see [A6:2017-Security Misconfiguration](Top_10-2017_A6-Security_Misconfiguration)). 36 | 37 | ### How to Prevent 38 | 39 | There should be a patch management process in place to: 40 | 41 | * Remove unused dependencies, unnecessary features, components, files, and documentation. 42 | * Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like [versions](http://www.mojohaus.org/versions-maven-plugin/), [DependencyCheck](/www-project-dependency-check), [retire.js](https://github.com/retirejs/retire.js/), etc. Continuously monitor sources like [CVE](https://cve.mitre.org/) and [NVD](https://nvd.nist.gov/) for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use. 43 | * Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component. 44 | * Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a [virtual patch](/www-community/Virtual_Patching_Best_Practices) to monitor, detect, or protect against the discovered issue. 45 | 46 | Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio. 47 | 48 | ### Example Attack Scenarios 49 | 50 | **Scenario #1**: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are: 51 | 52 | * [CVE-2017-5638](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638), a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches. 53 | * While [internet of things (IoT)](https://en.wikipedia.org/wiki/Internet_of_things) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices). 54 | 55 | There are automated tools to help attackers find unpatched or misconfigured systems. For example, the [Shodan IoT search engine](https://www.shodan.io/report/89bnfUyJ) can help you find devices that still suffer from [Heartbleed](https://en.wikipedia.org/wiki/Heartbleed) vulnerability that was patched in April 2014. 56 | 57 | ### References 58 | 59 | #### OWASP 60 | 61 | * [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](/www-project-application-security-verification-standard) 62 | * [OWASP Dependency Check (for Java and .NET libraries)](/www-project-dependency-check) 63 | * [OWASP Testing Guide - Map Application Architecture (OTG-INFO-010)](/www-project-testing) 64 | * [OWASP Virtual Patching Best Practices](/www-community/Virtual_Patching_Best_Practices) 65 | 66 | #### External 67 | 68 | * [The Unfortunate Reality of Insecure Libraries](https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf) 69 | * [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cvedetails.com/version-search.php) 70 | * [National Vulnerability Database (NVD)](https://nvd.nist.gov/) 71 | * [Retire.js for detecting known vulnerable JavaScript libraries](https://github.com/retirejs/retire.js/) 72 | * [Node Libraries Security Advisories](https://nodesecurity.io/advisories) 73 | * [Ruby Libraries Security Advisory Database and Tools](https://rubysec.com/) -------------------------------------------------------------------------------- /cheatsheets/Forgot_Password_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Forgot Password Cheat Sheet 5 | tags: cheat sheets, Forgot Password 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | This article provides a simple model to follow when implementing a *forgot password* web application feature. 13 | 14 | # The Problem 15 | 16 | There is no industry standard for implementing a **Forgot Password** feature. The result is that you see applications forcing users to jump through myriad hoops involving emails, special URLs, temporary passwords, personal security questions, and so on. In the end you have to reset it to a new value. 17 | 18 | # Steps 19 | 20 | ## Step 1) Gather Identity Data or Security Questions 21 | 22 | The first page of a secure Forgot Password feature asks the user for multiple pieces of hard data that should have been previously collected (generally when the user first registers). 23 | 24 | Steps for this are detailed in the identity section the Choosing and Using Security Questions Cheat Sheet [here](Choosing_and_Using_Security_Questions_Cheat_Sheet.md#step-1-decide-on-identity-data-vs-canned-questions-vs-user-created-questions). 25 | 26 | At a minimum, you should have collected some data that will allow you to send the password reset information to some out-of-band side-channel, such as a (possibly different) email address or an SMS text number, etc. to be used in Step 3. 27 | 28 | ## Step 2) Verify Security Questions 29 | 30 | After the form on Step 1 is submitted, the application verifies that each piece of data is correct for the given username. If anything is incorrect, or if the username is not recognized, the second page displays a generic error message such as *Sorry, invalid data*. 31 | 32 | If all submitted data is correct, Step 2 should display at least two of the user's pre-established personal security questions, along with input fields for the answers. It's important that the answer fields are part of a single HTML form. 33 | 34 | Do not provide a drop-down list for the user to select the questions he wants to answer. Avoid sending the username as a parameter (hidden or otherwise) when the form on this page is submitted. The username should be stored in the server-side session where it can be retrieved as needed. 35 | 36 | Because users' security questions / answers generally contains much less entropy than a well-chosen password (how many likely answers are there to the typical *What's your favorite sports team?* or *In what city where you born?* security questions anyway?), make sure you limit the number of guesses attempted and if some threshold is exceeded for that user (say 3 to 5), lock out the user's account for some reasonable duration (say at least 5 minutes) and then challenge the user with some form of challenge token per standard multi-factor workflow; see \#3, below) to mitigate attempts by hackers to guess the questions and reset the user's password. It is not unreasonable to think that a user's email account may have already been compromised, so tokens that do not involve email, such as SMS or a mobile soft-token, are best. 37 | 38 | ## Step 3) Send a Token Over a Side-Channel 39 | 40 | After step 2, lock out the user's account immediately. Then SMS or utilize some other multi-factor token challenge with a randomly-generated code having 8 or more characters. 41 | 42 | This introduces an *out-of-band* communication channel and adds defense-in-depth as it is another barrier for a hacker to overcome. If the bad guy has somehow managed to successfully get past steps 1 and 2, he is unlikely to have compromised the side-channel. It is also a good idea to have the random code which your system generates to only have a limited validity period, say no more than 20 minutes or so. That way if the user doesn't get around to checking their email and their email account is later compromised, the random token used to reset the password would no longer be valid if the user never reset their password and the *reset password* token was discovered by an attacker. 43 | 44 | Of course, by all means, once a user's password has been reset, the randomly-generated token should no longer be valid. 45 | 46 | ## Step 4) Allow user to change password in the existing session 47 | 48 | Step 4 requires input of the code sent in step 3 in the existing session where the challenge questions were answered in step 2, and allows the user to reset his password. Display a simple HTML form with one input field for the code, one for the new password, and one to confirm the new password. Verify the correct code is provided and be sure to enforce all password complexity requirements that exist in other areas of the application. 49 | 50 | As before, avoid sending the username as a parameter when the form is submitted. Finally, it's critical to have a check to prevent a user from accessing this last step without first completing steps 1 and 2 correctly. Otherwise, a [forced browsing](https://www.owasp.org/index.php/Forced_browsing) attack may be possible. Ensure the user changes their password and does not simply surf to another page in the application. 51 | 52 | The reset must be performed before any other operations can be performed by the user. 53 | 54 | ## Step 5) Logging 55 | 56 | It is important to keep audit records when password change requests were submitted. This includes whether or not security questions were answered, when reset messages were sent to users and when users utilize them. It is especially important to log failed attempts to answer security questions and failed attempted use of expired tokens. This data can be used to detect abuse and malicious behavior. Data such as time, IP address, and browser information can be used to spot trends of suspicious use. 57 | 58 | # Other Considerations 59 | 60 | - Whenever a successful password reset occurs, all other sessions should be invalidated. Note the current session is already authenticated and does not require a login prompt. 61 | - Strength of questions used for reset should vary based on the nature of the credential. Administrator credentials should have a higher requirement. 62 | - The ideal implementation should rotate the questions asked in order to avoid automation. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A1-Injection.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A1-Injection 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A1 8 | document: OWASP Top Ten 2017 9 | order: 6 10 | exploitability: 3 11 | prevalence: 2 12 | detectability: 3 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter. 20 | * **Security Weakness**: Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. 21 | Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws. 22 | * **Impacts**: Injection can result in data loss, corruption, or disclosure to unauthorized parties, loss of accountability, or denial of access. Injection can sometimes lead to complete host takeover. The business impact depends on the needs of the application and data. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | An application is vulnerable to attack when: 29 | 30 | * User-supplied data is not validated, filtered, or sanitized by the application. 31 | * Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter. 32 | * Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records. 33 | * Hostile data is directly used or concatenated, such that the SQL or command contains both structure and hostile data in dynamic queries, commands, or stored procedures. 34 | * Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs. Organizations can include static source ([SAST](/www-community/Source_Code_Analysis_Tools)) and dynamic application test ([DAST](/www-community/Vulnerability_Scanning_Tools)) tools into the CI/CD pipeline to identify newly introduced injection flaws prior to production deployment. 35 | 36 | ### How to Prevent 37 | 38 | Preventing injection requires keeping data separate from commands and queries. 39 | 40 | * The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs). 41 | **Note**: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec(). 42 | * Use positive or "whitelist" server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. 43 | * For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter. 44 | **Note**: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software. 45 | * Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection. 46 | 47 | ### Example Attack Scenarios 48 | 49 | **Scenario #1**: An application uses untrusted data in the construction of the following vulnerable SQL call: 50 | 51 | String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 52 | 53 | **Scenario #2**: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g. Hibernate Query Language (HQL)): 54 | 55 | Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); 56 | 57 | In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ' or '1'='1. For example: 58 | 59 | http://example.com/app/accountView?id=' or '1'='1 60 | 61 | This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures. 62 | 63 | ### References 64 | 65 | #### OWASP 66 | 67 | * [OWASP Proactive Controls: Parameterize Queries](/www-project-proactive-controls) 68 | * [OWASP ASVS: V5 Input Validation and Encoding](/www-project-application-security-verification-standard) 69 | * [OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection](https://www2.owasp.org/www-project-testing/#div-downloads) 70 | * [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) 71 | * [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) 72 | * [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) 73 | * [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) 74 | * [OWASP Automated Threats to Web Applications – OAT-014](/www-project-automated-threats-to-web-applications/) 75 | 76 | #### External 77 | 78 | * [CWE-77: Command Injection](https://cwe.mitre.org/data/definitions/77.html) 79 | * [CWE-89: SQL Injection](https://cwe.mitre.org/data/definitions/89.html) 80 | * [CWE-564: Hibernate Injection](https://cwe.mitre.org/data/definitions/564.html) 81 | * [CWE-917: Expression Language Injection](https://cwe.mitre.org/data/definitions/917.html) 82 | * [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) 83 | -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A2-Broken Authentication 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A2 8 | document: OWASP Top Ten 2017 9 | order: 7 10 | exploitability: 3 11 | prevalence: 2 12 | detectability: 2 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens. 20 | * **Security Weakness**: The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls. Session management is the bedrock of authentication and access controls, and is present in all stateful applications. 21 | Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks. 22 | * **Impacts**: Attackers have to gain access to only a few accounts, or just one admin account to compromise the system. Depending on the domain of the application, this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information. 23 | 24 | --- 25 | 26 | ### Is the Application Vulnerable? 27 | 28 | Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks. There may be authentication weaknesses if the application: 29 | 30 | * Permits automated attacks such as [credential stuffing](/www-community/attacks/Credental_stuffing), where the attacker has a list of valid usernames and passwords. 31 | * Permits brute force or other automated attacks. 32 | * Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“. 33 | * Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers", which cannot be made safe. 34 | * Uses plain text, encrypted, or weakly hashed passwords (see [A3:2017-Sensitive Data Exposure](Top_10-2017_A3-Sensitive_Data_Exposure)). 35 | * Has missing or ineffective multi-factor authentication. 36 | * Exposes Session IDs in the URL (e.g., URL rewriting). 37 | * Does not rotate Session IDs after successful login. 38 | * Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren't properly invalidated during logout or a period of inactivity. 39 | 40 | ### How to Prevent 41 | 42 | * Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks. 43 | * Do not ship or deploy with any default credentials, particularly for admin users. 44 | * Implement weak-password checks, such as testing new or changed passwords against a list of the [top 10000 worst passwords](https://github.com/danielmiessler/SecLists/tree/master/Passwords). 45 | * Align password length, complexity and rotation policies with [NIST 800-63 B's guidelines in section 5.1.1 for Memorized Secrets](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) or other modern, evidence based password policies. 46 | * Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes. 47 | * Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected. 48 | * Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts. 49 | 50 | ### Example Attack Scenarios 51 | 52 | **Scenario #1**: [Credential stuffing](/www-community/attacks/Credental_stuffing), the use of [lists of known passwords](https://github.com/danielmiessler/SecLists), is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid. 53 | 54 | **Scenario #2**: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication. 55 | 56 | **Scenario #3**: Application session timeouts aren't set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated. 57 | 58 | ### References 59 | 60 | #### OWASP 61 | 62 | * [OWASP Proactive Controls: Implement Identity and Authentication Controls](/www-community/www-project-proactive-controls) 63 | * [OWASP Application Security Verification Standard: V2 Authentication](/www-community/www-project-application-security-verification-standard) 64 | * [OWASP Application Security Verification Standard: V3 Session Management](/www-community/www-project-application-security-verification-standard) 65 | * [OWASP Testing Guide: Identity, Authentication](/www-community/www-project-testing) 66 | * [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) 67 | * [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) 68 | * [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) 69 | * [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) 70 | * [OWASP Automated Threats Handbook](/www-community/www-project-automated-threats-to-web-applications) 71 | 72 | #### External 73 | 74 | * [NIST 800-63b: 5.1.1 Memorized Secrets](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret) 75 | * [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) 76 | * [CWE-384: Session Fixation](https://cwe.mitre.org/data/definitions/384.html) -------------------------------------------------------------------------------- /cheatsheets/REST_Assessment_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: REST Assessment Cheat Sheet 5 | tags: cheat sheets, REST Assessment 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # About RESTful Web Services 11 | 12 | Web Services are an implementation of web technology used for machine to machine communication. As such they are used for Inter application communication, Web 2.0 and Mashups and by desktop and mobile applications to call a server. 13 | 14 | RESTful web services (often called simply REST) are a light weight variant of Web Services based on the RESTful design pattern. In practice RESTful web services utilizes HTTP requests that are similar to regular HTTP calls in contrast with other Web Services technologies such as SOAP which utilizes a complex protocol. 15 | 16 | # Key relevant properties of RESTful web services 17 | 18 | - Use of HTTP methods (`GET`, `POST`, `PUT` and `DELETE`) as the primary verb for the requested operation. 19 | - Non-standard parameters specifications: 20 | - As part of the URL. 21 | - In headers. 22 | - Structured parameters and responses using JSON or XML in a parameter values, request body or response body. Those are required to communicate machine useful information. 23 | - Custom authentication and session management, often utilizing custom security tokens: this is needed as machine to machine communication does not allow for login sequences. 24 | - Lack of formal documentation. A [proposed standard for describing RESTful web services called WADL](http://www.w3.org/Submission/wadl/) was submitted by Sun Microsystems but was never officially adapted. 25 | 26 | # The challenge of security testing RESTful web services 27 | 28 | - Inspecting the application does not reveal the attack surface, I.e. the URLs and parameter structure used by the RESTful web service. The reasons are: 29 | - No application utilizes all the available functions and parameters exposed by the service 30 | - Those used are often activated dynamically by client side code and not as links in pages. 31 | - The client application is often not a web application and does not allow inspection of the activating link or even relevant code. 32 | - The parameters are none standard making it hard to determine what is just part of the URL or a constant header and what is a parameter worth [fuzzing](https://www.owasp.org/index.php/Fuzzing). 33 | - As a machine interface the number of parameters used can be very large, for example a JSON structure may include dozens of parameters. [fuzzing](https://www.owasp.org/index.php/Fuzzing) each one significantly lengthen the time required for testing. 34 | - Custom authentication mechanisms require reverse engineering and make popular tools not useful as they cannot track a login session. 35 | 36 | # How to pentest a RESTful web service? 37 | 38 | Determine the attack surface through documentation - RESTful pen testing might be better off if some level of white box testing is allowed and you can get information about the service. 39 | 40 | This information will ensure fuller coverage of the attack surface. Such information to look for: 41 | 42 | - Formal service description - While for other types of web services such as SOAP a formal description, usually in WSDL is often available, this is seldom the case for REST. That said, either WSDL 2.0 or WADL can describe REST and are sometimes used. 43 | - A developer guide for using the service may be less detailed but will commonly be found, and might even be considered *black box*. 44 | - Application source or configuration - in many frameworks, including dotNet ,the REST service definition might be easily obtained from configuration files rather than from code. 45 | 46 | Collect full requests using a [proxy](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) - while always an important pen testing step, this is more important for REST based applications as the application UI may not give clues on the actual attack surface. 47 | 48 | Note that the proxy must be able to collect full requests and not just URLs as REST services utilize more than just GET parameters. 49 | 50 | Analyze collected requests to determine the attack surface: 51 | 52 | - Look for non-standard parameters: 53 | - Look for abnormal HTTP headers - those would many times be header based parameters. 54 | - Determine if a URL segment has a repeating pattern across URLs. Such patterns can include a date, a number or an ID like string and indicate that the URL segment is a URL embedded parameter. 55 | - For example: `http://server/srv/2013-10-21/use.php` 56 | - Look for structured parameter values - those may be JSON, XML or a non-standard structure. 57 | - If the last element of a URL does not have an extension, it may be a parameter. This is especially true if the application technology normally uses extensions or if a previous segment does have an extension. 58 | - For example: `http://server/svc/Grid.asmx/GetRelatedListItems` 59 | - Look for highly varying URL segments - a single URL segment that has many values may be parameter and not a physical directory. 60 | - For example if the URL `http://server/src/XXXX/page` repeats with hundreds of value for `XXXX`, chances `XXXX` is a parameter. 61 | 62 | Verify non-standard parameters: in some cases (but not all), setting the value of a URL segment suspected of being a parameter to a value expected to be invalid can help determine if it is a path elements of a parameter. If a path element, the web server will return a *404* message, while for an invalid value to a parameter the answer would be an application level message as the value is legal at the web server level. 63 | 64 | Analyzing collected requests to optimize [fuzzing](https://www.owasp.org/index.php/Fuzzing) - after identifying potential parameters to fuzz, analyze the collected values for each to determine: 65 | 66 | - Valid vs. invalid values, so that [fuzzing](https://www.owasp.org/index.php/Fuzzing) can focus on marginal invalid values. 67 | - For example sending *0* for a value found to be always a positive integer. 68 | - Sequences allowing to fuzz beyond the range presumably allocated to the current user. 69 | 70 | Lastly, when [fuzzing](https://www.owasp.org/index.php/Fuzzing), don't forget to emulate the authentication mechanism used. 71 | 72 | # Related Resources 73 | 74 | - [REST Security Cheat Sheet](REST_Security_Cheat_Sheet.md) - the other side of this cheat sheet 75 | - [RESTful services, web security blind spot](https://xiom.com/2016/10/31/restful-services-web-security-blind-spot/) - a presentation (including video) elaborating on most of the topics on this cheat sheet. -------------------------------------------------------------------------------- /cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: LDAP Injection Prevention Cheat Sheet 5 | tags: cheat sheets, LDAP Injection Prevention 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | This cheatsheet is focused on providing clear, simple, actionable guidance for preventing LDAP Injection flaws in your applications. 13 | 14 | LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it's possible to modify LDAP statements through techniques similar to [SQL Injection](https://www.owasp.org/index.php/SQL_Injection). 15 | 16 | LDAP injection attacks could result in the granting of permissions to unauthorized queries, and content modification inside the LDAP tree. 17 | 18 | For more information on LDAP Injection attacks, visit [LDAP injection](https://www.owasp.org/index.php/LDAP_injection). 19 | 20 | [LDAP injection](https://www.owasp.org/index.php/LDAP_injection) attacks are common due to two factors: 21 | 22 | 1. The lack of safer, parameterized LDAP query interfaces 23 | 2. The widespread use of LDAP to authenticate users to systems. 24 | 25 | Primary Defenses: 26 | 27 | - Escape all variables using the right LDAP encoding function 28 | 29 | Additional Defenses: 30 | 31 | - Use a framework (like [LINQtoAD](https://archive.codeplex.com/?p=linqtoad)) that escapes automatically. 32 | 33 | # Primary Defenses 34 | 35 | ## Defense Option 1: Escape all variables using the right LDAP encoding function 36 | 37 | The main way LDAP stores names is based on DN (distinguished name). You can think of this like a unique identifier. These are sometimes used to access resources, like a username. 38 | 39 | A DN might look like this 40 | 41 | `cn=Richard Feynman, ou=Physics Department, dc=Caltech, dc=edu` 42 | 43 | or 44 | 45 | `uid=inewton, ou=Mathematics Department, dc=Cambridge, dc=com` 46 | 47 | There are certain characters that are considered special characters in a DN. 48 | 49 | The [exhaustive list](https://ldapwiki.com/wiki/DN%20Escape%20Values) is the following: `\ # + < > , ; " =` and leading or trailing spaces. 50 | 51 | Some "special" characters that are allowed in Distinguished Names and do not need to be escaped include: 52 | 53 | ```text 54 | * ( ) . & - _ [ ] ` ~ | @ $ % ^ ? : { } ! ' 55 | ``` 56 | 57 | Each DN points to exactly 1 entry, which can be thought of sort of like a row in a RDBMS. For each entry, there will be 1 or more attributes which are analogous to RDBMS columns. If you are interested in searching through LDAP for users will certain attributes, you may do so with search filters. 58 | 59 | In a search filter, you can use standard boolean logic to get a list of users matching an arbitrary constraint. Search filters are written in Polish notation AKA prefix notation. 60 | 61 | Example: 62 | 63 | ```text 64 | (&(ou=Physics)(| 65 | (manager=cn=Freeman Dyson,ou=Physics,dc=Caltech,dc=edu) 66 | (manager=cn=Albert Einstein,ou=Physics,dc=Princeton,dc=edu) 67 | )) 68 | ``` 69 | 70 | When building LDAP queries in application code, you MUST escape any untrusted data that is added to any LDAP query. There are two forms of LDAP escaping. Encoding for LDAP Search and Encoding for LDAP DN (distinguished name). The proper escaping depends on whether you are sanitizing input for a search filter, or you are using a DN as a username-like credential for accessing some resource. 71 | 72 | ### Safe Java Escaping Example 73 | 74 | - [Prevent LDAP injection](https://wiki.sei.cmu.edu/confluence/spaces/flyingpdf/pdfpageexport.action?pageId=88487534). 75 | - [Legacy OWASP ESAPI for Java DefaultEncoder which includes encodeForLDAP(String) and encodeForDN(String)](https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/reference/DefaultEncoder.java). 76 | 77 | ### Safe C Sharp .NET TBA Example 78 | 79 | [.NET AntiXSS](https://blogs.msdn.microsoft.com/securitytools/2010/09/30/antixss-4-0-released/) (now the Encoder class) has LDAP encoding functions including `Encoder.LdapFilterEncode(string)`, `Encoder.LdapDistinguishedNameEncode(string)` and `Encoder.LdapDistinguishedNameEncode(string, bool, bool)`. 80 | 81 | `Encoder.LdapFilterEncode` encodes input according to [RFC4515](https://tools.ietf.org/search/rfc4515) where unsafe values are converted to `\XX` where `XX` is the representation of the unsafe character. 82 | 83 | `Encoder.LdapDistinguishedNameEncode` encodes input according to [RFC2253](https://tools.ietf.org/html/rfc2253) where unsafe characters are converted to `#XX` where `XX` is the representation of the unsafe character and the comma, plus, quote, slash, less than and great than signs are escaped using slash notation (`\X`). In addition to this a space or octothorpe (`#`) at the beginning of the input string is `\` escaped as is a space at the end of a string. 84 | 85 | `LdapDistinguishedNameEncode(string, bool, bool)` is also provided so you may turn off the initial or final character escaping rules, for example if you are concatenating the escaped distinguished name fragment into the midst of a complete distinguished name. 86 | 87 | ## Defense Option 2: Use Frameworks that Automatically Protect from LDAP Injection 88 | 89 | Safe NET Example 90 | 91 | [LINQ to Active Directory](https://linqtoad.codeplex.com) provides automatic LDAP encoding when building LDAP queries. 92 | 93 | ## Defense Option 3: Additional Defenses 94 | 95 | Beyond adopting one of the two primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are: 96 | 97 | - **Least Privilege** 98 | - **White List Input Validation** 99 | 100 | ### Least Privilege 101 | 102 | To minimize the potential damage of a successful LDAP injection attack, you should minimize the privileges assigned to the LDAP binding account in your environment. 103 | 104 | ### White List Input Validation 105 | 106 | Input validation can be used to detect unauthorized input before it is passed to the LDAP query. For more information please see the [Input Validation Cheat Sheet](Input_Validation_Cheat_Sheet.md). 107 | 108 | # Related Articles 109 | 110 | - OWASP article on [LDAP Injection](https://www.owasp.org/index.php/LDAP_injection) Vulnerabilities. 111 | - OWASP article on [Preventing LDAP Injection in Java](https://www.owasp.org/index.php/Preventing_LDAP_Injection_in_Java). 112 | - [OWASP Testing Guide](https://www.owasp.org/index.php/OWASP_Testing_Project) article on how to [Test for LDAP Injection](https://www.owasp.org/index.php/Testing_for_LDAP_Injection_%28OTG-INPVAL-006%29) Vulnerabilities. -------------------------------------------------------------------------------- /OWASP_Top_Ten_2017/Top_10-2017_A3-Sensitive_Data_Exposure.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: A3-Sensitive Data Exposure 5 | author: 6 | contributors: 7 | tags: OWASP Top Ten 2017, Top Ten, A3 8 | document: OWASP Top Ten 2017 9 | order: 8 10 | exploitability: 2 11 | prevalence: 3 12 | detectability: 2 13 | technical: 3 14 | 15 | --- 16 | 17 | {% include impacts.html %} 18 | 19 | * **Threat Agents/Attack Vectors**: Rather than directly attacking crypto, attackers steal keys, execute man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user’s client, e.g. browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs). 20 | * **Security Weakness**: Over the last few years, this has been the most common impactful attack. The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm, protocol and cipher usage is common, particularly for weak password hashing storage techniques. For data in transit, server side weaknesses are mainly easy to detect, but hard for data at rest. 21 | * **Impacts**: Failure frequently compromises all data that should have been protected. Typically, this information includes sensitive personal information (PII) data such as health records, credentials, personal data, and credit cards, which often require protection as defined by laws or regulations such as the EU GDPR or local privacy laws. 22 | 23 | --- 24 | 25 | ### Is the Application Vulnerable? 26 | 27 | 28 | The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws, e.g. EU's General Data Protection Regulation (GDPR), or regulations, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data: 29 | 30 | * Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems. 31 | * Are any old or weak cryptographic algorithms used either by default or in older code? 32 | * Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? 33 | * Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing? 34 | * Does the user agent (e.g. app, mail client) not verify if the received server certificate is valid? 35 | 36 | See [ASVS Crypto (V7), Data Protection (V9), and SSL/TLS (V10)](/www-project-application-security-verification-standard) 37 | 38 | ### How to Prevent 39 | 40 | Do the following, at a minimum, and consult the references: 41 | 42 | * Classify data processed, stored or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs. 43 | * Apply controls as per the classification. 44 | * Don't store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen. 45 | * Make sure to encrypt all sensitive data at rest. 46 | * Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management. 47 | * Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security ([HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html)). 48 | * Disable caching for response that contain sensitive data. 49 | * Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as [Argon2](https://www.cryptolux.org/index.php/Argon2), [scrypt](https://wikipedia.org/wiki/Scrypt), [bcrypt](https://wikipedia.org/wiki/Bcrypt) or [PBKDF2](https://wikipedia.org/wiki/PBKDF2). 50 | * Verify independently the effectiveness of configuration and settings. 51 | 52 | ### Example Attack Scenarios 53 | 54 | **Scenario #1**: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. 55 | 56 | **Scenario #2**: A site doesn't use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer. 57 | 58 | **Scenario #3**: The password database uses unsalted or simple hashes to store everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted. 59 | 60 | ### References 61 | 62 | #### OWASP 63 | 64 | * [OWASP Proactive Controls: Protect Data](/www-project-proactive-controls) 65 | * [OWASP Application Security Verification Standard (V7, 9, 10)](/www-project-application-security-verification-standard) 66 | * [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) 67 | * [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) 68 | * [OWASP Cheat Sheet: Password and Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) 69 | * [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) 70 | * [OWASP Testing Guide: Testing for weak cryptography](/www-project-testing) 71 | 72 | #### External 73 | 74 | * [CWE-220: Exposure of sens. information through data queries](https://cwe.mitre.org/data/definitions/220.html) 75 | * [CWE-310: Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) 76 | * [CWE-311: Missing Encryption](https://cwe.mitre.org/data/definitions/311.html) 77 | * [CWE-312: Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) 78 | * [CWE-319: Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) 79 | * [CWE-326: Weak Encryption](https://cwe.mitre.org/data/definitions/326.html) 80 | * [CWE-327: Broken/Risky Crypto](https://cwe.mitre.org/data/definitions/327.html) 81 | * [CWE-359: Exposure of Private Information (Privacy Violation)](https://cwe.mitre.org/data/definitions/359.html) -------------------------------------------------------------------------------- /cheatsheets/Query_Parameterization_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Query Parameterization Cheat Sheet 5 | tags: cheat sheets, Query Parameterization 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | [SQL Injection](https://www.owasp.org/index.php/SQL_Injection) is one of the most dangerous web vulnerabilities. So much so that it's the [\#1 item in the OWASP Top 10](https://www.owasp.org/index.php/Top_10_2013-A1-Injection). 13 | 14 | It represents a serious threat because SQL Injection allows evil attacker code to change the structure of a web application's SQL statement in a way that can steal data, modify data, or potentially facilitate command injection to the underlying OS. 15 | 16 | This cheat sheet is a derivative work of the [SQL Injection Prevention Cheat Sheet](SQL_Injection_Prevention_Cheat_Sheet.md). 17 | 18 | # Parameterized Query Examples 19 | 20 | SQL Injection is best prevented through the use of [*parameterized queries*](SQL_Injection_Prevention_Cheat_Sheet.md). The following chart demonstrates, with real-world code samples, how to build parameterized queries in most of the common web languages. The purpose of these code samples is to demonstrate to the web developer how to avoid SQL Injection when building database queries within a web application. 21 | 22 | ## Prepared Statement Examples 23 | 24 | ### Using Java built-in feature 25 | 26 | ```java 27 | String custname = request.getParameter("customerName"); 28 | String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; 29 | PreparedStatement pstmt = connection.prepareStatement( query ); 30 | pstmt.setString( 1, custname); 31 | ResultSet results = pstmt.executeQuery( ); 32 | ``` 33 | 34 | ### Using Java with Hibernate 35 | 36 | ```java 37 | //HQL 38 | @Entity // declare as entity; 39 | @NamedQuery( 40 | name="findByDescription", 41 | query="FROM Inventory i WHERE i.productDescription = :productDescription" 42 | ) 43 | public class Inventory implements Serializable { 44 | @Id 45 | private long id; 46 | private String productDescription; 47 | } 48 | 49 | // use case 50 | // This should REALLY be validated too 51 | String userSuppliedParameter = request.getParameter("Product-Description"); 52 | // perform input validation to detect attacks 53 | List list = 54 | session.getNamedQuery("findByDescription") 55 | .setParameter("productDescription", userSuppliedParameter).list(); 56 | 57 | //Criteria API 58 | // This should REALLY be validated too 59 | String userSuppliedParameter = request.getParameter("Product-Description"); 60 | // perform input validation to detect attacks 61 | Inventory inv = (Inventory) session.createCriteria(Inventory.class).add 62 | (Restrictions.eq("productDescription", userSuppliedParameter)).uniqueResult(); 63 | ``` 64 | 65 | ### Using .NET built-in feature 66 | 67 | ```csharp 68 | String query = "SELECT account_balance FROM user_data WHERE user_name = ?"; 69 | try { 70 | OleDbCommand command = new OleDbCommand(query, connection); 71 | command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text)); 72 | OleDbDataReader reader = command.ExecuteReader(); 73 | // … 74 | } catch (OleDbException se) { 75 | // error handling 76 | } 77 | ``` 78 | 79 | ### Using ASP .NET built-in feature 80 | 81 | ```csharp 82 | string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId"; 83 | SqlCommand command = new SqlCommand(sql); 84 | command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int)); 85 | command.Parameters["@CustomerId"].Value = 1; 86 | ``` 87 | 88 | ### Using Ruby with ActiveRecord 89 | 90 | ```ruby 91 | # Create 92 | Project.create!(:name => 'owasp') 93 | # Read 94 | Project.all(:conditions => "name = ?", name) 95 | Project.all(:conditions => { :name => name }) 96 | Project.where("name = :name", :name => name) 97 | # Update 98 | project.update_attributes(:name => 'owasp') 99 | # Delete 100 | Project.delete(:name => 'name') 101 | ``` 102 | 103 | ### Using Ruby built-in feature 104 | 105 | ```ruby 106 | insert_new_user = db.prepare "INSERT INTO users (name, age, gender) VALUES (?, ? ,?)" 107 | insert_new_user.execute 'aizatto', '20', 'male' 108 | ``` 109 | 110 | ### Using PHP with PHP Data Objects 111 | 112 | ```php 113 | $stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)"); 114 | $stmt->bindParam(':name', $name); 115 | $stmt->bindParam(':value', $value); 116 | ``` 117 | 118 | ### Using Cold Fusion built-in feature 119 | 120 | ```coldfusion 121 | 122 | SELECT * FROM #strDatabasePrefix#_courses WHERE intCourseID = 123 | 124 | 125 | ``` 126 | 127 | ### Using PERL with Database Independent Interface 128 | 129 | ```perl 130 | my $sql = "INSERT INTO foo (bar, baz) VALUES ( ?, ? )"; 131 | my $sth = $dbh->prepare( $sql ); 132 | $sth->execute( $bar, $baz ); 133 | ``` 134 | 135 | ## Stored Procedure Examples 136 | 137 | The SQL you write in your web application isn't the only place that SQL injection vulnerabilities can be introduced. If you are using Stored Procedures, and you are dynamically constructing SQL inside them, you can also introduce SQL injection vulnerabilities. 138 | 139 | To ensure this dynamic SQL is secure, you can parameterize this dynamic SQL too using bind variables. 140 | 141 | Here are some examples of using bind variables in stored procedures in different databases. 142 | 143 | ### Oracle using PL/SQL 144 | 145 | #### Normal Stored Procedure 146 | 147 | No dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required: 148 | 149 | ```sql 150 | PROCEDURE SafeGetBalanceQuery(UserID varchar, Dept varchar) AS BEGIN 151 | SELECT balance FROM accounts_table WHERE user_ID = UserID AND department = Dept; 152 | END; 153 | ``` 154 | 155 | #### Stored Procedure Using Bind Variables in SQL Run with EXECUTE 156 | 157 | Bind variables are used to tell the database that the inputs to this dynamic SQL are 'data' and not possibly code: 158 | 159 | ```sql 160 | PROCEDURE AnotherSafeGetBalanceQuery(UserID varchar, Dept varchar) 161 | AS stmt VARCHAR(400); result NUMBER; 162 | BEGIN 163 | stmt := 'SELECT balance FROM accounts_table WHERE user_ID = :1 164 | AND department = :2'; 165 | EXECUTE IMMEDIATE stmt INTO result USING UserID, Dept; 166 | RETURN result; 167 | END; 168 | ``` 169 | 170 | ### SQL Server using Transact-SQL 171 | 172 | #### Normal Stored Procedure 173 | 174 | No dynamic SQL being created. Parameters passed in to stored procedures are naturally bound to their location within the query without anything special being required: 175 | 176 | ```sql 177 | PROCEDURE SafeGetBalanceQuery(@UserID varchar(20), @Dept varchar(10)) AS BEGIN 178 | SELECT balance FROM accounts_table WHERE user_ID = @UserID AND department = @Dept 179 | END 180 | ``` 181 | 182 | #### Stored Procedure Using Bind Variables in SQL Run with EXEC 183 | 184 | Bind variables are used to tell the database that the inputs to this dynamic SQL are 'data' and not possibly code: 185 | 186 | ```sql 187 | PROCEDURE SafeGetBalanceQuery(@UserID varchar(20), @Dept varchar(10)) AS BEGIN 188 | DECLARE @sql VARCHAR(200) 189 | SELECT @sql = 'SELECT balance FROM accounts_table WHERE ' 190 | + 'user_ID = @UID AND department = @DPT' 191 | EXEC sp_executesql @sql, 192 | '@UID VARCHAR(20), @DPT VARCHAR(10)', 193 | @UID=@UserID, @DPT=@Dept 194 | END 195 | ``` 196 | 197 | # References 198 | 199 | - [The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures](http://bobby-tables.com/) 200 | - OWASP [SQL Injection Prevention Cheat Sheet](SQL_Injection_Prevention_Cheat_Sheet.md) -------------------------------------------------------------------------------- /cheatsheets/Access_Control_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Access Control Cheat Sheet 5 | tags: cheat sheets, Access Control 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | 11 | # Introduction 12 | 13 | This article is focused on providing clear, simple, actionable guidance for providing access control security in your applications. The objective is to provide guidance to developers, reviewers, designers, architects on designing, creating and maintaining access controls in web applications. 14 | 15 | ## What is Access Control / Authorization? 16 | 17 | Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused. Authentication is providing and validating identity. Authorization includes the execution rules that determine what functionality and data the user (or Principal) may access, ensuring the proper allocation of access rights after authentication is successful. 18 | 19 | Web applications need access controls to allow users (with varying privileges) to use the application. They also need administrators to manage the applications access control rules and the granting of permissions or entitlements to users and other entities. Various access control design methodologies are available. To choose the most appropriate one, a risk assessment needs to be performed to identify threats and vulnerabilities specific to your application, so that the proper access control methodology is appropriate for your application. 20 | 21 | ## Access Control Policy 22 | 23 | Why do we need an access control policy for web development? 24 | 25 | The intention of having an access control policy is to ensure that security requirements are described clearly to architects, designers, developers and support team, such that access control functionality is designed and implemented in a consistent manner. 26 | 27 | # Role-Based Access Control (RBAC) 28 | 29 | In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base. 30 | 31 | The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as a doctor, nurse, attendant, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.). 32 | 33 | An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. 34 | 35 | The advantages of using this methodology are: 36 | 37 | - Roles are assigned based on organizational structure with emphasis on the organizational security policy 38 | - Easy to use 39 | - Easy to administer 40 | - Built into most frameworks 41 | - Aligns with security principles like segregation of duties and least privileges 42 | 43 | Problems that can be encountered while using this methodology: 44 | 45 | - Documentation of the roles and accesses has to be maintained stringently. 46 | - Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements, e.g. OU in Active Directory 47 | - There is a tendency for scope creep to happen, e.g. more accesses and privileges can be given than intended for. Or a user might be included in two roles if proper access reviews and subsequent revocation is not performed. 48 | - Does not support data-based access control 49 | 50 | The areas of caution while using RBAC are: 51 | 52 | - Roles must be only be transferred or delegated using strict sign-offs and procedures. 53 | - When a user changes his role to another one, the administrator must make sure that the earlier access is revoked such that at any given point of time, a user is assigned to only those roles on a need to know basis. 54 | - Assurance for RBAC must be carried out using strict access control reviews. 55 | 56 | # Discretionary Access Control (DAC) 57 | 58 | Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of the information or any resource is able to change its permissions at his discretion (thus the name). 59 | 60 | A DAC framework can provide web application security administrators with the ability to implement fine-grained access control. This model can be a basis for data-based access control implementation 61 | 62 | The advantages of using this model are: 63 | 64 | - Easy to use 65 | - Easy to administer 66 | - Aligns to the principle of least privileges. 67 | - Object owner has total control over access granted 68 | 69 | Problems that can be encountered while using this methodology: 70 | 71 | - Documentation of the roles and accesses has to be maintained stringently. 72 | - Multi-tenancy can not be implemented effectively unless there is a way to associate the roles with multi-tenancy capability requirements, e.g. OU in Active Directory 73 | - There is a tendency for scope creep to happen, e.g. more accesses and privileges can be given than intended for. 74 | 75 | The areas of caution while using DAC are: 76 | 77 | - While granting trusts 78 | - Assurance for DAC must be carried out using strict access control reviews. 79 | 80 | # Mandatory Access Control (MAC) 81 | 82 | Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. MAC is usually appropriate for extremely secure systems, including multilevel secure military applications or mission-critical data applications. 83 | 84 | The advantages of using this methodology are: 85 | 86 | - Access to an object is based on the sensitivity of the object 87 | - Access based on the need to know is strictly adhered to, and scope creep has minimal possibility 88 | - Only an administrator can grant access 89 | 90 | Problems that can be encountered while using this methodology: 91 | 92 | - Difficult and expensive to implement 93 | - Not agile 94 | 95 | The areas of caution while using MAC are: 96 | 97 | - Classification and sensitivity assignment at an appropriate and pragmatic level 98 | - Assurance for MAC must be carried out to ensure that the classification of the objects is at the appropriate level. 99 | 100 | # Permission Based Access Control 101 | 102 | The key concept in Permission Based Access Control is the abstraction of application actions into a set of *permissions*. A *permission* may be represented simply as a string-based name, for example, "READ". Access decisions are made by checking if the current user *has* the permission associated with the requested application action. 103 | 104 | The *has* relationship between the user and permission may be satisfied by creating a direct relationship between the user and permission (called a *grant*), or an indirect one. In the indirect model, the permission *grant* is to an intermediate entity such as *user group*. A user is considered a member of a *user group* if and only if the user *inherits* permissions from the *user group*. The indirect model makes it easier to manage the permissions for a large number of users since changing the permissions assigned to the user group affects all members of the user group. 105 | 106 | In some Permission Based Access Control systems that provide fine-grained domain object-level access control, permissions may be grouped into *classes*. In this model, it is assumed that each domain object in the system can be associated with a *class* which determines the permissions applicable to the respective domain object. In such a system a "DOCUMENT" class may be defined with the permissions "READ", "WRITE" and DELETE"; a "SERVER" class may be defined with the permissions "START", "STOP", and "REBOOT". 107 | -------------------------------------------------------------------------------- /cheatsheets/JAAS_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: JAAS Cheat Sheet 5 | tags: cheat sheets, JAAS 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction - What is JAAS authentication? 11 | 12 | The process of verifying the identity of a user or another system is authentication. 13 | 14 | [JAAS](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html), as an authentication framework manages the authenticated user's identity and credentials from login to logout. 15 | 16 | The JAAS authentication lifecycle: 17 | 18 | 1. Create `LoginContext`. 19 | 2. Read the configuration file for one or more `LoginModules` to initialize. 20 | 3. Call `LoginContext.initialize()` for each LoginModule to initialize. 21 | 4. Call `LoginContext.login()` for each LoginModule. 22 | 5. If login successful then call `LoginContext.commit()` else call `LoginContext.abort()` 23 | 24 | # Configuration file 25 | 26 | The JAAS configuration file contains a `LoginModule` stanza for each `LoginModule` available for logging on to the application. 27 | 28 | A stanza from a JAAS configuration file: 29 | 30 | ```text 31 | Branches 32 | { 33 | USNavy.AppLoginModule required 34 | debug=true 35 | succeeded=true; 36 | } 37 | ``` 38 | 39 | Note the placement of the semicolons, terminating both `LoginModule` entries and stanzas. 40 | 41 | The word required indicates the `LoginContext`'s `login()` method must be successful when logging in the user. The `LoginModule`-specific values `debug` and `succeeded` are passed to the `LoginModule`. 42 | 43 | They are defined by the `LoginModule` and their usage is managed inside the `LoginModule`. Note, Options are Configured using key-value pairing such as `debug="true"` and the key and value should be separated by a `=` sign. 44 | 45 | # Main.java (The client) 46 | 47 | - Execution syntax: 48 | 49 | ```text 50 | Java –Djava.security.auth.login.config==packageName/packageName.config 51 | packageName.Main Stanza1 52 | 53 | Where: 54 | packageName is the directory containing the config file. 55 | packageName.config specifies the config file in the Java package, packageName. 56 | packageName.Main specifies Main.java in the Java package, packageName. 57 | Stanza1 is the name of the stanza Main() should read from the config file. 58 | ``` 59 | 60 | - When executed, the 1st command line argument is the stanza from the config file. The Stanza names the `LoginModule` to be used. The 2nd argument is the `CallbackHandler`. 61 | - Create a new `LoginContext` with the arguments passed to `Main.java`. 62 | - `loginContext = new LoginContext (args[0], new AppCallbackHandler());` 63 | - Call the LoginContext.Login Module: 64 | - `loginContext.login();` 65 | - The value in succeeded Option is returned from `loginContext.login()`. 66 | - If the login was successful, a subject was created. 67 | 68 | # LoginModule.java 69 | 70 | A `LoginModule` must have the following authentication methods: 71 | 72 | - `initialize()` 73 | - `login()` 74 | - `commit()` 75 | - `abort()` 76 | - `logout()` 77 | 78 | ## initialize() 79 | 80 | In `Main()`, after the `LoginContext` reads the correct stanza from the config file, the `LoginContext` instantiates the `LoginModule` specified in the stanza. 81 | 82 | - `initialize()` methods signature: 83 | - `Public void initialize (Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)` 84 | - The arguments above should be saved as follows: 85 | - `this.subject = subject;` 86 | - `this.callbackHandler = callbackHandler;` 87 | - `this.sharedState = sharedState;` 88 | - `this.options = options;` 89 | - What the `initialize()` method does: 90 | - Builds a subject object of the `Subject` class contingent on a successful `login()`. 91 | - Sets the `CallbackHandler` which interacts with the user to gather login information. 92 | - If a `LoginContext` specifies 2 or more LoginModules, which is legal, they can share information via a `sharedState` map. 93 | - Saves state information such as debug and succeeded in an options Map. 94 | 95 | ## login() 96 | 97 | Captures user supplied login information. The code snippet below declares an array of two callback objects which, when passed to the `callbackHandler.handle` method in the `callbackHandler.java` program, will be loaded with a user name and password provided interactively by the user: 98 | 99 | ```java 100 | NameCallback nameCB = new NameCallback("Username"); 101 | PasswordCallback passwordCB = new PasswordCallback ("Password", false); 102 | Callback[] callbacks = new Callback[] { nameCB, passwordCB }; 103 | callbackHandler.handle (callbacks); 104 | ``` 105 | 106 | - Authenticates the user 107 | - Retrieves the user supplied information from the callback objects: 108 | - `String ID = nameCallback.getName ();` 109 | - `char[] tempPW = passwordCallback.getPassword ();` 110 | - Compare `name` and `tempPW` to values stored in a repository such as LDAP. 111 | - Set the value of the variable succeeded and return to `Main()`. 112 | 113 | ## commit() 114 | 115 | Once the users credentials are successfully verified during `login()`, the JAAS authentication framework associates the credentials, as needed, with the subject. 116 | 117 | There are two types of credentials, **Public** and **Private**: 118 | - Public credentials include public keys. 119 | - Private credentials include passwords and public keys. 120 | 121 | Principals (i.e. Identities the subject has other than their login name) such as employee number or membership ID in a user group are added to the subject. 122 | 123 | Below, is an example `commit()` method where first, for each group the authenticated user has membership in, the group name is added as a principal to the subject. The subject's username is then added to their public credentials. 124 | 125 | Code snippet setting then adding any principals and a public credentials to a subject: 126 | 127 | ```java 128 | public boolean commit() { 129 | If (userAuthenticated) { 130 | Set groups = UserService.findGroups (username); 131 | for (Iterator itr = groups.iterator (); itr.hasNext (); { 132 | String groupName = (String) itr.next (); 133 | UserGroupPrincipal group = new UserGroupPrincipal (GroupName); 134 | subject.getPrincipals ().add (group); 135 | } 136 | UsernameCredential cred = new UsernameCredential (username); 137 | subject.getPublicCredentials().add (cred); 138 | } 139 | } 140 | ``` 141 | 142 | ## abort() 143 | 144 | The `abort()` method is called when authentication doesn't succeed. Before the `abort()` method exits the `LoginModule`, care should be taken to reset state including the user name and password input fields. 145 | 146 | ## logout() 147 | 148 | The release of the users principals and credentials when `LoginContext.logout` is called: 149 | 150 | ```java 151 | public boolean logout() { 152 | if (!subject.isReadOnly()) { 153 | Set principals = subject.getPrincipals(UserGroupPrincipal.class); 154 | subject.getPrincipals().removeAll(principals); 155 | Set creds = subject.getPublicCredentials(UsernameCredential.class); 156 | subject.getPublicCredentials().removeAll(creds); 157 | return true; 158 | } else { 159 | return false; 160 | } 161 | } 162 | ``` 163 | 164 | # CallbackHandler.java 165 | 166 | The `callbackHandler` is in a source (`.java`) file separate from any single `LoginModule` so that it can service a multitude of LoginModules with differing callback objects: 167 | 168 | - Creates instance of the `CallbackHandler` class and has only one method, `handle()`. 169 | - A `CallbackHandler` servicing a LoginModule requiring username & password to login: 170 | 171 | ```java 172 | public void handle(Callback[] callbacks) { 173 | for (int i = 0; i < callbacks.length; i++) { 174 | Callback callback = callbacks[i]; 175 | if (callback instanceof NameCallback) { 176 | NameCallback nameCallBack = (NameCallback) callback; 177 | nameCallBack.setName(username); 178 | } else if (callback instanceof PasswordCallback) { 179 | PasswordCallback passwordCallBack = (PasswordCallback) callback; 180 | passwordCallBack.setPassword(password.toCharArray()); 181 | } 182 | } 183 | } 184 | ``` 185 | 186 | # Related Articles 187 | 188 | - [JAAS in Action](https://jaasbook.wordpress.com/2009/09/27/intro/), Michael Coté, posted on September 27, 2009, URL as 5/14/2012. 189 | - Pistoia Marco, Nagaratnam Nataraj, Koved Larry, Nadalin Anthony from book ["Enterprise Java Security" - Addison-Wesley, 2004](https://www.oreilly.com/library/view/enterprise-javatm-security/0321118898/). 190 | 191 | # Disclosure 192 | 193 | All of the code in the attached JAAS cheat sheet has been copied verbatim from this [free source](https://jaasbook.wordpress.com/2009/09/27/intro/). -------------------------------------------------------------------------------- /cheatsheets/Mass_Assignment_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Mass Assignment Cheat Sheet 5 | tags: cheat sheets, Mass Assignment 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | ## Definition 13 | 14 | Software frameworks sometime allow developers to automatically bind HTTP request parameters into program code variables or objects to make using that framework easier on developers. This can sometimes cause harm. 15 | 16 | Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended. 17 | 18 | This is called a **Mass Assignment** vulnerability. 19 | 20 | ## Alternative Names 21 | 22 | Depending on the language/framework in question, this vulnerability can have several [alternative names](https://cwe.mitre.org/data/definitions/915.html): 23 | 24 | - **Mass Assignment:** Ruby on Rails, NodeJS. 25 | - **Autobinding:** Spring MVC, ASP NET MVC. 26 | - **Object injection:** PHP. 27 | 28 | ## Example 29 | 30 | Suppose there is a form for editing a user's account information: 31 | 32 | ```html 33 |
34 |       35 |       36 |       37 |       38 |
   39 | ``` 40 | 41 | Here is the object that the form is binding to: 42 | 43 | ```java 44 | public class User { 45 |    private String userid; 46 |    private String password; 47 |    private String email; 48 |    private boolean isAdmin; 49 |   50 |    //Getters & Setters 51 | } 52 | ``` 53 | 54 | Here is the controller handling the request: 55 | 56 | ```java 57 | @RequestMapping(value = "/addUser", method = RequestMethod.POST) 58 | public String submit(User user) {    59 |    userService.add(user); 60 |    return "successPage"; 61 | } 62 | ``` 63 | 64 | Here is the typical request: 65 | 66 | ```text 67 | POST /addUser 68 | ... 69 | userid=bobbytables&password=hashedpass&email=bobby@tables.com 70 | ``` 71 | 72 | And here is the exploit in which we set the value of the attribute `isAdmin` of the instance of the class `User`: 73 | 74 | ```text 75 | POST /addUser 76 | ... 77 | userid=bobbytables&password=hashedpass&email=bobby@tables.com&isAdmin=true 78 | ``` 79 | 80 | ## Exploitability 81 | 82 | This functionality becomes exploitable when: 83 | 84 | - Attacker can guess common sensitive fields. 85 | - Attacker has access to source code and can review the models for sensitive fields. 86 | - AND the object with sensitive fields has an empty constructor. 87 | 88 | ## GitHub case study 89 | 90 | In 2012, GitHub was hacked using mass assignment. A user was able to upload his public key to any organization and thus make any subsequent changes in their repositories. [GitHub's Blog Post](https://blog.github.com/2012-03-04-public-key-security-vulnerability-and-mitigation/). 91 | 92 | ## Solutions 93 | 94 | - Whitelist the bindable, non-sensitive fields. 95 | - Blacklist the non-bindable, sensitive fields. 96 | - Use [Data Transfer Objects](https://martinfowler.com/eaaCatalog/dataTransferObject.html) (DTOs). 97 | 98 | # General Solutions 99 | 100 | An architectural approach is to create Data Transfer Objects and avoid binding input directly to domain objects. Only the fields that are meant to be editable by the user are included in the DTO. 101 | 102 | ```java 103 | public class UserRegistrationFormDTO { 104 |  private String userid; 105 |  private String password; 106 |  private String email; 107 | 108 |  //NOTE: isAdmin field is not present 109 |   110 |  //Getters & Setters 111 | } 112 | ``` 113 | 114 | # Language & Framework specific solutions 115 | 116 | ## Spring MVC 117 | 118 | ### Whitelisting 119 | 120 | ```java 121 | @Controller 122 | public class UserController 123 | { 124 | @InitBinder 125 | public void initBinder(WebDataBinder binder, WebRequest request) 126 | { 127 | binder.setAllowedFields(["userid","password","email"]); 128 | } 129 | ... 130 | } 131 | ``` 132 | 133 | Take a look [here](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/validation/DataBinder.html#setAllowedFields-java.lang.String...-) for the documentation. 134 | 135 | ### Blacklisting 136 | 137 | ```java 138 | @Controller 139 | public class UserController 140 | { 141 |    @InitBinder 142 |    public void initBinder(WebDataBinder binder, WebRequest request) 143 |    { 144 |       binder.setDisallowedFields(["isAdmin"]); 145 |    } 146 | ... 147 | } 148 | ``` 149 | 150 | Take a look [here](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/validation/DataBinder.html#setDisallowedFields-java.lang.String...-) for the documentation. 151 | 152 | ## NodeJS + Mongoose 153 | 154 | ### Whitelisting 155 | 156 | ```javascript 157 | var UserSchema = new mongoose.Schema({ 158 | userid: String, 159 | password: String, 160 | email : String, 161 | isAdmin : Boolean, 162 | }); 163 | 164 | UserSchema.statics = { 165 | User.userCreateSafeFields: ['userid', 'password', 'email'] 166 | }; 167 | 168 | var User = mongoose.model('User', UserSchema); 169 | 170 | _ = require('underscore'); 171 | var user = new User(_.pick(req.body, User.userCreateSafeFields)); 172 | ``` 173 | 174 | Take a look [here](http://underscorejs.org/#pick) for the documentation. 175 | 176 | ### Blacklisting 177 | 178 | ```javascript 179 | var massAssign = require('mongoose-mass-assign'); 180 |   181 | var UserSchema = new mongoose.Schema({ 182 | userid: String, 183 | password: String, 184 | email : String, 185 | isAdmin : { type: Boolean, protect: true, default: false } 186 | }); 187 |   188 | UserSchema.plugin(massAssign); 189 |   190 | var User = mongoose.model('User', UserSchema); 191 | 192 | /** Static method, useful for creation **/ 193 | var user = User.massAssign(req.body); 194 | 195 | /** Instance method, useful for updating**/ 196 | var user = new User; 197 | user.massAssign(req.body); 198 | 199 | /** Static massUpdate method **/ 200 | var input = { userid: 'bhelx', isAdmin: 'true' }; 201 | User.update({ '_id': someId }, { $set: User.massUpdate(input) }, console.log); 202 | ``` 203 | 204 | Take a look [here](https://www.npmjs.com/package/mongoose-mass-assign) for the documentation. 205 | 206 | ## Ruby On Rails 207 | 208 | Take a look [here](https://guides.rubyonrails.org/v3.2.9/security.html#mass-assignment) for the documentation. 209 | 210 | ## Django 211 | 212 | Take a look [here](https://coffeeonthekeyboard.com/mass-assignment-security-part-10-855/) for the documentation. 213 | 214 | ## ASP NET 215 | 216 | Take a look [here](https://odetocode.com/Blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx) for the documentation. 217 | 218 | ## PHP Laravel + Eloquent 219 | 220 | ### Whitelisting 221 | 222 | ```php 223 | 35 | ``` 36 | 37 | ASP .NET 38 | 39 | ```csharp 40 | Response.Redirect("~/folder/Login.aspx") 41 | ``` 42 | 43 | Rails 44 | 45 | ```ruby 46 | redirect_to login_path 47 | ``` 48 | 49 | In the examples above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker. 50 | 51 | # Dangerous URL Redirects 52 | 53 | The following examples demonstrate unsafe redirect and forward code. 54 | 55 | ## Dangerous URL Redirect Example 1 56 | 57 | The following Java code receives the URL from the parameter named `url` ([GET or POST](https://docs.oracle.com/javaee/7/api/javax/servlet/ServletRequest.html#getParameter-java.lang.String-)) and redirects to that URL: 58 | 59 | ```java 60 | response.sendRedirect(request.getParameter("url")); 61 | ``` 62 | 63 | The following PHP code obtains a URL from the query string (via the parameter named `url`) and then redirects the user to that URL. Additionally, the PHP code after this `header()` function will continue to execute, so if the user configures their browser to ignore the redirect, they may be able to access the rest of the page. 64 | 65 | ```php 66 | $redirect_url = $_GET['url']; 67 | header("Location: " . $redirect_url); 68 | ``` 69 | 70 | A similar example of C\# .NET Vulnerable Code: 71 | 72 | ```csharp 73 | string url = request.QueryString["url"]; 74 | Response.Redirect(url); 75 | ``` 76 | 77 | And in Rails: 78 | 79 | ```ruby 80 | redirect_to params[:url] 81 | ``` 82 | 83 | The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. 84 | 85 | If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example: 86 | 87 | ```text 88 | http://example.com/example.php?url=http://malicious.example.com 89 | ``` 90 | 91 | The user sees the link directing to the original trusted site (`example.com`) and does not realize the redirection that could take place 92 | 93 | ## Dangerous URL Redirect Example 2 94 | 95 | [ASP .NET MVC 1 & 2 websites](https://docs.microsoft.com/en-us/aspnet/mvc/overview/security/preventing-open-redirection-attacks) are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3. 96 | 97 | The code for the LogOn action in an ASP.NET MVC 2 application is shown below. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter. 98 | 99 | ASP.NET MVC 2 LogOn action in `AccountController.cs` (see Microsoft Docs link provided above for the context): 100 | 101 | ```csharp 102 | [HttpPost] 103 | public ActionResult LogOn(LogOnModel model, string returnUrl) 104 | { 105 | if (ModelState.IsValid) 106 | { 107 | if (MembershipService.ValidateUser(model.UserName, model.Password)) 108 | { 109 | FormsService.SignIn(model.UserName, model.RememberMe); 110 | if (!String.IsNullOrEmpty(returnUrl)) 111 | { 112 | return Redirect(returnUrl); 113 | } 114 | else 115 | { 116 | return RedirectToAction("Index", "Home"); 117 | } 118 | } 119 | else 120 | { 121 | ModelState.AddModelError("", "The user name or password provided is incorrect."); 122 | } 123 | } 124 | 125 | // If we got this far, something failed, redisplay form 126 | return View(model); 127 | } 128 | ``` 129 | 130 | ## Dangerous Forward Example 131 | 132 | When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the URL, perform the functions it provides, and it is an appropriate URL request. 133 | 134 | If the application fails to perform these checks, an attacker crafted URL may pass the application's access control check and then forward the attacker to an administrative function that is not normally permitted. 135 | 136 | Example: 137 | 138 | ```text 139 | http://www.example.com/function.jsp?fwd=admin.jsp 140 | ``` 141 | 142 | The following code is a Java servlet that will receive a `GET` request with a url parameter named `fwd` in the request to forward to the address specified in the url parameter. The servlet will retrieve the url parameter value [from the request](https://docs.oracle.com/javaee/7/api/javax/servlet/ServletRequest.html#getParameter-java.lang.String-) and complete the server-side forward processing before responding to the browser. 143 | 144 | ```java 145 | public class ForwardServlet extends HttpServlet 146 | { 147 | protected void doGet(HttpServletRequest request, HttpServletResponse response) 148 | throws ServletException, IOException { 149 | String query = request.getQueryString(); 150 | if (query.contains("fwd")) 151 | { 152 | String fwd = request.getParameter("fwd"); 153 | try 154 | { 155 | request.getRequestDispatcher(fwd).forward(request, response); 156 | } 157 | catch (ServletException e) 158 | { 159 | e.printStackTrace(); 160 | } 161 | } 162 | } 163 | } 164 | ``` 165 | 166 | # Preventing Unvalidated Redirects and Forwards 167 | 168 | Safe use of redirects and forwards can be done in a number of ways: 169 | 170 | - Simply avoid using redirects and forwards. 171 | - If used, do not allow the URL as user input for the destination. 172 | - Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL. 173 | - This provides the highest degree of protection against the attack tampering with the URL. 174 | - Be careful that this doesn't introduce an enumeration vulnerability where a user could cycle through IDs to find all possible redirect targets 175 | - If user input can’t be avoided, ensure that the supplied **value** is valid, appropriate for the application, and is **authorized** for the user. 176 | - Sanitize input by creating a list of trusted URLs (lists of hosts or a regex). 177 | - This should be based on a white-list approach, rather than a blacklist. 178 | - Force all redirects to first go through a page notifying users that they are going off of your site, with the destination clearly displayed, and have them click a link to confirm. 179 | 180 | ## Validating URLs 181 | 182 | When attempting to validate and sanitise user-input to determine whether the URL is safe, wherever possible you should use a built in library or function to parse the URLs, such as `parse_url()` in PHP, rather than rolling your own parser using regex. Additionally, make sure that you take the following into account: 183 | 184 | - Input starting with a `/` to redirect to local pages is **not safe**. `//example.org` is a valid URL. 185 | - Input starting with the desired domain name is **not safe**. `https://example.org.attacker.com` is valid. 186 | - Only allow HTTP(S) protocols. All other protocols, including JavaScript URIs such as `javascript:alert(1)` should be blocked 187 | - Data URIs such as `data:text/html,` should be blocked 188 | - URIs containing CRLF characters can lead to header injection or response splitting attacks, and should be blocked. 189 | 190 | # References 191 | 192 | - [CWE Entry 601 on Open Redirects](http://cwe.mitre.org/data/definitions/601.html). 193 | - [WASC Article on URL Redirector Abuse](http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse) 194 | - [Google blog article on the dangers of open redirects](http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html). 195 | - [Preventing Open Redirection Attacks (C\#)](http://www.asp.net/mvc/tutorials/security/preventing-open-redirection-attacks). 196 | -------------------------------------------------------------------------------- /cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.md: -------------------------------------------------------------------------------- 1 | --- 2 | 3 | layout: col-document 4 | title: Vulnerability Disclosure Cheat Sheet 5 | tags: cheat sheets, Vulnerability Disclosure 6 | document: cheat sheets 7 | 8 | --- 9 | 10 | # Introduction 11 | 12 | This cheatsheet is to help people report vulnerabilities they can find either randomly, either through security research. 13 | 14 | **Disclaimer**: No warranty - consult lawyer! 15 | 16 | # Prepare 17 | 18 | - define the scope 19 | - check if company has 20 | - identified security contacts: typical security@, abuse@, noc@ ([RFC2142](https://www.ietf.org/rfc/rfc2142.txt)) or [public](https://first.org/members/teams/) [CERT](https://www.trusted-introducer.org/directory/teams.html). 21 | - a responsible disclosure web page 22 | - bug bounty program. Example platforms : hackerone, bugcrowd, synack, bountyfactory.io... 23 | - a security.txt file on one of their websites ([website](https://securitytxt.org/), [github repo](https://github.com/securitytxt/security-txt), [ietf draft](https://www.ietf.org/id/draft-foudil-securitytxt-00.txt)) 24 | 25 | # Identify 26 | 27 | Remember if they are rules defined by a bounty program or laws applied to your country. Document every step allowing to identify vulnerability, and if acceptable in your context, how to exploit it. 28 | 29 | # Report 30 | 31 | It is recommended to use responsible disclosure when dealing with vulnerabilities 32 | 33 | - alert the company, multiple times and persons if needed. 34 | - request [CVE Identification](http://cve.mitre.org/cve/request_id)([RedHat CVE HowTo](https://github.com/RedHatProductSecurity/CVE-HOWTO)). 35 | - alert trusted 3rd party like National CERT, Data Privacy regulator if apply. Eventually, some security researchers like [Brian Krebs](https://krebsonsecurity.com/) or [Troy Hunt](https://www.troyhunt.com/) (non-exhaustive. check your network first) can be intermediate too or provide support. 36 | - full/public disclosure 37 | 38 | Depending on your context, each step may have more or less important time interval. Be flexible. ***Encourage trust, transparency and openness***. Timeline of full disclosure is always a debate especially if there is active exploitation. Be considerate of the work necessary to do the fix while balancing with public interest. 39 | 40 | Examples of public disclosure timeline and methodology 41 | 42 | - RFPolicy, Rain Forest Puppy, 2000: [5d](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt) for initial contact 43 | - Google Project Zero: 44 | - [90d](https://googleprojectzero.blogspot.ca/2015/02/feedback-and-data-driven-updates-to.html) after initial notification and 14d grace period 45 | - [7d after if actively exploited Microsoft, 2016](https://www.secpod.com/blog/google-discloses-zero-day-in-windows-kernel/) 46 | - US CERT/CC: [45d](https://www.cert.org/vulnerability-analysis/vul-disclosure.cfm) after initial report 47 | - Internet Engineering Task Force (IETF): [Responsible Vulnerability Disclosure Process](https://tools.ietf.org/html/draft-christey-wysopal-vuln-disclosure-00). Insisted on joined work with no unique timeline 48 | - Microsoft: [Coordinated Vulnerability Disclosure](https://technet.microsoft.com/en-us/security/dn467923) (CVD) 49 | - ISO/IEC [29147:2014](http://www.iso.org/iso/catalogue_detail.htm?csnumber=45170): Vulnerability disclosure 50 | 51 | Report should include all details necessary to understand vulnerability and reproduce it (exploit code for example). If you identify limiting factors, include them (Non-Admin user, use of Ms EMET, security HTTP headers...). 52 | 53 | If possible, use encryption like PGP/GPG to encrypt your report. You can use [Encrypt.to](https://encrypt.to/) to do from a web browser if recipient has a public key. If you want to remain anonymous, it's probably better to use pseudonym and one-time use email on Tor network or similar. Intermediate party might also be available like ZeroDisclo.com but ensure target destination is relevant (In 2017, mostly FR & EU). 54 | 55 | # Aftermath 56 | 57 | If you think your lessons learned would be useful to community, share it (anonymously or not). 58 | 59 | # Legal 60 | 61 | Most western countries have an exception for interoperability and security research but... 62 | 63 | - US: Sec. 103(f) of the DMCA (17 U.S.C. § 1201 (f)) but EULA and contract override law. 64 | - FR: [Art.](https://fr.wikipedia.org/wiki/Rétro-ingénierie#L.C3.A9gislation) [L. 335-3-1 - article 22 du DADVSI](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000266350&categorieLien=id) (2006), [EU Directive 2009/24](http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32009L0024) 65 | - CA: Ambiguous... Bill [C-32](http://www.parl.gc.ca/HousePublications/Publication.aspx?DocId=4580265&Language=e&Mode=1) (2010), Bill [C-11](http://www.parl.gc.ca/HousePublications/Publication.aspx?DocId=5465759) (2011). Criminal code provisions (Bill [C-46](http://laws-lois.justice.gc.ca/eng/acts/C-46/FullText.html)) for testing without permission: 430(1.1) ("Mischief in relation to computer data"), 342.1 ("Unauthorized use of a computer"), 342.2 ("Possession of device to obtain unauthorized use of computer system or to commit mischief"). 66 | 67 | # Definitions 68 | 69 | - Full disclosure 70 | 71 | *Full disclosure is the practice of publishing analysis of software vulnerabilities as early as possible, making the data accessible to everyone without restriction. The primary purpose of widely disseminating information about vulnerabilities is so that potential victims are as knowledgeable as those who attack them.*, [Wikipedia](https://en.wikipedia.org/wiki/Full_disclosure_%28computer_security%29) 72 | 73 | - Responsible disclosure 74 | 75 | *The issue is reported privately to the vendor and no one else until the vendor issues a patch.*, [Microsoft](https://www.microsoft.com/en-us/msrc/cvd), 2010 76 | 77 | - Coordinated disclosure 78 | 79 | *Coordinate public release happens, ideally, when the vendor releases the update. In the case of publicly verifiable active attacks, details may be released prior to an update being released, with emphasis on giving details to protection providers.*, [Microsoft](https://www.microsoft.com/en-us/msrc/cvd), 2010 80 | 81 | - Private disclosure 82 | 83 | *The vulnerability is released to a small group of people (not the vendor) or kept private.* 84 | 85 | Other definitions : [CERT/CC](https://vuls.cert.org/confluence/pages/viewpage.action?pageId=4718642) 86 | 87 | # References 88 | 89 | - [Vulnerability Disclosure](https://www.cert.org/vulnerability-analysis/vul-disclosure.cfm). 90 | - [Debating Full Disclosure](https://www.schneier.com/blog/archives/2007/01/debating_full_d.html), Bruce Schneier, Jan2007. 91 | - [7 Deadly Sins of Website Vulnerability Disclosure](http://blog.jeremiahgrossman.com/2007/07/7-deadly-sins-of-website-vulnerability.html), Jeremiah Grossman, Jul 2007. 92 | - [Notification and disclosure Policy](http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html) (update), Thierry Zoller, Sep 2008. 93 | - [Matt's Guide to Vendor Response](http://blog.talosintelligence.com/2009/12/matts-guide-to-vendor-response.html), Talos, Dec 2009. 94 | - [The responsibility of public disclosure](https://www.troyhunt.com/the-responsibility-of-public-disclosure/), Troy Hunt, May 2013. 95 | - [Approaches to Vulnerability Disclosure](http://blog.opensecurityresearch.com/2014/06/approaches-to-vulnerability-disclosure.html), Brad Antoniewicz, Jun 2014. 96 | - [Reflections on Vulnerability Disclosure Case Studies & Ethical Dilemmas](https://www.ernw.de/download/ACM_SigComm_ENSR_Rey_Vulnerability_Disclosure.pdf), ERNW, ACM 2015. 97 | - [Good Practice Guide on Vulnerability Disclosure. From challenges to recommendations](https://www.enisa.europa.eu/publications/vulnerability-disclosure), ENISA, Jan 2016. 98 | - [Reverse Engineering legality](https://en.wikipedia.org/wiki/Reverse_engineering#Legality). 99 | - [FireEye takes security firm to court over vulnerability disclosure](http://www.pcworld.com/article/2983144/fireeye-takes-security-firm-to-court-over-vulnerability-disclosure.html), sep 2015. 100 | - [Google Discloses Windows Zero-Day Before Microsoft Can Issue Patch](http://www.bleepingcomputer.com/news/security/google-discloses-windows-zero-day-before-microsoft-can-issue-patch/), nov 2016. 101 | - [Bug bounties and extortion](https://scotthelme.co.uk/bug-bounties-and-extortion/), feb 2017. 102 | 103 | # Countries specifics 104 | 105 | - USA 106 | - [Reverse Engineering FAQ](https://www.eff.org/issues/coders/reverse-engineering-faq). 107 | - [DMCA exemption](https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca-security-research-exemption-consumer-devices). 108 | - CANADA 109 | - ['Messenger always gets shot': Hackers say the Canadian government doesn't want their help](http://www.cbc.ca/news/technology/canadian-government-hackers-1.3866336), CBC, Nov 2016. 110 | - [Some thoughts on Bill-C-32: An Act to Modernize Canada's copyright laws](http://www.barrysookman.com/2010/06/03/some-thoughts-on-bill-c-32-an-act-to-modernize-canada%E2%80%99s-copyright-laws/), Barry Sookman, Jun 2010. 111 | - UNITED KINGDOM 112 | - [UK surveillance law raises concerns security researchers could be 'deputised' by the state](https://www.theregister.co.uk/2017/05/31/surveillance_law_compulsion/), TheRegister, May 217. 113 | - FRANCE 114 | - [ANSSI: Notify a security issue](https://www.ssi.gouv.fr/en-cas-dincident/vous-souhaitez-declarer-une-faille-de-securite-ou-une-vulnerabilite/). 115 | - NETHERLAND 116 | - [NCSC: Notify a security issue](https://www.ncsc.nl/english/security). 117 | - LUXEMBURG 118 | - [CIRCL: Notify a security issue](http://circl.lu/report/). 119 | 120 | *Feel free to provide other countries!* --------------------------------------------------------------------------------