[Owasp-guide] ASVS 1.0 Released - Time to Move
Andrew van der Stock
vanderaj at owasp.org
Mon Jun 8 22:42:56 EDT 2009
Call to Action!
I am pleased to see the ASVS 1.0 Release Has occurred. What I would
like is for folks to grab the ASVS 1.0 Release, and let's go through
each of the Guide's major chapters, and bring it into line.
We need to re-write the Guide to be positive about ASVS verifications
and provide the detail the ASVS lacks. I would like it if we could
stick to the ASVS's headings to make a mapping possible. If we have
additional material (historical or not yet in the ASVS), it should
come after the ASVS controls. This will allow us to make a call as to
whether it survives or we ask for it to be included in ASVS 1.1.
Long term - the Guide needs a new leader.
You might have noticed, but I don't have a lot of time due to family
commitments. It's time to hand the baton over. This time, I'm only
going to project lead until we can find someone to replace me. I asked
the relevant folks last month to find a new leader, but I've not heard
anything back, so let's do it the old fashioned way - doing some work.
The way to become the Guide project leader is by DOING. It's how I got
the job. This is a meritocracy. I want to see contributors produce
their best work, provide a strong conceptual model and commitment to
research - don't just parrot received wisdom - you should demonstrate
why the received wisdom is good, or even better, come up with a
stronger model through research and development. For example, back in
2004, I researched exactly why questions and answers were so bad and
did some basic research as to how strong they are (roughly equivalent
to a 9 bit password). That's why Guide 2.0 has language against them.
Once we have been through this process, I will be making
recommendations to the OWASP Leaders / Global Projects committee as to
who will take over the Guide. Of course, I am one voice, but
realistically, demonstrating to everyone why you should be chosen is
easy if you've done high quality work, and lots of it.
What needs to happen between now and then
The ASVS 1.0 has controls like this:
V8.1 - Verify that the application does not output error messages or
stack traces containing sensitive data that could assist an attacker,
including session ID or personal information
So in the Error Handling section, we need to discuss design (how to
design an error handling system that simply cannot disclose such error
messages to the screen or user traffic (i.e. headers, cookies, hidden
comments or variables, viewstate, etc) and then how to do it using
ESAPI (if possible) or if ESAPI doesn't do that, then some snippets
that *actually* work in at least J2EE, .NET and PHP.
We need to ensure our positive controls meet ALL of the ASVS
Edits should come to the list, so we can all see them. Do not change
the Wiki. As we need to move things carefully as folks have deep
linked us outside, I will be asking Larry our Wiki guru to help me
create the final 3.0 version in the Wiki. So let's just do the text
file thing and send them to this list. Once we have a new structure
that meets the ASVS requirements, I will put the edits into the Wiki.
I need at least 14 authors for this version. If you've done work for
me in the past, such as the folks who did some work on the session
management and SQL chapters, can you please re-do it based on the ASVS?
V1 Architecture - S
V2 Authentication - L
V3 Session Management - L
V4 Access Control - L
V5 Input Validation - L
V6 Output Encoding - L
V7 Cryptography - Specialist
V8 Error Handling - M
V9 Data Protection - S
V10 Communications Security - M
V11 HTTP Security - S
V12 Security Configuration - S
V13 Malicious Code - S
V14 Internal Security Verification - S
S = Short < 8 controls, M = Medium 9-13 controls, L = Long 13+ controls
When you ask for a chapter, please reply to this list with a brief
outline of how you'd approach each of the topics covered in the ASVS,
and if there's existing material you can use or adopt. Chapter
adoption is on a first come first served basis. You'll have two weeks
(short topics), three weeks (medium topics), and four weeks (long
topics) to provide a first draft to the list. Please submit your draft
here, and we'll all look at it together. It doesn't have to be
perfect, and we're all here to make it the best it possibly can be.
DO NOT LET PERFECT GET IN THE WAY OF GOOD. Release whatever you have
at the end of your deadline. That allows us to give that work to
someone else to continue so it's not wasted if you can't continue. Let
us know as early as possible if you can't do the work you've been
assigned so we can re-assign it as quickly as possible.
If you need help with what a control should say, that's what this list
is for. Don't hesitate to ask. There's a lot of really talented folks
on this list.
Each chapter author can re-use what we already have (and I encourage
this), but you need to re-write it to be completely positive. Think
like a developer - is there ANY information in there that is better
off in the testing guide or the code review guide? If so, let us know
and I'll help get it across to that reference unless it's already
there (in which case we drop ours). There's no point in telling a
developer what NOT to do. Tell them ONLY what to do. They can only
code the stuff we want them to do.
Don't log credit cards.
Log non-sensitive information - as necessary - to provide
accountability. Non-sensitive information includes usernames, actions,
and so on.
Log sensitive information carefully in a highly protected logging
mechanism. For example, If you are going to create an audit log of
credit card transactions, please review PCI DSS 1.2 requirements as to
separation of protected data elements and storage requirements. Such
usage usually requires encrypted logs, and high levels of protection
such as access controls, and so on.
Is anyone here good at diagrams? If so, please let me know as we need
a lot of diagrams in EXACTLY the same style the entire way through.
Deadline - OWASP USA 2009 - November 10-11 2009.
* Early drafts should be posted to this list by the end of July
* Final drafts should completed and be in the Wiki by no later than
end of August
* Diagrams and snippets should be in by no later than end of September
* Final edits done by end of October so we can release to the
* Word and PDF version will be put together by me by the conference
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-guide