Feeds:
Posts
Comments

For info on projects recently set up and other news, please click on this link.

A. NEW PROJECTS

* OWASP Common Numbering Projectled by Dave Wichers, this project is  a new numbering scheme that will be common across OWASP Guides and References is being developed.

* OWASP HTTP Post Tool, led by Tom Brenann, this project is a tool for the purpose of performing web application security assessment around the availability concerns.

* OWASP Forward Exploit Tool Project, led by Marcos Mateos Garcia, this aims to develop a tool to exploit Top 10 2010 – A10 – Unvalidated Forward vulnerability to bypass access control to protected Java application files.

* OWASP Java XML Templates Project, led by Jeff Ichnowski, this is a fast and secure XHTML-compliant template language that runs on a model similar to JSP.

* OWASP ASIDE Project, led by Jing Xie, Bill Chu and John Melton, ASIDE is an abbreviation for Assured Software Integrated Development Environment. It is an Eclipse Plugin which is a software tool primarily designed to help students write more secure code by detecting and identifying potentially vulnerable code and providing informative fixes during the construction of programs in IDEs.

* OWASP Secure Password Project, led by Josh Sokol, this project will have a two pronged approach designed to put more nails in the single-factor method of authentication: an interactive portal where penetration testers are able to enter known information about the target and the results of all data collected into a large database.

* OWASP Secure the Flag Competition Project, led by Mark Bristow, this project aims to create a different type of competition that encourages secure coding rather than hacking skills.

* OWASP Security Baseline Project, led by Marian Ventuneac, this projects aims to benchmark the security of various enterprise security products/services against OWASP Top 10 risks.

* OWASP ESAPI Objective – C Project, led by Deepak Subramanian, this project is the Objective-C (Cocoa) implementation of ESAPI.

* OWASP Academy Portal Project, led by Martin Knobloch, Ricardo Melo and Konstantinos Papapanagiotou, this project envisages the creation of a Portal to offer academic material in usable blocks, lab’s, video’s and forum.

* OWASP Exams Project, led by Jason Taylor, this project will establish the model by which the OWASP community can create and distribute CC-licensed exams for use by educators.

* OWASP Portuguese Language Project, led by Lucas Ferreira and Carlos Serrão, this project aims to coordinate and push foward the iniciatives developed to translate OWASP materials to Portuguese.

* OWASP Browser Security ACID Tests Project, led by Dave Wichers, John Wilander and David Lindsay, this project was started in order to help people get a better understanding of what these issues are while also providing browser vendors a forum to compare strategies, vulnerabilities, and new features.

* OWASP Web Browser Testing System Project, led by Isaac Dawson, this project was built to quickly automate and test various browser and user-agents for security issues. It contains all the necessary services required for testing a browser.

* OWASP Java Project, led by Matthias Rohr, this project’s goal is to enable Java and J2EE developers to build secure applications efficiently.

* OWASP Myth Breakers Project, led by Stefano Di Paola and Dinis Cruz,this project  similar to http://dsc.discovery.com/tv/mythbusters but for appsec, urban legends and assumptions regarding appsec will be tested and there’ll be a set of examples that will prove the correctness/incorrectness of a statement related to the question.

* OWASP LAPSE Project, led by Pablo Martín Pérez and José María Sierra Cámara,  LAPSE is designed to help with the task of auditing Java EE Applications for common types of security vulnerabilities found in Web Applications.

* OWASP Software Security Assurance Process, led by Mateo Martínez, this project envisages to outline mandatory and recommended processes and practices to manage risks associated with applications.

* OWASP Enhancing Security Options Framework (ESOP Framework, led by Amber Marfatia, the purpose of the framework is to provide a security layer to a given web application / web site via web service which can use the functions / modules to protect the site from several specified  vulnerabilities.

* OWASP German Language Project, led by Matthias Rohr, this project will provide a foundation, guideance and common terminology for German translations (as well as other German language specific activities) of OWASP documents and parts of the OWASP web site. Furthermore, it will organize, plan and priorize new language projects such as translations.

* OWASP Mantra – Security Framework, led by Abhi M BalaKrishnan, this project is a security framework which can be very helpful in performing all the five phases of attacks including reconnaissance, scanning and enumeration, gaining access, escalation of privileges,maintaining access, and covering tracks.

* OWASP Java HTML Sanitizer, led by by Mike Samuel and Jim Manico, this this is a fast Java-based HTML Sanitizer which provides XSS protection.

* OWASP Java Encoder Project, led by Jeff Ichnowski, this project is a simple-to-use drop-in encoder class with little baggage.

* OWASP WebScarab NG Project, led by Daniel Brzozowsk, this project is a robust tool that assists the user in penetration test. This is a complete rewrite of the old WebScarab application, with a special focus on making the application more user-friendly.

* OWASP Threat Modelling Project, led by Anurag Agarwal, this project envisages to establish a single and inclusive software-centric OWASP Threat modeling Methodology, addressing vulnerability in client and web application-level services over the Internet.

* OWASP Application Security Assessment Standards Project, led by Matteo Michelini, the Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed and what level of assessment is appropriate based on business requirement.

* OWASP Hackademic Challenges Project, led by Anastasios Stasinopoulos and Konstantinos Papapanagiotou, this is an open source project that can be used to test and improve one’s knowledge of web application security.

* OWASP Hatkit Proxy Project, led by Martin Holst Swende, this is an intercepting http/tcp proxy based on the Owasp Proxy, but with several additions.

* OWASP Hatkit Datafiddler Project, led by Martin Holst Swende, this is a tool for performing advanced analysis of http traffic.

* OWASP ESAPI Swingset Interactive Project, led by Cathal Courtney and Fabio Cerullo, this a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library.

* OWASP ESAPI Swingset Demo Project, led by Craig Younkins, this is a web application which demonstrates the many uses of the Enterprise Security API (ESAPI).

* OWASP Web Application Security Accessibility Project, led by Petr Závodský, this project will focus extensively on the issue of web application security accessibility.

* OWASP Cloud ‐ 10 Project, led by Vinay Bansal, Shankar Babu Chebrolu, Pankaj Telang, Ken Huang, and Ove Hansen, the goal of the project is to maintain a list of top 10 security risks faced with the Cloud Computing and SaaS Models. List will be maintained by input from community, security experts and security incidences at cloud/SaaS providers.

* OWASP Web Testing Environment Project,l ed by Matt Tesauro, this project was thought o receive all contents OWASP Live CD related.

* OWASP iGoat Project, led by Kenneth R. van Wyk, this project aims to be a developer learning environment for iOS app developers. It was inspired by the OWASP WebGoat project in particular the developer edition of WebGoat.

* Opa, led by David Rajchenbach-Teller, usher in a new generation of web development tools and methodologies.

* OWASP Mobile Security Project – Mobile Threat Model, led by Jack Mannino this sub-project is a component of the OWASP Mobile Security Project.

* OWASP Codes of Conduct, led by Colin Watson, this project envisages to create and maintain OWASP Codes of Conduct. In order to achieve our mission, OWASP needs to take advantage of every opportunity to affect software development everywhere. At the OWASP Summit 2011 in Portugal, the idea was created to try to influence educational institutions, government bodies, standards groups, and trade organizations.


B. PROJECTS/UNDER WORK

* OWASP Cross-Site Request Forgery Research Pool

A. RELEASES’ ASSESSMENTS AND NEW LEADERSHIPS

1. OWASP ModSecurity CRS Project, led by Ryan Barnett, has been under intense work development and has produced recently various releases. Its version ModSecurity2.0.6 has been reviewed and assessed and was consequently rated Stable Quality Release.

2. In a record time the OWASP Secure Coding Practices – Quick Reference Guide, led by Keith Turpin, has had its third release assessed and consequently rated as Stable Quality.

3. The OWASP AppSensor Project, led by Michael Coates, has important developments (new tool) and is currently under review targeting a Stable Release rating.

4. The OWASP O2 Platform, led by Dinis Cruz, has important developments (new release) and is currently under review targeting a Stable Release rating.

5. The OWASP Development Guide has new project leaders. Vishal Garg and Anurag Agarwal are currently assuming the role previously performed by Andrew van der Stock.

6. The OWASP JBroFuzz Project has a new leadership. Yiannis Pavlosoglou has been replaced by Ranulf Green.

7. The OWASP Enterprise Application Security Project has been recently adopted by Alexander Polyakov.

8. The OWASP CTF Project has a new leader. Martin Knobloch has been replaced by Steven van der Baan.

B. NEW PROJECTS

1. OWASP College Chapters Program, led by Jeff Williams. This initiative will help to extend application security into colleges and universities worldwide.

2. OWASP Alchemist Project, co-lead by Bishan Singh, Chandrakanth Narreddy and Naveen Rudrappa. This project enables a software development team in realization of highly secure and defensible application with built-in defences/controls against security‐related design, coding and implementation flaws.

3. OWASP Browser Security Project, created by initiative of Dave Wichers & Michael Coates. This project still has no clear leadership but the main effort has been made by the above referred.

4. OWASP Uniform Reporting Guidelines, led by Vlad Gostomelsky. This project will complement the OWASP Testing Guide as well as the OWASP RFP Template. This is going to be a reporting template for vulnerability findings which will be free, base on industry best practices and hopefully will become the de facto standard.

5. OWASP Zed Attack Proxy Project, led by Psiinon. This project provides an easy to use integrated penetration testing tool for testing web applications and provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

6. OWASP Secure Web Application Framework Manifesto, led Rohit Sethi. This project is a document detailing a specific set of security requirements for developers of web application frameworks to adhere to.

7. OWASP Mobile Security Project, led by Jack Mannino and  Mike Zusman. The OWASP Mobile Security Project will help the community better understand the risks present in mobile applications, and learn to defend against them.

8. OWASP Application Security Skills Assessment, led by Neil Smithline. This project (aka OWASP ASSA) is an online multiple-choice quiz built to help individuals understand their strengths and weaknesses in specific application security skills.

9. OWASP Fiddler Addons for Security Testing Project, led by Chris Weber. This project (aka OWASP FAST) is the umbrella for two complementary projects i.e. the Watcher   Project, a passive vulnerability scanner, and the X5s Project, an active XSS testing and input/output encoding detection.

C. PROJECTS TO BE SOON SET UP

1. OWASP ESAPI Objective C

2. OWASP PASSWD

3. OWASP Eclipse plug-in

4. OWASP Open-sourcing JXT

5. OWASP A10-Unvalidated Forwards

D. PROJECTS TO BE SOON RESET UP

1 All the Cross-Site Request Forgery (CSRF) related contents.

E. OTHER NEWS

1. Three major OWASP Guides – Development, Testing and Code Review – are being pushed by their leaders and contributors to reasonably soon publish a new release. Each of them has been funded with 5,000 dollars.

2. The Google Hacking Project’s Inquiry has been concluded with the publication of the OWASP Global Projects Committee’s Report and the OWASP Board Resolution.

New Drive for Project Reviewers You may or may not have noticed, but as of the assessment criteria v2, each release will require at least three reviews as it moves from beta to stable. This reintroduces problems we have had in the past finding reviewers for these projects. In addition, at least one of these reviewers should be from the GPC. Based on the last GPC call on Monday, November 23, I am going to spear-head a drive for centralizing the collection and recruitment of OWASP Project reviewers. The general idea for this is to create a pool of known-good persons that can be pulled in when a reviewer is not supplied by the project lead. There are several phases I am planning to implement in order to streamline this.

 

  1. Thanks to Paulo, this is already done: Create a sane tracking page where reviewers can register, allowing us to easily find them when needed. You can find a preliminary view of this here:
    http://www.owasp.org/index.php/OWASP_Project_Reviewers_Database
  2. Launch a campaign to recruit as many reviewers as possible:
    a. Parse the wiki for existing reviewers that have been active in the last 24 months, as them if they are willing to participate in future reviews
    b. Create a new “how to get involved” page on the wiki with detailed information on what levels of involvement are available within OWASP, to include “Benefits”. “Time commitment”, and “Role” type metrics
    c. Add information regarding the new review campaign in OWASP media, such as mailing lists, conferences, and the newsletter
  3. Create a mandatory rotation for all members of the GPC, so that each member will be involved in reviews as they come available.
  4. Create a review template guide so that reviewers have an idea of what is expected of them. A great example of a top notch review can be seen by Matt Tesauro on JbroFuzz 1.7 here:

    http://www.owasp.org/index.php/Category:OWASP_JBroFuzz_Project_-_Version_1.7_Release_-_Assessment#Stable_Release_Review_of_the_OWASP_JBroFuzz_Project_-_Release_1.7

    and here:

    https://docs.google.com/Doc?docid=0ATb3QwFMHCXrZGdubjI3ZHNfNWhkejdkY2Rj&hl=en

These are merely early thoughts of how I’d like to see this formulated. Feedback is, as always, welcome.

 

-Brad Causey

Guidelines for OWASP leaders’ attendance of OWASP Conferences and OWASP Memberships

Following the debate started by this thread OWASP Internals: Leaders participation at OWASP conferences I submitted today the proposal below to the OWASP Board which has just been approved :)

I’m really happy with this model and I hope that this will mean that we will see much more participation from our leaders at our conferences,

Guidelines for OWASP leaders’ attendance of OWASP Conferences and OWASP Memberships:

In recognition of the enormous value provided to OWASP by its leaders (projects, chapters, committee & board members) , and the fact that it is beneficial for all that these leaders actively participate on one or more OWASP-organized conferences (16 in 2009), OWASP would like to propose the following ‘operation guidelines’ for facilitating the leaders participation at OWASP conferences:

  • All leaders who currently enjoy an ‘OWASP Honorary individual membership’ (see details below) apply for a ‘FREE’ participation on as many Conferences he/she is able to attend
  • By ‘FREE’ we mean that there is NO (i.e. zero) cost for the OWASP leader, but internally OWASP is marking up this cost between $100 USD and $300 USD (depending on the conference) which cover the ‘participation costs’ of a conference attendee (venue, refreshments, lunch, etc..) .
  • In order to simplify the process and to remove the potential financial burden, this cost will NOT be allocated/paid by the Conference Organizers, but will be covered by (in order of preference):
    • a local chapter that has funds and wants to ‘sponsor’ a particular leader to attend a conference (in most cases this should be in ‘exchange’ of a chapter presentation of a debrief of what happened at the conference). See ‘Notes for chapter with budgets’ below,
    • a direct sponsorship of the leader’s main employer or 3rd party company that wishes to sponsor OWASP leaders,
    • OWASP on the Move funds,
  • In order to maximize OWASP resources and efforts, the following would be expected from the OWASP Leader:
    • Submit a presentation proposal with the conference RFP time period (note that a separate thread (& guidelines) will be required to define the recommended process (for conference organizers) to deal with these OWASP Leaders presentations),
    • Allow the conference to include the leader name in its marketing efforts, i.e.: “…come to the XYZ conference where you will be able to meet personally the following OWASP leaders: {name – project}, {name – project}, {name – project}, {name – project} ..”,
    • Help as much as possible the local organization team (conferences are a LOT of work, and extra pair of hands are always necessary),
    • If there is an OWASP-Stand, help with the ‘manning the stand’,
    • Actively promote the conference in Blogs, Tweets, local chapters and press,
  • To help with the OWASP Leader participation, and if required, OWASP central (i.e. Kate) can send an ‘official invitation letter’ requesting that the leader’s employer allows the conference participation under company’s time (versus holiday time),
    • Depending on the level of sponsorship given to the leader by its employer, the conference organizers should add the leader’s employer as a conference sponsor (note: at the moment there is no standard name for these type of sponsorships).

Notes for chapter with budgets:

The chapters that currently have budget available (see this document for the current list of funds available to local chapters), can and is encouraged (at the discretion of the chapter leader AND its local community) to use its funds to:

  • ‘Pay’ the OWASP internal conference participation cost (100 USD to 300 USD) of the current Chapter Leader(s),
  • Cover part of the current Chapter Leader(s) travel expenses to attend the conference (the current guidelines are 250 USD for local travel (in US or in Europe) and 500 for International Travel (Europe-> US, in Asia, etc),
  • ‘Sponsor’ a particular OWASP Project leader to attend the OWASP conference in exchange for a participation at their chapter (this could be a presentation, a training session, etc…),

Notes on “Who is eligible for OWASP Honorary individual membership’:

Contributions to OWASP are highly valuable, so in order to recognize its effort OWASP is allocating ‘Honorary Individual Memberships’ (i.e. Free memberships) to:

  • OWASP Board Members
  • OWASP Committee Members
  • OWASP Chapter Leaders*
  • OWASP Projects Leaders*
  • Individuals with Special Contributions to OWASP*

* The allocation of ‘Honorary Individual Memberships’ is going to be implemented in two phases:

  • ‘pre AppSec DC conference’ (i.e. now) – For historical reasons OWASP chapter and projects leaders were not made OWASP Members in the past. So in an effort to clean up the past and start with a clean state, the OWASP Projects and Membership Committees is currently creating a list of ALL active and past project and chapter leaders who will be given a Free 1 Year OWASP Individual Membership
  • ‘post AppSec DC conference’ – from Nov 09, and once a year there after, the OWASP Chapter and Project Committees will be expected to first create a criteria to allocate memberships (based on their contributions over the past year) and then use it to produce an annual list of Individuals who should be allocated an Free 1 Year ‘Honorary Individual Membership’. This list should then be submitted for vote and approval

Honorary members will be given the opportunity, although not required to “donate” the annual dues to the Foundation.

Written by Dinis Cruz

There are 3 clarifications to cover, I’ve used headings to make the individual bits easy to find.

Changes to ACv2:

Based on traffic on the OWASP Leaders list coupled with interactions of project leaders with the GPC, I took away a couple of action items which will hopefully make life better for OWASP project leaders when their projects are reviewed under the Assessment Criteria v2 (ACv2):

  1. Alter the ACv2 to make it explicit that both the short slide deck and the flyer/pamphlet are listed as OPTIONAL.
  2. Freeze the requirements of ACv2 for a period of time, say 2 years.

Note that the above will be discussed at the next GPC and if there are any changes, I’ll update this post.  I don’t suspect there will be which is why I’m writing this now.

A bit more info on the two points:

  • If we make any items options, the GPC will review our email templates to make sure the distinction between required and optional is very clear.  To my mind, the purpose of the slide deck and pamphlet/flyer are to ease spreading the word about OWASP projects.  While this is very much in line with the OWASP Mission (“make security visible”), its not fundamental to creating a valuable OWASP project.  For those project leads that want to ‘go the extra mile’, its there but not mandated for all projects.
  • About freezing changes to the ACv2:
    • This benefits project leads as they know that what is asked of them won’t change as they’re working on their project.  I think project leads will appreciate not having  ACv2 change out from under them.
    • ACv2 is new so there is still a chance for a ‘bug’ or two to be found while using it.  The best way to meet the competing needs of project leads (fixed ACv2) and the GPC (ability to fix bugs in ACv2) is to provide a threshold before changes can occur.  My proposed threshold is OWASP Board approval.  Hopefully this will provide the balance necessary for both parties to be happy.

Why ACv2 asks for things at release time:

There was another item raised in the discussion:  Why is the GPC linking some of the ACv2 things that aren’t really release related to assessing a release?

To be perfectly honest and candid, because that’s when the GPC has the attention of the project lead.  There is great diversity in responsiveness amongst the project leads.  Some will respond to emails very quickly, others are a digital black hole.  Since this is all volunteer work, those items were added because I knew that if an project lead wanted their project assessed, that was the time to try and get those tangential items.  For leads that are engaged and active with their projects, I’m sure this seems like a silly hassle.  I wouldn’t disagree with that in specific cases but globally, it seemed like the best way for OWASP to try to raise project quality over all projects.

Purpose of the roadmaps:

Finally, two items that have been tripping up project leads are the roadmaps – both the project level and the release one.  Since I wrote ACv2, let me tell you my purpose for those documents and what my expectations were for them.  (Maybe I have another action item to add this to the OWASP wiki)

(A) Project Roadmaps – this is to provide the high level details of where you’d like to take the project.  Basically, what are your thoughts on the final destination for the project – where should it end up.  You may never get there (and that’s OK) but this helps to:

  1. Let users & reviewers get an idea of what you’re thinking at a high level
  2. If the project is orphaned, any new project lead can keep the project going that much easier.

(B) Release Roadmaps – this is to provide both reviewers and users an idea ‘what they are getting’ in the new release.  It could double as (or be sourced from) the change log.  Particularly for reviewers, this helps them focus their efforts on the new parts of the project.  That should help project leads get eyeballs and feedback on their new code.  Especially for large projects that have made previous releases, this is very useful.  Think about the difference in effort between reviewing the Testing Guide as a whole vs looking at the 2 new chapters and 20 minor additions.

How big to either of these have to be?  As big as the project lead feels they need to be to meet the purpose of them.  Maybe 10 bullets, maybe 10 pages – its really the project leads choice.  Also, project leads are in the best position to know how much effort this should take.

Hope this helps project leads and OWASPers in general understand ACv2 that much better.

Follow

Get every new post delivered to your Inbox.