Difference between revisions of "Category:OWASP Source Code Flaws Top 10 Project Roadmap"

From OWASP
Jump to: navigation, search
 
Line 21: Line 21:
 
     upcoming Owasp AppSec Eu 2009
 
     upcoming Owasp AppSec Eu 2009
  
 +
= The Deliverable =
  
This project deliverable will be a document with an outline very close to the "Owasp Top 10" one. The document will contain for each category:
+
This project deliverable will be a document with an outline very close to the "Owasp Top 10" one.  
* a description about the category itself,
+
For each flaw category a document chapter will be dedicated.
* a non exhaustive list of security checks that can be assigned to this category,
+
Each chapter will be organized this way:
(for each security check, some example in 2 or 3 web orientend programming language will be provided to show),
+
* Vulnerability description. Each flaw category will be in depth described in order to explain why it is a security issue for a software not to be compliant with it.
* broken code,
+
* Check list. Given a vulnerability,  a non exhaustive list of security checks that can be assigned to this category it will be issued. To each check, it will be provided using 2 or 3 web oriented programming language some example about:
* how to fix them,
+
** broken code
* the related Top 10 category than can be applied when the source code will be executed,
+
** correct code
* some link to existing material.
+
* Static to Dynamic bridge. When appliable, each category will be linked to the related Owasp Top 10 category
* e.g. (to match A1-A10 style, maybe using C1-C10 with the leading C stands for Code)-
+
* Links. Some link to existing material.
  
* C1 - Missing input validation; some words about why this is a security issue in a source code.
+
= Category naming convention =
 
+
While, the Original Owasp Top 10 use the prefix "A" to introduce each category id-code (A1, ..., A10), the Source code flaws Top 10 will use the "C" letter, as "Code".
* Check list<br>
+
So the categories will be introduced by these id codes: C1, C2, ..., C10
* C1-0x1: Don't build queries using concatenation and java.sql.Statement; example of bad code using Statement and example of good code using PraparedStatement and filtering parameter using whitelist,
+
* C1-0xn: n-th security check; example of bad code and example of good code,
+
* Correspondent Top 10 categories (if applicable),
+
** Cross Site Scripting,
+
** Injection Flows,
+
** Malicious file execution,
+
** CSRF.
+
 
+
* Link: some link about filtering input
+
 
+
* My very draft of Top 10 is:
+
** Missing input validation,
+
** Information leakage and improper error handling (match perfectly TOP10),
+
** Insecure communications (All the checks about how transport layer is used, ssl handling in communication, certificates, insecure usage of pipes, sockets, and so on…),
+
** Architectural weakness (All the bad things can happen to software architecture. If you don't perform a good threat modeling than your architecture can be subverted.All issues about communication with auxiliary systems must be in this category (insecure connection pool usage, poor SMTP usage, insecure SQL... not sql injection)),
+
** Direct object reference,
+
** Design weakness (Software design issues… scope… number of methods…),
+
** Documentation weakness (If your code is poor documented, poor annotated..),
+
** Usage of potentially unsafe APIs (Usage of deprecated or potentially dangerous API (gets(), java.sql.Statement, …)),
+
** Misuse of local resources (Infinite loop, resources allocated but never freed, garbage collector issues, …),
+
** Best practices violation (Naming convention and all stuff that doesn't match other categories but are know in literature),
+
 
+
* Related Top 10 categories:
+
** Insecure cryptographic storage,
+
** Broken auth and session management,
+
** Failure to restrict url,
+
** access,
+
 
+
My goal is to put this Top 10 summary in the Code Review Guide with a snippet of all information contained and use this taxonomy to gather security checks for Owasp Orizon. With this I finally linked together static analysis tool and the related guide.
+

Latest revision as of 05:36, 15 December 2008

The Roadmap

The goal is to reach beta quality for next European AppSec 2009, in Cracow. In order to reach this, the roadmap will be the following:

 Project roadmap v1.0_20081215
 * 16 Dec 2008, the project officialy starts
 * 16-20 Dec 2008, "Spread the voice". Each major in topic mailing list will be reached with a press announcement mail in order to find contributors
 * 21-31 Dec 2008, "The quite before the storm". During these 10 days, people in the mailing list will start discussing, sharing the first 
    ideas over the first Top 10 draft
 * 1 Jan 2009 - 31 March 2009, "Let's work". The Top 10 draft will be discussed, modified, reorganized. People from all over the world will hack 
    over it. They will destroy my first ideas, rebuilding from scratch, making examples, destroying again and rebuilding yet another time.
 * 1 April 2009, "Let's cheat". April fool, we will announce our first major release with a nonsense Top 10 :-)
 * 2 April 2009 - 15 April 2009, "Let's freeze it". Top 10 Beta will be freezed. No major updates will be possible, just minor issues or some example
    corrections.
 * 16 April 2009 - 30 April 2009, "Let's correct thesp0nge's poor english". Over the final document wiki pages, we will correct english grammar to make
    the document readable for a mother tongue person.
 * 1 May 2009 - 5 May 2009, "Let's build the doc". The final Wiki will be translated in a Microsoft Word Owasp Templated based document.
 * 6, 7 May 2009, "Let's make available for printing". The final Microsoft Word document will be sent to lulu.com for printing it.
 * 10 May 2009, "Let's announce it". Each major in topic mailing list will be reached with a press release announcement for the final document
 * 13 May 2009, "Let's release it". The first beta version of the Owasp source flaws Top 10 document will be released in Cracow, Poland during 
    upcoming Owasp AppSec Eu 2009

The Deliverable

This project deliverable will be a document with an outline very close to the "Owasp Top 10" one. For each flaw category a document chapter will be dedicated. Each chapter will be organized this way:

  • Vulnerability description. Each flaw category will be in depth described in order to explain why it is a security issue for a software not to be compliant with it.
  • Check list. Given a vulnerability, a non exhaustive list of security checks that can be assigned to this category it will be issued. To each check, it will be provided using 2 or 3 web oriented programming language some example about:
    • broken code
    • correct code
  • Static to Dynamic bridge. When appliable, each category will be linked to the related Owasp Top 10 category
  • Links. Some link to existing material.

Category naming convention

While, the Original Owasp Top 10 use the prefix "A" to introduce each category id-code (A1, ..., A10), the Source code flaws Top 10 will use the "C" letter, as "Code". So the categories will be introduced by these id codes: C1, C2, ..., C10

This category currently contains no pages or media.