[Owasp-webcert] OWASP Evaluation and Certification Criteria

Jeff Williams jeff.williams at aspectsecurity.com
Mon Aug 6 18:07:29 EDT 2007


Hi Mark,

Here are a few ideas for you to consider. This is just a quick
top-of-my-head dump, not a full review.  One thing that would make it
easier for me to review would be a summary document that just lists the
categories and requirement text (one-liners).  I'm always much more
comfortable reviewing the details once I'm sure the topics are right.
I'll look at process later.


AUTHENTICATION

See USERMAN-009 - Passwords should be stored hashed, not encrypted


SESSIONS

1. Wouldn't it be clearer to developers to say ALL traffic from login
form to logout results must go over SSL, instead of having both SESS-003
and AUTHN-002.
2. Application should be sure that the server-side session is
invalidated upon logoff
3. Application should be sure to change the session id upon login (to
prevent fixation)
4. At this point, do you think anyone should be generating their own
tokens?  How about a "use the container provided session token"


ACCESS CONTROL

1. Document the access control policy
2. Centralize the access control mechanism
3. Use only trusted information in access control checks
4. Enforce presentation layer access control (means don't allow users to
see widgets they shouldn't)
5. Enforce access control to URLs (some people call this coarse-grained)
6. Enforce access control to business functions
7. Enforce access control to services
8. Enforce access control to data (some people call this fine-grained)
9. Keep administrative functions in a separate application (as much as
possible)
10. Avoid exposing direct object references (see Top Ten 2007)
11. I think we should specify whitelist in this section


VALIDATION

1. Not sure output validation really deserves a spot (output encoding
absolutely does)
2. I think we should specify whitelist here for both validation and
encoding
3. Canonicalization and Encoding should be split.  Input needs to be
canonicalized.  Output needs to be encoded.


PREVENTING SPECIFIC ATTACKS

1. Forced browsing (or generalize parameter tampering)
2. Don't allow arbitrary forwarding after an access control check
3. The buffer overflow items could be combined (I'd prefer to just
require languages that are resistant)
4. AppDOS - applications should minimize resources expended prior to
authentication


DATA PROTECTION

1. Don't create your own encryption
2. Store keys safely
3. Not sure P3P is the right solution here
4. Control access to temporary files, and clean them up when you're done


BACKEND CONNECTIONS

1. This deserves its own section - if not, then they will always be
ignored. These requirements apply to EACH backend connection.
2. Secure communications (SSL, leased line) 
3. Authentication - credentials stored properly
4. Access Control - who can invoke?
5. All input to service validated and encoded
6. All output from service treated as untrusted
7. Errors handled properly
8. Logged properly


SECURITY MONITORING

1. Use a proper logging API (don't build your own)
2. Applications should detect obvious attacks and respond accordingly
(This is a pipe dream.  But dammit, it would make applications an order
of magnitude more difficult to attack, and it ain't that hard.  Scans
are super obvious -- just log them out and disable their account).


I think there's an argument for including concurrency and code quality
type issues (like use of System.out and keeping test/debug code out of
production).  But we can talk later about those.

--Jeff

Jeff Williams, CEO
Aspect Security
Work: 410-707-1487
Main: 301-604-4882


-----Original Message-----
From: owasp-webcert-bounces at lists.owasp.org
[mailto:owasp-webcert-bounces at lists.owasp.org] On Behalf Of Mark Curphey
Sent: Sunday, August 05, 2007 12:11 PM
To: owasp-webcert at lists.owasp.org
Subject: [Owasp-webcert] OWASP Evaluation and Certification Criteria

For those that want to see some progress attached is the latest draft. 

1. Remember the idea is to build a template from which we can derive
individual Evaluation and Certification Criteria or indeed a complete
scheme. What you see is the template from which we will "configure" a
reference implementation. This approach is scalable and I have heard
from a few of you off-line that you really like this and a few banks
plan to adopt it which is great news! This will allow Big Co X or Big Co
Y to choose their password quality or link to their own secure code
standards without being constrained by a generic lowest common
denominator approach but agreeing on the big ticket items. The idea is
not to cover every possible thing. 

2. Authorization - I need some help with this. What do we need to define
here?

I plan to complete the Process and People parts tomorrow and then
configure the reference implementation. This will be the one with
tangible values and not the cut and paste <insert here>.

Please don't waste time on detailed feedback (especially for grammar)
BUT I would like commentary and feedback on the topics included in
Technology and Process. Are there any missing? 

Note: This has highlighted that there is a need for a great deal of
supporting material such as secure coding standards and detailed How To
Test for specific issues. This is both an issue and an opportunity for
OWASP to pull together various projects in a cohesive way. 


More information about the Owasp-webcert mailing list