[Owasp-board] ESAPI libraries-preliminary tests results

Kevin W. Wall kevin.w.wall at gmail.com
Wed Jun 18 04:32:07 UTC 2014

On Tue, Jun 17, 2014 at 6:09 PM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
> I still think that the ESTAPI (or even just STAPI) would be a great way to
> add value here: http://blog.diniscruz.com/2011/06/estapi-idea.html
> And I can tell you that as a developer, I could really do with ESTAPI tests
> to ensure (and prove) that my app is secure

I agree that something like what you suggest would be valuable, but
ALL the unit tests are at the API level and done via things like JUnit
or NUnit to
implement the unit test cases, when really (at least IMHO), using
tests using something
like HttpUnit would have been more reusable. I suspect that this didn't happen
because the initial investment in the test harness code can be somewhat large.
Plus in the ESAPI Java world at least, all those singletons make it
more difficult
to do what you suggest without extending the component interfaces.  That is why
I have deliberately (in not-yet-committed code), burned the singleton
to the ground
so that I could add a protected setIV(byte[]) method to JavaEncryptor
and actually
use with different CTORs (e.g., so I could more easily create an
Encryptor for AES,
another for DESede, etc.). This will allow me to start building out
standard test vectors
for the ESAPI crypto, which is one of my longer term goals. In a
nutshell, I would
have test cases in an external file where the format is TBD, but could
be something
simple like this:
    test1.cipherxform = AES/CBC/PKCS5Padding
    test1.key = 0x<hex_encoded_key>
    test1.iv = 0x<hex_encoded_iv>
    test1.plaintext = <plaintext_string>
    test1.ciphertext = <base64_encoded_ciphertext>

    test2.cipherxform = AES/CBC/PKCS5Padding
    test2.key = 0x<hex_encoded_key>
    test2.iv = 0x<hex_encoded_iv>
    test2.plaintext = <plaintext_string>
    test2.ciphertext = <base64_encoded_ciphertext>


The you just have a small unit test to read the file, do the encryption with the
designated cipher transformation, key, IV on the plaintext and compare it to
the ciphertext.

This is pretty much how all cryptosystems do testing. In fact, there are
even standard test vectors defined for things like AES which I definitely
would be using.

Generalizing this approach for some things my be a bit more difficult
than doing so with crypto because it may be slightly more difficult to
build the support infrastructure for the testing, but it sure doesn't seem
like rocket science. Most of the output encoding could easily take an
approach like this and it would make it trivial to add new test cases.

I think this is what you are envisioning. If not, you definitely need to
slap me up the side of the head and lecture me a bit more. :)

Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.

More information about the Owasp-board mailing list