Hi Jim, First, I have to point out - which I do in the documentation - that it wasn't possible to solve every WebGoat lesson for real-world implementation (e.g. session management, concurrent file access, a million users :-). That would take somebody 2 to 3 years to do. So some lesson solutions addressed specifically that particular WebGoat vulnerability (which I call 'quick-and-dirty'); some solutions were generic that could be used in other similar situations (e.g. blacklisting for XSS & injection attacks); some were solved by drilling deep because it was a new concept and an interesting area of research; some were quick-and-dirty fixes but supported by excellent solutions from a reviewer; some I ran out of time but offered a solution; and one was not fixable and I explained why.
About the Access Control lessons, 2 were quick-and-dirty fixes, one accompanied by an excellent reviewer comment and a better solution. I believe you are referring a 3rd one, '2 Access Control Flaws -> 2.3 LAB: Role Based Access Control'. Read about it at: https://www.owasp.org/index.php/OWASP_ModSecurity_Securing_WebGoat_Section4_Sublesson_02.3 Basically, I suggest roughly to implement the WebGoat solution - which is to add to the source code a method called 'isAuthorized' - instead in Lua script in ModSecurity (the pieces to do so are implemented in other lessons). Lua can do SQL and can access the file system, so either the access control matrix has to be implemented separately (it can be fronted with a Web app for administrating and can be written in any language) or if possible might be able to hook into an existing access control matrix. I give a suggestion for file formats for this particular lesson's access control matrix. Keep in mind that you have the full flexibility of the Lua programming language at your disposal. So, upon receiving an HTTP request, ModSec checks the role of the user and then determines if that role can access the requested resource. If yes, then it goes through. If no, then it is blocked. Of course, the implementation is not trivial, but if you can't touch the code and the situation requires a solution, then this offers another option. Stephen On Sun, Nov 30, 2008 at 5:08 AM, Jim Manico <[EMAIL PROTECTED]> wrote: > 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. _______________________________________________
