[Esapi-user] Over-riding parts of the reference implementation

Jim Manico jim.manico at owasp.org
Tue Feb 2 04:18:45 EST 2010


Yi Li,

Currently you cannot over-ride the validation messages within either 
branch of ESAPI. We have a plan to fix this for ESAPI 2.1 (David Sklarew 
sent us a very solid proposal on this needed feature).

http://code.google.com/p/owasp-esapi-java/issues/detail?id=57

But for today in the 2.0 branch, you can take the current 
DefaultValidator, make a copy specific to your business, and change the 
error messages. Once you have done that, you can tell ESAPI to use your 
copy  of the validator by changing the ESAPI.properties file. Just change :

ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator
to
ESAPI.Validator=path.to.YOUR.validator!

Now, if you want to over-ride ESAPI's configuration in the 2.0 branch, 
you need to take a different approach due to the timing of when when the 
configuration abstraction is needed.

This is done via a System property setting.

private static final String securityConfigurationImplName = 
		System.getProperty("org.owasp.esapi.SecurityConfiguration", "org.owasp.esapi.reference.DefaultSecurityConfiguration");

Which is then called here:

	/**
	 * @return the current ESAPI SecurityConfiguration being used to manage the security configuration for 
	 * ESAPI for this application. 
	 */
	public static SecurityConfiguration securityConfiguration() {
		synchronized (accessorLock) {
			if (ESAPI.securityConfiguration == null) {
				ESAPI.securityConfiguration = (new ObjFactory<SecurityConfiguration>()).make(securityConfigurationImplName, "SecurityConfiguration");
			}
		}
		return ESAPI.securityConfiguration;
	}


> Jim, thanks.
> will appreciate if you could point me on how to write my own 
> securityConfiguration with the hook.
> I would go with the solution to store the properties in a db.
> As a thought, databases today support authentication with OS 
> credentials (such as sql server). then this could be a solution for 
> the key management: run ESAPI in the context of an OS account, which 
> can authenticate into the db.  then the OS will do the dirty work of 
> maintaining the OS account credentials.
>
>
> On Mon, Feb 1, 2010 at 3:50 PM, Jim Manico <jim.manico at owasp.org 
> <mailto:jim.manico at owasp.org>> wrote:
>
>     Yi,
>
>     I think moving the ESAPI properties into a db or (preferably) a
>     keystorage mechanism is a great idea - and a /necessary /idea.
>     ESAPI will eventually move in this direction. I'm reviewing
>     Keyczar and looking at how we can integrate this into ESAPI as one
>     possible implementation.
>
>     What you can do today is write your own SecurityConfiguration
>     layer. We recently added hooks (in the 2.0 trunk) to let you
>     over-ride our security configuration implementation and use your own.
>
>     If this path interests you, let us know and we can point you in
>     that direction.
>
>     -- 
>     Jim Manico
>     OWASP Podcast Host/Producer
>     OWASP ESAPI Project Manager
>     http://www.manico.net
>
>
>>     thanks for all these great thoughts.
>>       I definitely agree that key management is something ESAPI not
>>     supposed to resolve.
>>       for critical application, I believe prompting a human to enter
>>     the secret (passphase or password to database) is a doable
>>     solution for key management.
>>       will appreciate if anyone could let me know whether there is
>>     any existing implementation that can help ESAPI to load the
>>     master secret from either db or java keystore.
>>
>>      
>>      
>>      
>>
>>     On Sun, Jan 31, 2010 at 9:05 PM, Jeff Williams
>>     <jeff.williams at aspectsecurity.com
>>     <mailto:jeff.williams at aspectsecurity.com>> wrote:
>>
>>         Hi Yi,
>>
>>          
>>
>>         >  it seems to introduce another weakness.
>>
>>         The weakness is there no matter what you do – and has nothing
>>         to do with ESAPI.  The application has to have a ‘master’
>>         secret that it can access without relying on some other
>>         secret.  You could have a human put this key into a running
>>         application, but then it won’t be able to restart itself
>>         without human intervention.
>>
>>          
>>
>>         The ESAPI approach is to acknowledge this problem and not
>>         play obfuscation games that are likely to end up introducing
>>         mistakes that reduce security. Protect the ESAPI
>>         configuration file with operating system controls.
>>
>>          
>>
>>         --Jeff
>>
>>          
>>
>>         *From:* esapi-user-bounces at lists.owasp.org
>>         <mailto:esapi-user-bounces at lists.owasp.org>
>>         [mailto:esapi-user-bounces at lists.owasp.org
>>         <mailto:esapi-user-bounces at lists.owasp.org>] *On Behalf Of *Yi Li
>>         *Sent:* Saturday, January 30, 2010 8:58 PM
>>         *To:* Kevin W. Wall
>>         *Cc:* esapi-user at lists.owasp.org
>>         <mailto:esapi-user at lists.owasp.org>
>>         *Subject:* Re: [Esapi-user] store encyrptor.masterkey encrypted
>>
>>          
>>
>>         Kevin, chris:
>>           thanks for the great reply. I am using ESAPI 2.0.
>>           If I fetch the master key from a database, then the
>>         application would need to be able to connect to a database,
>>         which would require a login password.
>>           it seems that I have to store the username/password to the
>>         database in a clear text conf file so that the application
>>         could load and connect to database?
>>           it seems to introduce another weakness.
>>           this is a question on how we could use ESAPI and in the
>>         mean time have a secure key management.
>>           it would be great if you could share your insight.
>>           thanks.
>>
>>         On Fri, Jan 29, 2010 at 4:56 PM, Kevin W. Wall
>>         <kevin.w.wall at gmail.com <mailto:kevin.w.wall at gmail.com>> wrote:
>>
>>         Yi Li wrote:
>>         > greetings, all:
>>         >     will appreciate if anyone could provide insight here.
>>         >     I would like to store the master encryption key
>>         > (encryptor.masterkey) with some sort of protection, instead
>>         of keeping
>>         > it clear text in the properities file even though i can
>>         place access
>>         > control via the file system.
>>         >    i am thinking to either store the encryption key either
>>         in a database
>>         > or in a flat file but encrypted (where to store the
>>         master's master key
>>         > become another problem to solve).
>>         >    will appreciate if anyone could point me to an
>>         implementation that
>>         > will support this or point me the way to write my own
>>         implementation to
>>         > implement this.
>>
>>         Yi,
>>
>>         How you do this depends greatly on whether you are using
>>         ESAPI 1.4 or
>>         2.0.
>>
>>         If you are using 2.0 and concerned about it, your best course
>>         of action
>>         would be to retrieve it from wherever you wish to store it
>>         (e.g., TPM,
>>         HSM, database, etc.) and then use the encrypt / decrypt
>>         methods that
>>         take a secret key, i.e.,
>>
>>                public interface Encryptor {
>>                        ...
>>                        CipherText encrypt(SecretKey key, Plaintext
>>         plaintext)
>>                                throws EncryptionException;
>>                        PlainText decrypt(SecretKey key, CipherText
>>         ciphertext)
>>                                throws EncryptionException;
>>                        ...
>>                }
>>
>>         The way you calculate this SecretKey value, given the
>>         Encryptor.MasterKey
>>         value, is quite simple:
>>
>>            String masterKey = ... retrieve from some secure storage ...;
>>            byte[] skey = ESAPI.encoder().decodeFromBase64( masterKey );
>>            String encryptAlgorithm =
>>                ESAPI.securityConfiguration().getEncryptionAlgorithm();
>>            SecretKeySpec secretKeySpec = new SecretKeySpec(skey,
>>         encryptAlgorithm);
>>
>>         and then use secretKeySpec for the SecretKey parameter on the
>>         above
>>         encrypt / decrypt methods.
>>
>>
>>         OTOH, if you are using ESAPI 1.4.x, then I'm afraid that this
>>         is going
>>         to be much harder. It does not have such encrypt / decrypt
>>         methods so it
>>         can only use the single key. The value of this property is
>>         retrieved and
>>         base64-decoded by the reference encrypt/decrypt Encryptor
>>         implementation
>>         using ESAPI.securityConfiguration().getMasterKey(), so you
>>         would need
>>         to write your SecurityConfiguration implementation and change
>>         getMasterKey()
>>         to retrieve the master key from whatever secure data store
>>         you wish
>>         to keep it in. You would then have to call
>>         ESAPI.setSecurityConfiguration(new MySecurityConfigurationImpl())
>>         before you encrypt/decrypt with this. You could write your own
>>         SecurityConfiguration implementation by either wrapping
>>         (delegation)
>>         or extending DefaultSecurityConfiguration and then change
>>         getMasterKey()
>>         to act differently.
>>
>>         I might be missing some of the details, which I' sure others will
>>         correct, but I think this is the guts of it.
>>
>>         HTH,
>>         -kevin
>>         --
>>         Kevin W. Wall
>>         "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,
>>         co-creator of MIME
>>
>>          
>>
>>
>>     ------------------------------------------------------------------------
>>     _______________________________________________ Esapi-user
>>     mailing list Esapi-user at lists.owasp.org
>>     <mailto:Esapi-user at lists.owasp.org>
>>     https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
>


-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100201/5291b6e3/attachment.html 


More information about the Esapi-user mailing list