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

Chris Schmidt chris.schmidt at owasp.org
Tue Jan 25 11:46:22 EST 2011


Jim - 

That is really the intent here is to start on what will become the
ESAPI-Encoder and/or ESAPI-Codecs component. The bit of making them
pluggable is just a part of a single subsession within the Working Session.

Encoders and Codecs are a very simple place to start because they have no
third party dependencies, and have no need to.

Also - FYI, according to Maven, there are a total of 20 dependencies between
ESAPI and Antisamy XD


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

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

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