Stephen, Very interesting project.
May I ask - how did you solve some of the Access Control labs in webgoat? Some of those access control labs were data-contextual: ie, only certain users had delete access against certain pieces of data. The way students are supposed to solve this data contextual access control lab is to modify the database query in webgoat so the query itself does an access control check to see if the current user can execute delete against this specific object. The only way a WAF could solve that problem would be to either get access to the production database so it could understand the access control rules; or include some of the database data and logic logic inside of your WAF rule. Really curious as to what you did, Jim > Hi, > > I did an OWASP Summer of Code 2008 project, "Securing WebGoat using > ModSecurity" (actually, it expanded into a Fall of Code project too > :-) > > First, the project should have been named "Protecting WebGoat using > ModSecurity" but by the time I figured it out, it was too late to > change the title. > > The goal of the project was to fix as many of the WebGoat > vulnerabilities as possible using ModSecurity without changing any of > the source code, and I ended up either with solutions or suggestions > of solutions - prevention or detection - for 46 of the possible 47 > WebGoat sub-lessons. > > IMO, some interesting parts of it: > - The combination of using Lua script on the WAF (back end) and > Javascript injection (into the response body) on the front end allows > for a complete programming environment (keep in mind that ModSecurity > cannot alter the content of HTTP requests or responses, but can > prepend and append Javascript to the response) > - Using Lua and Javascript injection to mitigate business logic flaws > - Using Javascript injection to mitigate 3rd-party attacker kinds of > attacks, and enhance the end user experience when ModSecurity has to > block a request or response > - The documentation is sorta of a primer for ModSecurity (quite a bit > of interest in this project has been from infosec people who want to > learn more about ModSecurity and WAFs in general) > - Included are insightful, invaluable reviewer comments from the > project reviewers (Ivan Ristic, Ryan Barnett, and Christian Folini) > that you won't find any place else > > I've put the finishing touches on the project wiki (as far as new > content goes) so I thought I would introduce the project here. > > The project main page: > https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project > > The project wiki: > https://www.owasp.org/index.php/OWASP_Securing_WebGoat_using_ModSecurity_Project > > Appendix D contains a Word file - 134 pages - of the wiki (as of Nov > 25); it might be easier to refer to it rather than navigating around > inside the wiki. Plus, I put up a ppt prezo from the recent OWASP EU > Summit in Portugal, and all future fixes and enhancements to the > current ModSecurity solution rulesets will be placed there also. > > I have been getting some private emails of people actually starting to > use the project stuff, so it's time to redirect that to the mailing > list. > > To subscribe: > https://lists.owasp.org/mailman/listinfo/owasp-webgoat-using-modsecurity > Archives: https://lists.owasp.org/pipermail/owasp-webgoat-using-modsecurity/ > > I call WAFs, code review, and penetration testing the 3 pillars of the > application security portion of PCI-DSS, and I believe that adding a > WAF to the toolbox - and being able to write custom rule sets - not > only can benefit the client but also can be a career-enhancer (I've > already used it on one project). > > Of course, the percentage of the project that is theoretical/research > vs. the percentage that is practical and has real-world value is > subject to debate. Anybody wanting to throw some flames are very > welcome - I have some pretty thick skin (which started to thicken as a > casualty of the classic OS/2-Windows flame wars of the early '90's). I > touch on this in the project documentation so I only ask that one > reads it first before flaming away :-) > > Thanks for your attention, > Stephen > > > Cheers, > Stephen > _______________________________________________ > 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. > _______________________________________________ > -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com _______________________________________________ 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. _______________________________________________
