![securecoding logo](/images/securecoding-logo.png)
Secure Coding mailing list archives
Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog
From: jim.manico at owasp.org (Jim Manico)
Date: Thu, 14 Jan 2010 23:31:32 -1000
Good comments man, I much prefer this level of discourse to what I saw previously.
Thank you, I appreciate that and I do value your input, John.
I think you mistook my ultra-vague and in-specific template pattern reference. I made the same such reference at the 1.4 summit and no one seemed to bite. I'll have to find the time to write an example up... ...but Joel and I have had bigger fish to fry.
Yes, I hold you to a higher standard of clarity when talking about something so crucial as specific design pattern recommendations. I know you are very busy, but if you include even a few minutes of pseudo code with your suggestions it will help us all. Ultra-vague references do not help - nor do they even meet your own self-imposed criteria for excellence which you describe below. ;)
And note that even communists keep track of data. Prior to this google debacle, the Chinese did a very effective round of government reform based on data they'd culled from their populous regarding living standards, literacy, and public opinion.
And they completely misused that data. The Chinese "pulled the switch" on 300 million citizens last year, giving them middle class benefits right as the global economy failed. If you read foreign affairs magazine, I can point you to primary sources.
...but you know I'm just pulling your chain on that. If I thought of OWASP as communists, I wouldn't hold them to the accord I hold my consultants and customers... of which I make the same demands for improvement. -jOHN ...and please rest assured, I hold myself to the highest standard. Currently, I self-assess my current project at 5-7% effectiveness. I'm not just a masochist though: current data, though conservative, bears this out. Whereas, the way my current clients evaluate me, they think I've been effective at providing a 40-70% improvement. I just understand their measurement is naive. I think the principal difference between myself and most of OWASP is this: I think it's OK to have only provided 5% value. Altruism (volunteer army, open-source) doesn't cause me to grade on a curve. I understand that is an insanely unpopular stance to take within the group--and understand I will remain an outsider as a result. That doesn't change my feelings on the matter: 1) OWASP is immensely valuable and 2) OWASP needs immensely to improve.
Very well said. But you are missing the real the real way that OWASP values it's members. Talk is cheap and you get very few points for an idea. It's those that really dig in and try to help the community with actual volunteerism and project help that are most valued in OWASP. Outsiders who throw complaints without real solutions or research or assistance are basically poison pills to the organization. But that said, we need critique here at ESAPI central, and I will continue to look for your counsel and advice. And as a side note, I think many of your concerns are justified. I am petitioning the ESAPI team to relabel different versions of ESAPI as ALPHA/BETA where appropriate, an opinion that is sure to bring me heat from many directions. -- Jim Manico OWASP Podcast Host/Producer OWASP ESAPI Project Manager http://www.manico.net
:-D On Jan 13, 2010, at 3:13 AM, Jim Manico wrote:On 1/11/2010 3:42 PM, John Steven wrote:As a last resort, might I suggest using inheritance andencapsulation 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 adeveloper'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 consistencyrequired 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 pleasedeploy 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
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://krvw.com/pipermail/sc-l/attachments/20100114/697d9503/attachment.htm>
Current thread:
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog, (continued)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Matt Parsons (Jan 05)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog James Manico (Jan 06)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog John Steven (Jan 06)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Jim Manico (Jan 07)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Boberski, Michael [USA] (Jan 07)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog John Steven (Jan 07)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Boberski, Michael [USA] (Jan 07)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Jim Manico (Jan 07)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog John Steven (Jan 11)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Jim Manico (Jan 13)
- Message not available
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Jim Manico (Jan 15)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog James Manico (Jan 06)
- Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog Matt Parsons (Jan 05)