[Esapi-user] [OWASP-ESAPI] ESAPI 2.0r6 web application failure

Kevin W. Wall kevin.w.wall at gmail.com
Fri Apr 23 00:59:10 EDT 2010

[NOTE: Moved from owasp-esapi list to ESAPI-Users list.]

Jim Manico wrote:
> Mr Wall - any thoughts here?
> - Jim

Well, I'll take a crack at it.

>> I am using ESAPI 2.0r6 with Tomcat 6.0.20, JDK 1.6.0_20. I have

[Can you tell me what OS and CPU architecture this was on? I don't
think this is relevant, but I never had chance to check the encryption
serialization, which is used with EncryptedProperties, on anything other than
an ,x86 architecture which is to say a little endian CPU. It could be (but
not likely) that what you are seeing is the result of invalid serialization
messed up during the encryption. If you are running on an x86 or any other
CPU running in little endian configuration, then then that's NOT the issue

>>     protected void loadProperties( final Properties props ) throws
>> IOException {
>>       EncryptedProperties loader = new DefaultEncryptedProperties();
>>       loader.load( new FileInputStream( new File( "jdbc.properties") ));
>>       try {
>>           props.setProperty( "database.driver", loader.getProperty(
>> "database.driver" ));
>>           props.setProperty( "database.url", loader.getProperty(
>> "database.url" ));
>>           props.setProperty( "database.username", loader.getProperty(
>> "database.username" ));
>>           props.setProperty( "database.password", loader.getProperty(
>> "database.password" ));
>>       } catch( EncryptionException ee ) {
>>           ee.printStackTrace();
>>       }
>>     }

Given the file name "jdbc.properties", since it doesn't imply an encrypted
properties file, it is a bit hard to determine your intent here.

One possibility is you wish to take a file ("jdbc.properties") of
UNencrypted properties, load it, and then encrypt the properties
"database.driver", "database.url", "database.username",
"database.password" and *add* them to the Properties props

Is that the correct interpretation of your intent?

If so, I think you are out of luck as I'm not sure there is
a way to do this without writing your own class to extend
java.util.properties.  Unfortunately, in hindsight, we did
not allow a way to mix a properties file that contains both
encrypted and plaintext properties, nor did we have DefaultEncryptedProperties
extend Properties (which I believe was on purpose). The latter point
being that you can't substitute a DefaultEncryptedProperties object
for where a Properties object is expected. (There is no is-a relationship

If it is this case (i.e., jdbc.properties file is not an encrypted properties),
then I'm not sure why you got the error that you did, but these two

>>       EncryptedProperties loader = new DefaultEncryptedProperties();
>>       loader.load( new FileInputStream( new File( "jdbc.properties") ));

are definitely expecting to "load" a file that contains ENCRYPTED properties.

On the other hand, if "jdbc.properties" really already is an ENCRYPTED
properties file (if so, consider naming it to indicate that; it might avoid
future confusion), then these two lines to load the jdbc.properties" are
correct, and the loader.getProperty(_propName_) method calls would try to
decrypt the specified _propName_ and return its value.  In that case, I believe
that what you have done here looks to be OK and my guess is that the
file "jdbc.properties" is somehow corrupt. The most likely scenario is that the
base64-encoded encrypted value of some property was split over lines and the
subsequent base64-decoding "broke" as a result. Alternately some other invalid
base64 encoding character made it's way into your file.

In the error message:

>> ERROR [SECURITY FAILURE Anonymous:null at unknown ->  /<Application>/Base64]
>> Bad Base64 input character at 3: 46(decimal)

a "46(decimal)" would indicate a '.' ASCII character.  The "character at 3" is
probably indicates it was the third character of some base-64 encoded string
it was trying to decode.

If that's what was going on, could you email me your encrypted
"jdbc.properties" file and send it to me as an attachment?  Since
I'm not going to try to decrypt it, I won't need your Encryptor.MasterKey
from your ESAPI.properties file. However, it it makes you feel better,
you can send me an alternate jdbc.properties file with bogus encrypted
information (encrypted with a bogus key for that manner) as long as
that new jdbc.properties produces the same problem.

I hope that helps some.
P.S.- If it seems as though you can't decipher my email, I apologize. I
      almost fell asleep 3 or 4 times while writing it. Going off to
      catch some Zzzzzs.
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

More information about the Esapi-user mailing list