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

Jim Manico jim.manico at owasp.org
Tue Jan 25 09:46:29 EST 2011


Please correct me if I am wrong, but the codec project below seems like
- LESS modularization, not more. (ie: more features to a current classes).

I think we need to split up ESAPI into different usable modules : like a
stand alone encoder, a stand alone validator, a stand alone crypto
module, etc. ESAPI is pretty bulky, with 80+ dependencies and counting.
I think we need more modules, less dependencies and less new features....

... and the summit is the perfect place to rip ESAPI apart to accomplish
these goals. :)


> 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
>         * 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
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders

More information about the OWASP-Leaders mailing list