[Esapi-dev] [Esapi-user] Fwd: ESAPI development process

[Chris Schmidt]

  Also worth mentioning - and Jim I know you are going to love this, is 
that as part of the componentization process with the locator class, we 
can add some compile time annotations to verify that services that 
aren't configured and/or included are not being called in the codebase 
and throw compile-time exceptions if they are. It really opens up a lot 
of possibilities for enforcing secure code practices as an additional 
feature of the ESAPI.

On 9/12/2010 3:16 PM, Chris Schmidt wrote:
>  The design flaw is not in the locator itself, the primary design flaw 
> is that you can only currently have a single instance of any of the 
> ESAPI interfaces, which is severely limiting. In the process of 
> modularization the idea that I was tossing around was using dependency 
> injection to allow for several 'named' singleton or non-singleton 
> instances of ESAPI services could be referenced from the locator. I 
> think the concept of the locator is an important separation of concern 
> aspect of ESAPI that should not go away. Take the following 2 examples 
> into consideration:
>
> 1.
>
> Class A {
>     public void doSomeStuff() throws AccessControlException {
>        new ESAPISpringAccessController().assertAuthorized( "A", 
> "doSomeStuff" );
>        // ... do some stuff
>    }
> }
>
> Class B {
>    public void doSomeOtherStuff() throws AccessControlException {
>       new ESAPISpringAccessController().assertAuthorized( "B", 
> "doSomeOtherStuff" );
>      // ... do some other stuff
>    }
> }
>
> In this example which is not using the locator - if I one day switch 
> to a fully active directory ldap integration for my application (not 
> unheard of as an app grows to change Auth/ACL providers) I will need 
> to change the code in *both* classes (and any other classes) to use my 
> new ESAPIActiveDirectoryAccessController to do the AC check.
>
> 2.
>
> Class A {
>     public void doSomeStuff() throws AccessControlException {
>        ESAPI.accessController().assertAuthorized( "A", "doSomeStuff" );
>        // ... do some stuff
>    }
> }
>
> Class B {
>    public void doSomeOtherStuff() throws AccessControlException {
>       ESAPI.accessController().assertAuthorized( "B", 
> "doSomeOtherStuff" );
>      // ... do some other stuff
>    }
> }
>
> In the same circumstances described above - I need only change the 
> *default* implementation of the Access Controller to use in my 
> security configuration. The level of impact for the change is 
> *significantly* less.
>
> That being said, what I envision is the following
>
> ESAPI.accessController()
>     Get's an instance the *default* implementation of the access 
> controller
>
> ESAPI.accessController(String name)
>     Get's an instance of the *named* access controller
>
> I believe this idea is paramount to the idea of using the ESAPI and 
> helps to solve several problems -
>     * Having distinct implementation needs where different parts of 
> the app need different implementations of ESAPI services
>     * Modularization - this will aide greatly in dividing the ESAPI 
> into the things that are being used.
>     * Plug-in ability - Having DI in place makes creating a plug-in 
> type interface a fairly simple task. Since in DI the implementation is 
> specified by way of configuration, plugins can either programmatically 
> inject themselves into the configuration or they can be manually 
> configured or distributed with configurations.
>
> This is just my $0.02
>
>
>
> On 9/12/2010 2:45 PM, Jim Manico wrote:
>> (moving this to the DEV list)
>>
>> No disrespect meant to Jeff or anyone else, but I agree that the single
>> global ESAPI locator is a significant design mistake for a number of
>> reasons.
>>
>> My plan is to get 2.0 out the door in as stable and secure way as 
>> soon as
>> possible without any more major architectural changes.
>>
>> ESAPI 3.0 is going to be a very significant re-write to modularize 
>> the code.
>> I'm also certain that the central locater class will go away during this
>> process.
>>
>> Once we get 2.0 at GA, I'll host a design summit (virtual) to begin 
>> planning
>> 3.0. I'd love to have your thoughts on that then.
>>
>> In the meantime, please toss this is the google code tracker under the
>> ESAPI-Java project so we do not lose track of it, cool?
>>
>> - Jim
>>
>> -----Original Message-----
>> From: esapi-user-bounces at lists.owasp.org
>> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Patrick Higgins
>> Sent: Friday, September 10, 2010 10:55 AM
>> To: esapi-user at lists.owasp.org
>> Subject: [Esapi-user] Fwd: ESAPI development process
>>
>> Forwarding to list because I accidentally left it off.
>>
>> ---------- Forwarded message ----------
>> On Fri, Sep 10, 2010 at 8:33 AM, Ed Schaller<schallee at darkmist.net>  
>> wrote:
>>> I'm not sure I'd like the codec configurations being unchangeable for
>>> all code in a container though.  I may want exceptions to be thrown
>>> for invalid characters in some of my code but not in my JSPs. As such I
>>> lean toward the factory route or something else where code that wants a
>>> codec with certain options can get one without affecting thread safety
>>> or codec options for other code.
>> My thought on this would be to just create two configurations. I think
>> having a single global ESAPI locator is a mistake. It's so easy to
>> just declare your own class with static volatile variables to locate
>> the configurations you need. For example,
>> MyESAPI.JSP_ENCODER.encodeForHTML() and
>> MyESAPI.SERVLET_ENCODER.encodeForHTML().
>>
>> If you need more configurations, just create more instances.
>>
>> --Patrick
>> _______________________________________________
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-user
>>
>> _______________________________________________
>> Esapi-dev mailing list
>> Esapi-dev at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-dev
>