[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:58:05 EST 2011

On the contrary Jim - Modularization is not about *removing functionality*
or *limiting new features* at all. It is about building the API in a way
that users can pick and choose what functionality they actually need.

Think about the jQuery UI Downloader widget. Jquery-UI is a huge project,
especially when compounded with all of it's themes and styles. When you
download jQuery-UI you pick and choose the components that you intend on
using and pick the style that you want to use.

This is how I envision ESAPI functioning. The real power of ESAPI is the API
itself, not the individual implementations, so I think having standalone
controls as you call out below, while something that should be doable
completely breaks the entire philosophy of the API itself.

The idea is that this is a component of ESAPI that can be dropped in where
it is needed. However, if you don't have any need for the Hibernate encoder,
well - why would you even want the code in your codebase right?

This is my $0.02

On 1/25/11 7:46 AM, "Jim Manico" <jim.manico at owasp.org> wrote:

> Chris,
> 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. :)
> Fair?
>> 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

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