[Owasp-standards] Project Status - feedback and round2!

owasp-standards-admin at lists.sourceforge.net owasp-standards-admin at lists.sourceforge.net
Sat Feb 11 13:09:36 EST 2006

Hello List,

I'm a bit behind on this update (I said I'd start something by the end of
Jan), so apologies up front.  Anyhow, I'm going to work on the next draft of
the Web Application Security Standard and I though a good status update and
a discussion of the project would be a good place to start.  I'll also share
some of the things submitted so far, open it up for a last round of
suggestions, then work on the document.

To start off with, a high level view of the project.  What we are trying to
produce here is a mechanism whereby web-based applications can be audited
for *minimum* security.  I emphasise minimum because there's lots of things
that can be done to vastly improve security outside of what we'll be
suggesting in this project. Hopefully though we'll be able to agree on a
baseline that applications can be measured against, and get better (both the
standard and general quality of apps) over time.

Another bit of background to those coming in late :)  Originally this
project was called the PCI Web Application Security Standard (PCI-WASS)
Project.  The idea was to frame this project with what the PCI has done to
network security and give a context to what we'd like to achieve (like PCI,
but for apps).  Visa and MasterCard never "blessed" or sponsored the
project, and on their request we removed all PCI references.  This hasn't
changed the project in any way, and we continue to work for a vendor and
technology neutral project that will stand on it's own as a standard, or be
incorporated into other frameworks.  As ever, all suggestions, comments,
feedback are welcome from wherever they come, but they all "go in the pot
together" for us all to discuss.

And now on to the status update and suggestions from you guys.  What I've
tried to do is abstract out the relevant posts from the archive.  I'll try
and describe the direction I'd like the project to go (by all means this is
up for discussion), and then onto the specifics.

First up, where this project fits.

One subscriber asks is this content driven or project driven?  It's sort of
echoed by another posting asking if this is for auditors or developers?

I'm wanting to drive this project more towards the auditing (testing) rather
than the project (architecture/management) side.  The reasoning behind this
is that given a set of well known objectives, it should be quite easy to
design an application to meet them.  Remember, what we are trying to achieve
in this project is a baseline to gauge apps that they are "known good" to a
particular level of vulnerabilities (even if it's the "low hanging fruit"
variety - which I hope we can do better - but *something* being certain is
better than *nothing*).  We can do this at the design/code/implementation
level, but that leaves a lot of apps out there that we can't (easily)
assess.  With this approach I hope that we can use the project for auditors
(I'd prefer to say "testers" though, let's believe that everyone is
capable :) ), *and* developers, who can look at the standard and say "right,
I have to protect against these threats".

Next up, what level of detail is this project?  I've had people ask where it
fits in with other OWASP project (the top-ten and the testing guide

This is my Goldilocks analogy I'm sure you are all bored with.  The top-ten
is too "hot" - it's been a great project to draw attention to the issues
surrounding web apps, but it was never intended to be tested against.  For
example, there's great advice on unvalidated input, but (IMHO),  there's no
specifics in what to look for and where.  The testing guide on the other
hand is too much info for a standard.  It follows a complete testing
methodology throughout the SDLC (or would do if the project continues to be
updated which unfortunately it appears it hasn't been touched in a while).
The checklist is close, but it doesnt follow the level of detail any tester
would need to sign off on any particular objective.  It's certainly needed
(and I may turn my attention there after this project), but it's too "cold"
for what I think is needed on this project.

So, what I'd like to aim for is something in between - a short, high level,
document like the top ten which address all the issues but has enough detail
that people can test against (with clear pass/fail results) without having
to interpret what's required.  It shouldn't be a simple checklist (are all
inputs validated against [SQL|XSS|CmdInj|BO|...]), or a description of what
approach to use (you should follow variables from their input to their
output and if they are not "checked" in some way  then there is likely a
problem).  I'd like this project to say is what to test (leakage of session
values), why they need testing (separation of users, hijacking), and how
(session values should never been send "in the clear") - clear, specific,
and actionable objectives.  I understand that we won't be able to do this
and guarantee a secure app, but I'm hopeful that we'll be able to get
perhaps 90% of the issues and push the bar higher.  We can then continue to
update for changes in knowledge and technology, as well as new threats.

Lastly in this section, where does the project fit in?  Quite a few posts I
received were noting that some of these requirements were already in PCI
documents, other standards exits that cover what we are trying to acheive,
or why are we not covering X (where X could be host security, network,
database, etc).

Some of this I've answered above (and to be fair, they were early questions
to the list when I realized that I hadn't explained the project fully) in
that we shouldn't rely on the fact that what we produce will be incorporated
into another standard.  We'd like this to stand-alone, but also it should be
specifc just to web apps.  This I feel is important as however critical it
is to have a secure host, or to practice least-privilage on the underlieing
database, these we'll have to assume are covered (or we'll be here

Now on to the specific comments to the strawman document.  I really
appreciate the feedback everyone gave me, and I don't like to call out
individuals in a community-based project, but Justin Derry, Lyal Collins,
Ahmed Shahzad, and Jean-Jacques Halans gave some great suggestions.  A lot
of people helped frame the above discussion of where the project fits in
(and I hope you know who you are - thanks), but these guys gave laser sharp
focus to the area I think we needed the most - the actual requirements.
Thanks very much you guys.

** Passwords should not be stored within the application.

My thoughts are that this could be  a bit impractical - the app has to have
access to passwords in some level for authentication (ie in a database or a
file - however, if that was supposed to mean "hard-coded into the app", then
I agree, but think it's going to be difficult to test for).  However, they
shouldn't be "reversible", although once again I'm not sure how to test for
this externally.

** Check the value of hidden fields on server side and make sure the values
of the hidden fields returned by client are expected

Once again, a good requirement, and will make it into the next version, but
I think we need to be more specific.  Something like looking for hidden
fields, and doing [something] to them to check they can't be abused.  I was
thinking that hidden fields should fall under 4.2 (checking parameters are
in range), but it's a fair point to perhaps call it out separately.

** Cookies used for session identification or having other sensitive
information contained within them should be encrypted
Any thoughts on this from the list?  I feel that session identifiers, as
long as they are transmitted security, don't need to have their actual
contents encrypted (or signed/check-summed).  They are short lived and
should pass other requirements.  As for other sensitive information, do we
want *any* of this hanging around on the client?

** Add a new section to the document on summarising the PCI data protection
guidelines. The reason for this is most of the people I talk to in the
financial sector hear a lot about the OWASP guides and refer to them often
but they don't understand or know how to get to the PCI data protection
guidelines. (Although security staff within financial organisations know
this, most developers and application architects don't. Surely adding a
brief summary so that when anyone picks up this guideline/standard they can
have a brief rundown on the PCI data protection guidelines.)
A great thing to put in the introduction to the project - call out where it
fits and what the overlap is with other standards.

** Auditing of events. There is nothing in the guidelines about auditing of
activity, such as when a card number was received, when it was used, is it
stored for batch processing etc. This should probably also include recording
and storing of data such as the users details including IP address, etc.

Could be a good thing, but I can't think of a way to actually test this,
especially in a black-box nature which this project really *has* to follow
if it's every going to be used on *existing* apps.

** A password should use at least one numeric character and one alphabetic
character. The password should have as many different characters as
possible. Character variety is almost as important as password length.
Lower- and upper-case letters, numbers, and other characters
(!"?;%:?*()_+/@#$%...) may be used.  Also some comments on SANS saying that
passwords should be 8 or greater characters, shouldnt have any part of the
username, shouldn't be "easy to guess", etc, etc.

An extension of a requirement already in the strawman, but making the
password complexity much more stringent.  This is one I *know* is going to
cause upset to have in any standard.  I think we should start of with it
(can we come to an agreement on what is necessary?), and discuss the impact.

** Nothing about password expiration? Renew password every 6 months?
Once again, something difficult to specifically test for, but what does the
list think?

** Req. 6 should be expanded to counter attacks such as Session Riding, AKA
Cross Site Request Forgeries (CSRF)
Absolutely right!  I should have included this.  In the next version we have
to start adding how to look for, and test, for certain attacks

** Limiting scope [in section 1] to SSL only means things like VPNs can't be
used for sensitive data, nor encrypted objects in Web Services/SOAP
environments (encrypt the payload data, and pass it via http, not
necessarily https)

Yep, I hadn't considered wording it this way, but as long as the data is
protected in transit from sniffing/modification, then we should add this
into the requirement

** [RE: caching] Shouldn't you mention the actual HTTP headers and HTML meta
tags in question? Caching is also pretty browser dependant, handling headers
and meta tags differently. How is an auditor to test this? Another
anti-caching technique would be to append a random number to the querystring
part of the URL.

Yes, we should mention the HTTP and HTML tags in question (to cover the goal
of specifically calling out what to test).  I agree that caching is pretty
browser dependent, but I believe that there's a good combination that can be
used which will work on all browsers (which is i think how we should test
for this).  Also, we'd have to assume that clients are "well behaved"
(perhaps add that into the introduction), otherwise all bets are off - the
client could be trojaned, specifically doing malicious actions, or other
activities, in which case whatever we do on the server isn't going to affect
the client (it's just going to ignore us).  Hopefully, other requirements
will minimize (or mitigate) what a badly behaved client is trying to do.
Finally, I don't think we should specify solutions, just tests, and leave
the implementation details to the developers :)

Well, it's been a long post, and I'm glad that you made it down this far :)
If you feel like it, go back and have another look at the strawman document
at http://www.owasp.org/standards/wass.html and please comment on the doc or
any of the above.  I'll try and work up a new draft of the requirements when
I've got some feedback (so I can blame you guys for my inactivity :) - i.e.
"I've not had nearly enough feedback to justify working on a 2nd version
yet"!).  From there, I'll add a bit more flesh to the requirements (start in
the middle and work out - we'll do the intro and other "framing" material
when we know what we have), and possibly put a wiki up so changes can be
made by everyone at will.

I want to finally say thanks to everyone on the list for taking part and
having an interest in the project (hopefully, continued interest).  There's
been so many people, in addition to those I thanked above, that have said
that it's a good thing to do and have given support.  If that kind of
encouragement wasn't there, these kind of projects quickly die.  From
myself, and I'm sure others in the OWASP community, my heartfelt thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-standards/attachments/20060211/9fab92a5/attachment.html 

More information about the Owasp-standards mailing list