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

Jerry Hoff jerry at jerryhoff.net
Tue Jan 25 10:21:53 EST 2011


Hi Chris,

>>The real power of ESAPI is the API itself, not the individual
implementations

I've found the exact opposite with my clients.  While I agree the API is
elegant and in theory would be a great way to achieve uniformity across
languages and teams, most of the time groups I work with just want fixes
to individual issues, and cannot retrofit ESAPI easily into existing
apps.  What would be nice is if all the esapi implementation was broken
down into logical projects (encoders, validators, waf, etc..) where each
project did one thing and did it well.  ESAPI could be the umbrella that
supplies the API and some plumbing to make the various projects play
well together.

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

It's not an easy sell to go to a large financial institution that has
tens of thousands of apps and tell them to adopt ESAPI for its
philosophical beauty! :)  I think modularity is the key - it's what
makes UNIX great and it would make ESAPI great as well.

Of course - this is just my perspective.  But I've had to break out
parts of ESAPI and modularize them for multiple clients in the past - so
from where I'm standing, there is definitely a need out there for more
modular security control set.

Thoughts?

- Jerry Hoff



On 1/25/11 10:58 PM, Chris Schmidt wrote:
> 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
>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders



More information about the OWASP-Leaders mailing list