[Esapi-user] Setter Methods in ESAPI Class

Kevin W. Wall kevin.w.wall at gmail.com
Fri Aug 5 22:57:15 EDT 2011


On Fri, Aug 5, 2011 at 9:47 PM, Owen Berger <owen.k.berger at gmail.com> wrote:
> Hello all,
>
> I just have a quick question. I recently migrated from the ESAPI 2.0 rc6 to
> ESAPI 2.0 GA.  In my old code I set the ESAPI Authenticator and a couple of
> other class by calling:
>
> ESAPI.setAuthenticator(MyAuthenticator);
>
> However, ESAPI 2.0 GA won't let me do that now, and I can't find the setter
> methods for the ESAPI class, even though the JavaDocs and the code in the
> Google Repository say "Use the set methods to override the reference
> implementations with instances of any custom ESAPI implementations."  I have
> been searching for awhile and can't figure out how to set my own customized
> esapi wrappers, can anyone point me in the right direction?

IIRC, these methods had thread safety issues and they were removed because
of that.

If you wish to permanently replace the default reference implementation
Authenticator (FileBasedAuthenticator) with your, then you should do
this by resetting the ESAPI.Authenticator property in your ESAPI.properties
file. This would be something like:

    ESAPI.Authenticator=my.full.packagename.MyAuthenticator

> Also, while were at it, I decided to upgrade after I implemented my own
> SecurityConfiguration and was unable to load validation.properties after
> that. I didn't change any of the security configuration code dealing with
> loading properties.  Any ideas, is the DefaultSecurityConfiguration not
> meant to be overriden?

If you override DefaultSecurityConfiguration, I think you have to do
that *after* that class has loaded. And reading through the ESAPI.java
class, I came across this undocumented (no javadoc) public method:

   // TODO: This should probably use the SecurityManager or some value
within the current
    // securityConfiguration to determine if this method is allowed to
be called. This could
    // allow for unit tests internal to ESAPI to modify the
configuration for the purpose of
    // testing stuff, and allow developers to allow this in
development environments but make
    // it so the securityConfiguration implementation *cannot* be
modified in production environments.
    //
    // The purpose of this method is to replace the functionality
provided by the setSecurityConfiguration
    // method that is no longer on this class, and allow the context
configuration of the ESAPI
    // to be modified at Runtime.
    public static String initialize( String impl ) {
        String oldImpl = securityConfigurationImplName;
        securityConfigurationImplName = impl;
        return oldImpl;
    }

So it appears that you use this to change to a different SecurityConfiguration
class. E.g.,

    String currentSecurityConfiguration =
                ESAPI.initialize("my.package.name.MySecurityConfiguration");
    ... use your implementation ...
    ESAPI.initialize(currentSecurityConfiguration); // optional restore
                                 // You could also use
ESAPI.override(null) to accomplish
                                 // the same thing

I can't say I've every tried this though.

BTW, if your implementation of SecurityConfiguration was from back in
2.0 RC6, you had better take another look as I'm quite sure that it's
changed quite a bit since then in terms of new methods being added.

Finally, a lot of this is just an educated guess. Chris Schmidt would be
the goto person to ask has I think he was the one who made these final
changes. At a minimum, we should document this in the ESAPI javadoc
and remove references to the old setter methods.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the Esapi-user mailing list