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

Chris Schmidt chris.schmidt at owasp.org
Tue Jan 25 12:17:18 EST 2011


All - 

Sorry for the interruption - this conversation has been taken off-list..

Move along, nothing to see here.. :)


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

> Chris,
> 
> I think some of this modularization is unnecessary.
> 
> Why not just wrap the encoder and codecs together and make it all
> concrete? The swappable API is not necessary. The extra couple of K per
> codec is no big deal. Then we would have one jar...
> 
> ESAPI-encoder.jar
> 
> ...that drops in easily to solve injection problems.
> 
> Same with validation. For starters, drop cannonicalization and just do
> straight-up validation. Now we have ...
> 
> ESAPi-validation.jar
> 
> ...that easily drops in and handles straight forward validation fairly
> well. Perhaps have an *optional* hook where if both the jars are in the
> classpath, cannonicalization takes place in the validation API.
> 
> Then take CSRF. Ala CSRFGuard.jar
> 
> We could do this for other security areas as well.
> 
> And you are right, maven (in my world) only triggers 30 (not 80)
> dependencies. Still a lot, but fair enough. :)
> 
> Please note, I'm going to have a ESAPI-lite working session at the
> Summit where we plan to accomplish the same thing that I'm describing
> above. The response that I got when suggesting ESAPI-lite was enormous.
> 
> Perhaps we just need:
> 
> ESAPI-core (zero dependencies here is a must)
> ESAPI-validator
> ESAPI-encoder
> ESAPI-authenticator
> ESAPI-accesscontroller
> etc.
> 
> Anyhow, we are both taking different routes to the same goal; we should
> definitely meet up and coordinate.
> 
> And Leaders, this belongs on the ESAPI-dev channel. Moving there soon,
> sorry folks.
> 
> - Jim
> 
>> 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
>> 
>> 
>> 
> 

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