On Jan 12, 2010, at 9:23 AM, Rohit Sethi wrote: > Many of us have argued that the features of underlying web > applications frameworks will make a major impact on the security of > the individual applications built on top of them.
This is timely, relative to John Steven's recent discussion (re: ESAPI) that it's not all in the code. There's a ton to be done in the code, but it's not all there. > I’d like to propose turning this into an OWASP project, but wanted to > solicit feedback from the security community prior to turning it into > an official project. I think this is an interesting start, but it seems unfocused. Some of the problems are broad (data confused as commands) and some are highly specific (getting down to the name of the researcher who discovered it). Some seem like they mention technology that's cool without describing the problem that the technology addresses and why that technology is the right answer to the problem. Some seem like issues that a framework could offer (pluggable security) and others seem like they are operating system issues (security logs) while still others seem like they are application business logic (login forms and password requirements). Providing some set of criteria and/or features that indicate compliance with certain best practices is a fine idea. Should you spend your time enumerating flaws and attacks, though, or spend time enumerating correct behavior? I say this because the criteria in this document do both. In some cases they are prescriptive: "use cryptographic random numbers." In other cases, they are untestable negatives: "don't accept illegal characters." I think each of these criteria should follow a formula. There needs to be some acceptance criteria for what makes the cut to be included in the manifesto, too. I think each of your criteria should have the same qualities that good software requirements have. They're often remembered using the mnemonic "SMART". Different people assign slightly different names, but I would suggest that, for your purposes, you consider: Specific, Measurable, Achievable, Relevant, Testable. I think you can admit criteria to your list that are weak in one of these areas, but if it is weak in two or more areas, it either needs to be expanded or removed (IMO). You have good and bad examples for each of these, so let me try to demonstrate: Specific: "illegal characters" is not specific, because what is illegal for one context is mandatory in another context. "Provide an encoding format for every page": that's specific. Measurable: "Safe file upload" is not measurable (any more than secure web app framework is). Supporting configurable session timeouts is measurable. Achievable: Safe interaction with unmanaged code is very hard to do. Not to say impossible, but achievability is going to be a key issue. Turning on secure cookie flags is obviously achievable. Relevant: I'm not sure if password policy and "login form" are relevant. If this is a framework we're talking about, application developers tend to manage this in their own business logic, not the underlying framework, right? The rest of your list is pretty relevant. Testable: I'm not sure if the arithmetic overflow protection is testable. Other things, like cryptographic randomness is, but even then you have to be careful how you specify the tests. Lastly, numerous people have created countless lists of flaws, defects, vulnerabilities, attack patterns, security patterns, programming mistakes, design mistakes, and so on. The security world is quite thick with them. I don't see hardly any referenced here, certainly none older than a year or two, despite software security being a 40-year-old field. I like your fundamental idea, of having a checklist of capabilities that enables descriptions and comparisons of frameworks. I just think it could use something else as its source material / organization. Paco -- Paco Hope, CISSP - CSSLP Technical Manager, Cigital, Inc. http://www.cigital.com/ Software Confidence. Achieved. _______________________________________________ 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. _______________________________________________
