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

Jim Manico jim.manico at owasp.org
Tue Jan 25 10:03:22 EST 2011


I agree, Chris...

But right now, if I want to use the encoder - I need to include 80+
dependency jars, a WAF, a flat file authenticator (with poor password
hashing), a bunch of beta filters, etc, etc, etc.

Instead of enhancing the encoder by making the codecs pluggable, perhaps
split out the big pieces first?

- Jim

> 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
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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