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

Jim Manico jim.manico at owasp.org
Tue Jan 25 11:56:24 EST 2011


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


...that drops in easily to solve injection problems.

Same with validation. For starters, drop cannonicalization and just do
straight-up validation. Now we have ...


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

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

More information about the OWASP-Leaders mailing list