[Owasp-leaders] Feedback on Potential New OWASP Project

[Sethi, Rohit]

Hey Dinis, you're absolutely right that the "devil is in the details". The manifesto, in its current format, is something akin to Section #1 below. It's a set of platform-independent requirements. They apply equally to:

a) existing frameworks and
b) frameworks that have not yet been developed.

By definition, we can't provide that kind of technology-specific advice to frameworks that full under column b) yet.

As for a), I completely agree that we need to take the general requirements and translate them into something more meaningful to each framework. Each translation would be a separate effort. Before we get there, however, we need to make sure the requirements in their current format are "release quality" which is what we're aiming for first. Once we're done that, the translation effort will be laborious and I would suggest we only spend translating to a particular framework if the developers / leadership of said framework indicate an interest to adopt the manifesto. Do Struts maintainers care to adopt the manifesto? What about Spring MVC? In many cases, fulfilling requirements may boil down to integrating existing ESAPI work into the core framework

We have been toying around with the idea of using Django as a launching pad to adopt the manifesto. In essence, we will be willing to help with not just requirements but implementation if Django is willing to have it; hopefully we can integrate a lot of the work already done for ESAPI Python.

Thanks,

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 dinis cruz
Sent: Tuesday, January 19, 2010 7:34 AM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project

Rohit & Mike,

I was thinking about both of your projects (which make sense to be separate entities for now, since they are tacking the problem from different angles), and when I try to visualize what they would look like in a mature and widely used state (i.e. the moment community adoption reaches critical mass), I can't see how it would work unless you are able to build a modular approach where the final 'Application XYZ' checklist is 90% to 100% customized to the langages, frameworks and architecture of that application.

In another words, for your 'standard' or 'manifest' to be usable, it will need to be quite specific and non-ambiguous, but that will require quite detailed information and guidance (since devil is in the details). The problem you will then have is that (unless you break it apart) the noise-to-information ratio is going to be too big.

Let's take a very simple example, data validation, which (as per this thread) is covered here:

ASVS V5.2 :  "Verify that a positive validation pattern is defined and applied to all input." Is a verification activity

Manifesto 3.1.2: "Provide an API to Validate All Input Data" Is a mechanism...

How to write a document that is able to cover this topic for (to name a few) Frameworks like: Struts 1.5, Struts 2.0, Spring MVC 2.5, Spring MVC 3.0, Wicket, JSF, J2EE with JSPs, Java Portlets,  ASP.NET<http://ASP.NET> with WebForms, ASP.NET<http://ASP.NET> MVC, Sharepoint WebParts, WebSphere Portal, Ruby on Rails,custom framework XYZ or custom modifications to the each one of these?

How to write a document that is able to cover this topic for languages as different as: C++, Java, .NET, Python, Ruby, PHP, Perl, etc... ?

(even inside of of these, there are massive differences. For example, just Spring MVC has multiple ways to handle data-inputs! (so any security guidance on Spring MVC input handling, will have to include/support ALL of these ways, and (also very important), what happens when an app uses some (or all) of those different data input mechanisms)

Since each Framework and Language has it own variation of 'Data Validation functionality with security implications', my view is that unless we have specific guidance (which can be 'consumed when needed')  for the bit of the 'Framework vs Language vs What is being used', our guidance is either going to be to generic or to big.

The key in the previous paragraph is the 'consumed when needed'. We have to make sure that what every guidance we provide can be 'consumed' by the multiple tools that are currently used by the players we want to influence. So for developers we must have guidance that is available on their IDEs, for architects we have to have guidance that can be used in the data modeling / visualization that they use (please don't push this conversation to the 'human vs tools' or 'tools suck' discussion, since I am not making the case that 100% automated tools are the solution).

So, for me (and this is my recommendation to both ASVS and Rohit's manifesto) is that we split these documents/guides into two very distinct sections

* Section 1 - A small objective, language/framework/behaviour agnostic description of what we are trying to do, with a big focus on the how Section 2 should be used (i.e. maintained, updated, customized, consumed and supported).

* Section 2 - Very detailed and comprehensive information of the security behaviour (or implications) that we want our target audience to be aware of, in a way that can be easily manipulated (i.e. filtered and sorted) and tool-consumable. Just like a Reference Book, this Section 2 is not designed to be read from beginning to the end, but designed to be easily customizable to (as much as possible) the exact scenario faced by its reader (i.e. consumer (which in most cases will be the developer))
This topic goes to the heart to one of the objectives that I have for the  O2Platform<http://www.owasp.org/index.php/OWASP_O2_Platform>, which is to create an technological eco-system where the security guidance that we (Security Industry) and framework developers (Microsoft, Spring, Apache, Facebook, etc...) create, is made available to developers, so that they have 'visibility' into the security implications of what they are creating / coding, and ultimately, they are abel to move into a world where they dont have to worry about understanding security (while creating apps as secure as they client's risk appetite is).

Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

2010/1/19 Sethi, Rohit <rohit at securitycompass.com<mailto:rohit at securitycompass.com>>
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> [mailto: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<mailto: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.

************************************************************

_______________________________________________
OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org<mailto:OWASP-Leaders at lists.owasp.org>
https://lists.owasp.org/mailman/listinfo/owasp-leaders

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20100119/8c16bf44/attachment-0001.html