[Owasp-leaders] Creating OWASP 4.0!

Jim Manico jim.manico at owasp.org
Fri Dec 10 13:50:30 EST 2010

John is right on the money. This is one of the best ideas I have seen for
conference presentations in some time, especially developer centric

I would also like to expand on John's ideas and demonstrate defensive
techniques specific to key frameworks. The devil is in the details, and
those details speak directly to developers.

For example, CSRF is mitigated differently based on the framework. (If you
use Struts, turn on Struts transaction token and call it a day. Spring has a
different integrated mechanism. If you are using a Java framework that does
not have built-in transaction tokens like Wicket, use ESAPI CSRF functions
like so, etc...)

Nice, John.
 - Jim

-----Original Message-----
From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of John Steven
Sent: Thursday, December 09, 2010 10:04 AM
To: owasp-leaders at lists.owasp.org
Cc: Chris Schmidt; Michael Coates; Jack Mannino; Jeremy Long; Benjamin
Subject: Re: [Owasp-leaders] Creating OWASP 4.0!


I agree with Rex. Chaos remains an important (constructively)
disruptive force. It can not provide coherent direction I hear people
craving ATM. The board seems to want the organization to remain
decentralized and with a bottom-up driven direction through project
leaders. This seems 'fine' to me because its fundamental to the OWASP
organization and culture.

Though, outside of the community itself, I perceive this having
resulted in two forces providing OWASP most of its external impact and
momentum beyond general Application Security Awareness recently:
Conferences and ESAPI

I'm concerned that as we look at '11, we don't see these two forces
providing us the progress we desire alone. The last few conferences I
attended suffered from confusion or division in promotion and the
majority of topic areas have already been presented (often in nearly
or exactly their current form). Momentum on conferences, from my view,
will wane unless something changes. ESAPI, by comparison, has momentum
but is less mature. There isn't a "The Solution" but I think we can
create some direction and bolster both of these key aspects of the
OWASP organization simultaneously. I've talked to almost everyone
explicitly listed as a CC regarding my idea. They seemed at least
superficially interested in participating.

Create a "No Fluff just stuff"-like track for Portugal, pull out our
laptops (not for email/IM), and show people how to develop secure
code. Chris referred to this here:
I'd like to prototype this in Portugal and keep it going in Minnesota.
Pravir led something like this with SAMM (but regarding process) in
Portugal the first time around. This was incredibly valuable.

I'd like to propose the following skeleton and get passionate
developers to sign up for it. I'm imagining 1/2 day sessions. (So,
over four days, we could have eight (8) facilitators). I suggest we
pick a single target (Java EE?), a single victim app, and a single
container as a 'base of operations' for the first one to keep things

Track Mission: Building Security In: Using OWASP tools/techniques/code
to build secure applications.
(the list is not in any particular order. In fact, that may be
something to talk about. I've tried to provide four (4) one-hour seeds
for each session, subject again to discussion)

*     Topic                                             *
Facilitator   *    Proctors   *

1 Applying ESAPI input validation        Mr. Schmidt
    * Serial Decomp: Decode, canonicalize, filter
    * Structured data (SSN, CC, etc.)
    * Unstructured data (comments, blogs,  blah)
    * Other input examples (ws-, Database, etc.)

2  Defining AppSensor sensors for:      Mr. Coates
     * Forced Browsing
     * Request Velocity
     * Unexpected encodings
     * Impersonation (Sudden user switch)

3 Managing sessions                          ????????
   * Across requests
   * Across containers
   * Invaliding sessions (Timeout, attack event, logout)
   * Invalidating sessions (across containers, SSO token invalidation,
user termination)

4 Protecting information stored client-side  Mr. Steven
    * Threat Modeling the problem
    * Protecting theft and re-playability of application-specific
info (on client & in flight)
    * Protecting theft and re-playability of session-specific info (in
    * Protecting session-specific information from attack on the client

5 Protecting against CSRF                 ????????
    * Hygiene
       * Discuss/show Frames-busting, cross-domain policy,
       * Discuss referrer and other red herrings
    * Tokens (crafting, scoping, and checking)
    * Discussions, techniques on scale
    * Discussions, techniques on CAPTCHA, re-auth, etc.

6 Providing access to persisted data   ???????
   * Controlling visibility of tables by role (Spring?)
   * Providing access to safe SQL-like query through DAO layer
   * Discussions, techniques for providing secure 'auto-wiring' / marshaling
   * Encoding and canonicalization for storage (or alternatively:
   * Security concerns with hierarchical caching & object pooling)

7 ...I have some other ideas for 7 and 8, but wanted to afford the
skeleton some flexibility.



* Facilitator role replaces "speaker". They lead the session, but the
session is a working session, laptops open, whiteboards filling. This
is not a lecture.
* Other facilitators adopt the present facilitator's goal as their own
and we drive the concept/design/code forward Dissenting views are for
drinks later.
* Sessions are open to all participants provided they have at least
the ability to read the chosen language, and have the following things
installed when they arrive:
   * Our victim app
   * All session dependencies
   * Dev tools sufficient to build and run the app and our dependencies
* Facilitators must agree to attend six (6) out of eight (8) sessions.
Failing that, they're booted from the next venue
* The objective of each session is split between educating
participants and bringing the state of the practice forward.
* Participants may bring whatever code they like, provided they
contribute it to OWASP.
* Facilitators should seek to absorb any new developments into the
next conference session. IE: each session should have some new and
unique content
* Facilitators don't 'own' topics, in fact, I'd like them to rotate
between cons. if possible.

Next Steps:

* Define eight sessions, facilitators. Solicit proctoring help
* Finalize (and verify) dependency list for participants
* Ratchet up specificity in session topics (create, review, and revise
a track outline)
* Establish a twice-monthly call for facilitators to take our skeleton
plan to reality.

I would be happy to help organize this track, direct it, and provide
air-support to the other facilitators in their sessions. Chris, Mike:
want to participate? Mr. Cornell--we discussed this out west. You
game? Others?

This track idea, in no way, replaces the need for continued awareness,
novice training, and other popular OWASP tools/projects (LiveCD,
Top10, ... etc.)  The track is designed to engage passionate and more
advanced participants, as well as entice more developer participation.
Let's build something interactive, tangible and immediately useful for
our conference participants.


On Wed, Dec 8, 2010 at 5:36 PM, Rex Booth <rex.booth at owasp.org> wrote:
> I hate to so contrarian with you today James, but chaos doesn't work on a
> strategic level.  Your positive experience at your chapter doesn't
> to the organization as a whole.
> Whether we are a non-profit or not, we need to recognize that we are in a
> competitive marketplace where we need to struggle for relevancy in order
> achieve our mission.  We can't treat this like some sort of free-for-all.
> We have numerous dedicated individuals, but I think as an organization we
> try to be everything to everyone.  In the pursuit of allowing owasp to be
> anything somebody wants it to be (new conference?  Sure!  New project?
> not?) we've sacrificed our ability to focus and really make an impact
> some notable exceptions).
> I think better coordination of efforts, some culling of the less useful
> projects and undertakings, and more strategic leadership from the board
> level would go a long way.
> Imagine how much we could accomplish if we eliminated the noise and were
> able to double our efforts on the truly impactful and high-profile
> Rex
> On Dec 8, 2010, at 4:02 PM, "James McGovern" <JMcGovern at virtusa.com>
> I too have noticed the chaos and believe it is a good thing! When the
> Hartford chapter did a joint meeting with ISACA, they had a lot more
> formality in organizing things. Generally speaking, when I organize
> chapter meetings I tend to start with finding two speakers who are of
> interest, figuring out what they are going to talk about, creating an
> and then blasting it to the world. The ISACA model required multiple
> of approval and dozens of phone calls.
> We get things done without requiring audits and checklists :-)
> James McGovern
> Insurance SBU
> Virtusa Corporation
> 100 Northfield Drive, Suite 305 | Windsor, CT | 06095
> Phone:  860 688 9900 Ext:  1037 | Facsimile:  860 688 2890
> -----Original Message-----
> From: owasp-leaders-bounces at lists.owasp.org
> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Yiannis
> Pavlosoglou
> Sent: Wednesday, December 08, 2010 12:47 PM
> To: owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Creating OWASP 4.0!
> Examples:
> 2. We have real issues on establishing individual efforts and commits
> to a particular task. Other organisations are also open and
> transparent, why all the chaos with us?
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org

More information about the OWASP-Leaders mailing list