Category:OWASP Source Code Flaws Top 10 Project Roadmap

Revision as of 05:07, 15 December 2008 by Thesp0nge (talk | contribs)

Jump to: navigation, search

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
 * 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 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

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:

  • a description about the category itself,
  • a non exhaustive list of security checks that can be assigned to this category,

(for each security check, some example in 2 or 3 web orientend programming language will be provided to show),

  • broken code,
  • how to fix them,
  • the related Top 10 category than can be applied when the source code will be executed,
  • some link to existing material.
  • e.g. (to match A1-A10 style, maybe using C1-C10 with the leading C stands for Code)-
  • C1 - Missing input validation; some words about why this is a security issue in a source code.
  • Check list
  • 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.

This category currently contains no pages or media.