> 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 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. _______________________________________________
