On 1/11/2010 3:42 PM, John Steven wrote: > As a last resort, might I suggest using inheritance and encapsulation to stitch together framework-provided cut points and ESAPI code.
This is where ESAPI will evolve. For starters, we need to get our base controls right. :) This is the hallmark of complicated engineering fields like robotics - start small, get it working and add complexity over time. > For instance, one can simulate [the dreaded] 'multiple inheritance' of both Struts and ESAPI base classes by using the template method pattern within a sub-class of (say) the struts-provided class, which, implementing the template method pattern, would call security controls (such as validation or the largely vestigial ESAPI authentication checks) before handing off to end-application developer code that handles other controller functionality/business logic. Interesting. Keep in mind, template pattern implies some kind of shared functionality. I would not call interfaces (ie: Java's substitution for standard multiple-inheritance) dreaded when used appropriately. Interfaces are "clean" and do not carry any baggage (ie: functionality). It's my opinion that the ESAPI interfaces are ESAPI's gold - we are trying to suggest a few (100 or so) methods that you organization needs to have at the app level (in some form or another) in order to build secure apps. Template pattern might be more appropriate for a C+ ESAPI, but not Java, IMO, in this specific case. Each language-specific version of ESAPI will mandate different patterns. But once we start the ESAPI-Struts and the ESAPI-Spring project, which will happen, template will resurface. Taking a step back - let's take the common notion that we live in a "framework world" and dismiss it. The reality is, many large organizations depend on completely heterogeneous software architectures. I've seen one large org use multiple versions of struts, swing and wicket, in addition to several custom architectures, in addition to old school servlets, using several different servlet containers including one in which they built their own servlet container from scratch and continue to maintain it. This is where an ESAPI is ideal - a common set of centrally maintained controls to pull from. > Personally, for me, the strategy of tacking ESAPI calls onto a developer's application code manually on a case-by-case basis without techniques described above is bound for failure. I think "bound for failure" is an almost dangerous exaggeration. Difficult (at first) and even error prone? Possibly. Deep framework integration of all of these controls will take time. I originally wanted to make ESAPI a struts project - and just go mad in submitting patches to struts. After ESAPI reaches a measure of stability, I may do just that (ESAPI-Struts!). Also, (your) ESAPI should be part of a well balanced software engineering life-cycle. You need to trust developers to some degree to do the right thing. Trust but verify. This is where code guidelines, code review (and I do not mean security code review, just plain ol review of developers code to ensure they are writing to corporate standards) and other non-security code quality and functionality review techniques come into play. > Developers simply won't be able to reach the total consistency required for robust defense in a large existing application. Well, that speaks of a larger problem - if your coders are all "coders gone wild"- then you are in trouble even before the auditors arrive. Consistency of your codebase is your organizations, architects and other software leaders job. > If you're going to walk this road though for the love of God please deploy SAST to make sure that something is sweeping through and looking for that ever-elusive consistency of application I describe. SAST is a decent value, in some cases, when approaching very insecure code-bases. Turnkey SAST is a waste of money on a mature code base - without custom rules specific to your conventions and controls. And for a very large company? I think *not *moving in the direction of some kind of SAST technology - whether its off the shelf or custom built - is crazy in this day in age. You need some measure of automated code review, but doing it cost effectively can be illusive. Findbugs is a great place to start in the Java world. A few RegEx's specific to YOUR controls and styles go a long way. And if you can afford it, going whole hog on one of the major commercial SAST players with custom rules is not a terrible idea, if you have the AppSec FTE's or consultants available to run and interpret the results. The open source world is behind but will catch up. I know I'm mixing ideas here, but you get the gist. And these are loaded ideas, I'm curious to hear your response. > I'd be very-much interested in data regarding faster and cheaper. With the exception of the input validation, canonicalization, and related functionality (*5) it seems like a lot of analysis and integration jobs remain when adopting ESAPI. It took me about 8 hours to port the flat-file authenticator to a high-performance hibernate solution. Perhaps another 16 hours of code tweaking. I'm not a fan of the ESAPI authenticator as it stands today and I would like to see it evolve. But porting the reference implementation forced me to do it "right" and it did not take long at all. Calling it vestigial is certainly and exaggeration, IMO. > I'd also like to know about bug rates relative to non-ESAPI code. I've been on the ESAPI mailing list for a while and can't discern from conversation much information regarding successful operationalization, though I hear rumblings of people working on this very problem. It difficult to do this without violating non disclosures with clients. But I agree, we need these stats! And I need to be careful here. The world is a very meaningless place if you over-analyze it. I'm in the trenches trying to support the developers who are donating their time to build open source security libraries in order to make the world a better place in some small way. My personal goal is to make the entire application security industry disappear and/or shrink so AppSec is just a standard set on line items on each software projects SOW. Communists? Maybe. But we are making a difference. These are all my opinions and do not necessarily represent the "official" position of OWASP, if such a thing even exists (yet). -- Jim Manico OWASP Podcast Host/Producer http://www.manico.net
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________