[Owasp-leaders] OWASP Secure Coding Track: Actions from 01//24/11 at 8:30EST

Chris Schmidt chris.schmidt at owasp.org
Tue Jan 25 09:16:27 EST 2011


All - 

I sincerely apologize for not being on the line last night, I had some work
issues that I was working through that had to take priority.

That being said - I am fully on board with John's take of really getting
something tangible out of these sessions. Output Encoding is one of the most
mature controls in ESAPI, however every time I implement it somewhere it
seems like there is some *one-off* edge case that either isn't covered and
needs to be worked around or there simply isn't the *right* codec.

In the interest of the upcoming modularization push for ESAPI my main focus
for the workshop will be done in 3 parts, the idea being to have 3 working
groups that revolve through these goals like a game of musical chairs. The
result of this session would be a new add-on to ESAPI, called ESAPI-Codecs
that could be dropped in to extend Codec coverage.

Working Group 1: Current Codecs
Deliverable: Updated tests and code for existing codecs
    * Verify Codecs are up-to-date for current contexts
        * Specific focus on MySQL Codec which currently supports 2 modes,
however according to MySQL Documentation there are officially something like
7 modes of operation - all of which have slightly different rules for
formatting.
    * Write test cases for specific codecs in the interest of replacing the
codec specific tests in EncoderTest

Working Group 2: New Codecs
Deliverable: New ESAPI-Codecs sub-project
    * New Codecs
        * Sybase
        * Postgres
        * Gigaspaces Query Language
        * Hibernate Query Language
        * SparQL
        * ECMAScript
    * Attack them and test them

Working Group 3: Codecs Architecture
Deliverable: UML and/or architecture design plan for
modularized/componentized Encoders
    * Architecture review and plan for Encoders
        * Does the current Encoder interface make sense in a modularized
ESAPI?
        * How can Codecs register themselves with the framework to enhance
usability?
    * Ensuring backwards compatibility with existing ESAPI integrations
    * How could we build an 'artifact customiser' widget that would allow a
user to build a custom esapi-codecs.jar with the codecs that they would
need.     

I purposefully left the concrete plan of WG3 slightly open as I don't want
to restrict anywhere that this subsession could lead and really want to get
peoples minds and creativity going on the subject so that we can get the
most out of it. 

Prepatory Actions:
    * Create subversion structure in existing ESAPI project for the
ESAPI-Codecs sub-project
    * Create maven project for esapi-codecs
    * Look for more ideas for new codecs

I will get the wiki updated with this information today.



On 1/25/11 6:19 AM, "John Steven" <John.Steven at owasp.org> wrote:

> All,
> 
> [Sum]
> Last night we honed in on our track sub-section focuses. Two
> sub-sections come to the summit with more content available and a
> clearer picture: IV and AppSensor.
> 
> Jim suggested an "Attack and Defense" style offering where he'd bring
> enough application and attack harness code to have participants in
> roles either building defense against encoding-based attacks or
> proving evasion of those protections built by others. He suggested
> participants switch roles within his session so that they gain both
> perspectives. He suggested building competition kit (bells/whistles
> for when an evasion succeeds, etc.)  to raise interest / sex-appeal.
> 
> Mike has a cut-and-dried task in his mind: we have the AppSensor
> framework and need more example sensors. He'd like to focus his
> session on [that: building those].
> 
> I have, for my part, come up with a few goals in the context of
> 'protecting information client-side' and have documented on the
> sub-track page (PI, App-specific info, etc.). I am concerned about
> dragging participants through those goals in two or three contexts
> (Classic n-tier, phone OS, and RIA). Currently, I'm trying to build
> sub-section design to take these ideas into work-able chunks. My
> principal concern remains [potential audience] familiarity with phone
> OSes and RIA tech stacks.
> 
> Dan reports a similar difficulty in working his persisting data
> section. He and Jim are going to  mine their existing code bases for
> usable snippet material. Dan, particularly, is concerned about
> representing properties of 'real world' data models that that solution
> definition/implementation treats issues developers confront beyond,
> "Flip this config setting and you're good."
> 
> [Decisions]
> * Move from GITHUB --> Google Code (SVN)  - Completed; jOHN has
> already exhausted his tears on the matter.
> 
> https://code.google.com/p/secure-coding-workshop/
> 
> * Focus each sub-section on 'getting something back' from the session
> to share with the community in addition to raising awareness and
> disseminating knowledge
> * Decision to work with snippets rather than demand a full "sample app."
> * Meet 'every other day' until summit in prep. Tentatively, this will
> be on Tuesday, Thursday, and Saturday.
> 
>  [Actions]
> * Each person held themselves to different prep-work activities but we
> agreed that for the next call to come up with the specific goals for:
> 
>   * What we want participants to 'give back' to the sub-section in
> analysis/code/test/docs
>   * What we want participants to 'leave understanding' that they
> didn't when they arrived.
> 
> I'll report status each week to cut down list traffic,
> -jOHN
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

Chris Schmidt
ESAPI Project Manager (http://www.esapi.org)
ESAPI4JS Project Owner (http://bit.ly/9hRTLH)
Blog: http://yet-another-dev.blogspot.com





More information about the OWASP-Leaders mailing list