Hi David I'm Michele Orrù, the one who published on you jira the issue you mentioned: https://issues.apache.org/jira/browse/OFBIZ-1959
Basically we are using Ofbiz trunk in our projects, when we need to build ecommerce, crm, facility management and so on: we also developed a few customization (for example to be able to download a bunch of digital products as a single zipped one (a work that required song track bundles), some customization and issue solving of JMS related funzionalities, and security). I'm a penetration tester, more for passion than for work: I already helped other companies such as Konakart to secure their products ( take a look at my blog: http://antisnatchor.com/2008/12/22/konakart-2260-responsible-disclosure/ ). Security (intended as Web Application Security, not Role Based one) in Ofbiz is not so "high" as you mentioned in your complete post, and as I mentioned in my jira ticket. Now, the right thing to do as I said, and as you accepted (I'm glad for this), is to integrate the filtering functionality of ESAPI inside Ofbiz. It will not be so easy, because Ofbiz structure is so huge and vast, but the points you cited in your post regarding XSS and XSRF protection are OK, from a security point of view. I was thinking to proceed in two ways, when I will have a bit of time: first implement a servlet filter that we can declare in web.xml that validates input BEFORE an eventually malicious request can reach the application surface. In this way a user can choose if implement the filter in every ofbiz application, or just leave ofbiz without it. Second idea, research where to put the validation code of ESAPI and integrate it in Ofbiz. Maybe UtilHttp can extend ESAPI DefaultEncoder to protect from XSS: I need time to look at this solutions, and from a few days I'm researching it. Maybe we can exchange some ideas to finally secure Ofbiz from web security threats. Output encoding is useful but can be implemented in a second moment, because if we filter in a good way the input, output should not be malicious. XSRF protection trough random token it will be maybe the most difficult part, and I think your proposal of store a number n of last tokens is not a good solution, because it only minimize XSRF (without actually eliminating it) restricting the attack window time. Last thing: you're right when you speak about "I've avoided most of these types of things because they always tend to cause a dozen problems for every problem they solve." or "having a bunch of false positives for security errors because of some funny scenario that was not anticipated (and this isn't an if thing, it's a when and how often thing). ".....your points are correct, but the main point is that we (as Ofbiz users/developers) cannot leave Ofbiz in such an "insecure" state. Ofbiz is really an application that can change the market, and improving his security to maximum levels is definitely needed, and maybe an urgent TO-DO. As I wrote here (I'm nickname: euronymous): http://sla.ckers.org/forum/read.php?3,25331,25334#msg-25334 there are a lot of production websites created with Ofbiz that are vulnerable to every attack I described in the jira issue: if we don't integrate security functions, almost no one is gonna put something like an application firewall in front of it in production. Said this...I'm gonna research a bit about ESAPI integration. Looking forward for your thoughts Have a good weekend. Michele -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p21628377.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
