Secure Coding mailing list archives

Secure Web Application Framework Manifesto


From: Paco at cigital.com (Paco Hope)
Date: Tue, 12 Jan 2010 15:31:21 -0500


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.




Current thread: