To help to clarify why I asked those questions (and my chain of thought) here are two extra entries with my personal opinion. The first one is a post that that I started writing a couple days ago, and the 2nd one, is a response I just posted on the SC-L and esapi-user mailing lists:
1st one (note that some of the questions asked here are already answered in some of the comments to the original post)
My position is that ESAPI is a great example of what an enterprise security API should look like. But we have to be very careful when we say 'use ESAPI', because we risk that people actually use ESAPI on their applications (i.e. download the jar and copy it into their application, and use it)
I think we need to be careful to do this recommendation for several reasons. The first one is that when we say 'use EASPI', we are basically positioning ESAPI in competition with all the other frameworks (including J2EE in this case, for the Java side of things).
The second one is we have to provide much more visibility to the bits of ESAPI that are ready to be used in production. My understanding is that there are a lot of modules in ESAPI and not all of them have the same level or quality or readiness.
Some of our target audience is going to be developers without a lot of experience in application security, but who want to implement their security controls/features right, So we have to be very, very clear, whether we are providing them with the right advice on ESAPI, namely on which modules are actually enterprise-ready. (for ex: Is it just the encoding module or the logging module? Or is the authentication module also ready for enterprise or application use?)
For me, part of the solution is to explicitly break ESAPI into three parts.
The first one is the interfaces. Basically, the security controls that an ESAPI API or ESAPI compliant framework should have.
The second one should be a reference implementation(s), which is what we have today (and is the one that should be commercially supported by third parties).
The third one, are unit tests for the interfaces. This is a bit where I'm actually quite interested, and I call these the ESTAPI, which is the Enterprise Security Testing API.
I think that is a really valuable asset that we need to implement asap (staring by extracting what is already inside the ESAPI implementations). With ESTAPI , we will have a particular set of tests for a particular 'security sensitive behaviour', for example: "...If you are doing encoding for HTML, this is what you should do. If you are doing encoding for Javascript, this is what you should do. If you are doing encoding for HTML attributes, this is what you do. If you are doing encoding for exec inside a Javascript block...., if your are doing authentication...., if you are doing authorization, ... if you are implementing a password reset... ,..etc., etc. ..."
With the ESTAPI, I'll be able to run these tests against all supported frameworks, whereby for each framework, all I need are little connecters between the ESAPI interface and the particular framework functionality/behaviour. Then we will be able to test the frameworks for their security capabilities. I think this will actually provide a much more pragmatic and much more objective analysis of the framework, allow the mapping of the supported security controls & behaviour, and allow the framework's clients to have much more visibility into what's happening on those frameworks.
Again, I don't want to put ESAPI down. I think ESAPI is a great project. I think it's one of the most successful and powerful projects for OWASP and we just need to clarify it a little bit. In fact, I think the more successful ESAPI is, the more this becomes a problem. I don't think ESAPI has blown up yet because ESAPI hasn't reached a wide level of adoption by software developers or commercial applications.
Remember that one day we will have to deal with the problems of applications built on top of ESAPI that have security vulnerabilities or that are being successfully compromised by malicious hackers.
2nd one (posted on on mailing lists)
My view is that the key to make this work is to create the ESTAPI, which is the Enterprise Security Testing API
This way we would have (for every language):
- ESAPI Interfaces - which describe the functionality that each security control should have
- ESTAPI - Unit Tests that check the behaviour of the security controls
- ESAPI Reference Implementation(s) - Which are (wherever possible) 'production ready' versions of those security controls (and in most cases a one-to-one mapping to the ESAPI Interfaces)
- Framework XYZ ESAPI 'connectors' - Which wrap (or expose) the security controls defined in the ESAPI Interfaces in Framework XYZ
What I really like about this world, is that we (Application Security Consultants) we start to create standards for how Security Controls should behave. and (as important) are able to work with the Framework developers without they felling that ESAPI is a 'competitor' to they Framework. After all, the way we will really change the market is when the Frameworks used by the majority of developers adopt ESAPI (or its principles)
Of course that the Framework developers are more than welcomed to grab large parts (or even all) of the code provided by the ESAPI reference implementation(s). But the key is that they (the framework developers) must: a) take ownership of the code and b) respect the ESAPI Interfaces.
And hey, if the Framework developers decide NOT to implement a particular security control, that is fine too.
BUT!
I would at least expect them to provide detailed information why they made that decision and why they chose NOT to implement or support it (which would allow us (Security community) to respectably agree or disagree with their choices (hey for some Frameworks, being insecure is a feature :) )
Finally, In addition to all the advantages that we will have when frameworks adopt these security controls, there is one that for me is probably the MOST important one: An 'ESAPI compliant app' (which btw is a term we still have to agree what exactly means),is an app that is providing explicit information about where they (the developers) think their (the app) security controls are located.
In another works, via the ESAPI Interfaces (and the ESTAPI tests) the developers are actually telling us (the security consultants):
a) what they think their application's attack surface is and
b) what is the security behaviour that they have already tested for
Of course that they can game the system, which is why we (Security Consultants) will still be needed (we will also need to make sure that they implemented the security controls properly). But compare that to today's (2009) world, were we are lucky to get an up-to-date application diagram and a reasonable accurate
This would also (finally) give the application security tools (white, black, glass, gray, pink, blue) a fighting change to automatically, or operator-driven, understand what is going on and report back:
- what it knows (security vulnerabilities) and (as important)
- what it doesn't know / understand
(ok there is a lot more that these tools will provide us (for example ESTAPI tests) but that is a topic for another post)
(ok there is a lot more that these tools will provide us (for example ESTAPI tests) but that is a topic for another post)
So, for me, the key added value of the ESAPI Interfaces, is that it will provide us (Security Consultants) a way to understand how the app works (from a security point of view) and to be able to finally be able to give the clients what they want: Visibility, Assurance and the ability to make 'knowledgeable Risk-based decisions'.
