[Owasp-leaders] OWASP Secure Coding Track: Actions from 01//24/11 at 8:30EST
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?
> 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:
>> 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. :)
>>> 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
>>> * 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
>>> * How can Codecs register themselves with the framework to enhance
>>> * 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
>>> 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:
>>>> 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."
>>>> * Move from GITHUB --> Google Code (SVN) - Completed; jOHN has
>>>> already exhausted his tears on the matter.
>>>> * 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.
>>>> * 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
>>>> * 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,
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>> 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
> 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