[Owasp-leaders] Feedback on Potential New OWASP Project
Sethi, Rohit
rohit at securitycompass.com
Mon Jan 18 23:22:29 EST 2010
James, thanks for the continued comments. We can certainly include #1 in the next draft.
Multi-tenancy is a hot topic today. With respect to application frameworks, I believe the most fundamental security concerns boils down to horizontal privilege escalation. In light of some of the suggestion from Paco Hope on SC-L, we're thinking of narrowing rather the scope of what we're making recommendations on for this round. I'd like to include some built-in mechanism for horizontal access control but would rather see it in practice first before recommending it broadly.
Point 3 is very interesting. Deep linking is sometimes a genuine application need. That said, some web application frameworks provide page flow capabilities; one model would be to add optional page flow enforcement by tracking the user's navigation history on the server and allowing or denying access to a given page based on the page the user is currently on. For example, a user is only allowed to access Page 3 after coming from page 2; direct access after page 1 or any other page would result in authorization failure. As I type this I'm pretty sure I've seen it before but can't remember where off-hand. Does anyone know of a framework that does this automatically?
As for the entitlements piece, it looks like another aspect of authorization. Should user jmcgovern have access to policy XYZ742 and not ABC153? That depends - should users of the role 'OWASP' have access to that policy? Should only user jmcgovern have access to that policy? Should all users who have purchased a certain coverage have access to that policy? I believe that a framework can help developers by providing ubiquitous access to authorization-relevant data, but developers ultimately need to determine authorization criteria on a case by case basis.
4 & 5 sit in that nebulous area between reliability and availability. We can certainly make an argument that these are relevant to security, but I'm worried that they only begin to scratch the surface of a much larger domain. We could probably throw things like inefficient garbage collection in the same grouping. For the first cut, we'll probably stay away from all but the most obvious Denial of Service protections and re-evaluate what goes into the next cut.
We included file upload in the last version, but we need to get more specific about it. Configuring ICAP for virus scanning seems to be a generally reasonable requirement; how often is it actually done by an application server rather than a caching or proxy server?
Cheers,
Rohit Sethi
Director, Professional Services
Security Compass
http://www.securitycompass.com<http://www.securitycompass.com/>
Direct : 888-777-2211 ext. 102
Mobile: 732.546.4473
Twitter: rksethi
From: owasp-leaders-bounces at lists.owasp.org [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of McGovern, James F. (eBusiness)
Sent: Friday, January 15, 2010 9:19 AM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project
Additional feedback:
1. More enterprisey comments: First, I am probably blissfully ignorant of certain open publishing rules, but I firmly believe that all papers should contain the BIOs of the folks who have written them. I tend to like the templates for documents published by Gartner more than the IEEE stuff.
2. Can we apply some analysis to how a framework should handle multitenancy and its security considerations? For example, Liferay Enterprise Portal, eXO and others support multitenancy but have slightly different takes. Which is the better model going forward from a security perspective? Used as examples, focus on model not analysis of product. This however challenges somewhat what the definition/granuality of framework we should target.
3. A developer asked me an interesting question today in which I could only offer sage wisdom. They wanted to understand how a framework should handle deep linking. I decomposed this question into two thoughts of which the first is whether there is control on doing such a thing. You may not want deep linking where you want to control flow and at other times, you want the exact opposite. Control flow is good to prevent against business logic flaws, etc. The second part of the question is how to think about entitlements around data. For example, if you saw the link: http://www.aetna.com/medical/getmyrecord.jsp?policy=XYZ742, the obvious stuff like parameter tampering comes to mind, but how do we associate the given subject with this policy as part of a validation model.
4. Are we fans that web application frameworks may want to provide capability for graceful degradation, quiescing traffic or having a way of making certain portions of an application unavailable based on a schedule or other trigger? On one of our portals, I know we have some functions where we can support 10K concurrent where others if we had 100 users hitting simultaneously, things would break bad. What should a framework do in this regard?
5. How does a framework work in a clustered environment? Should every object be required to implement serializable or things crash?
6. If you hava a framework that builds XML on the fly, does it provide special protections for things like credit card?
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20100118/f25b63d5/attachment.html
More information about the OWASP-Leaders
mailing list