[Owasp-webcert] OWASP Evaluation and Certification Criteria

Mark Curphey mark at curphey.com
Wed Aug 8 09:46:55 EDT 2007


Thanks Jeff this is excellent. Let me process it all and send out a revised
draft by the end of the week.  See inline specifics and some questions. 

-----Original Message-----
From: owasp-webcert-bounces at lists.owasp.org
[mailto:owasp-webcert-bounces at lists.owasp.org] On Behalf Of Jeff Williams
Sent: Tuesday, August 07, 2007 12:07 AM
To: owasp-webcert at lists.owasp.org
Subject: Re: [Owasp-webcert] OWASP Evaluation and Certification Criteria

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.

Curphey> I thought that was there. I'll double check. 


AUTHENTICATION

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

Curphey> Would be a configuration for the OWASP version ie algorithm, bit
length etc unless you are saying they should never be anything other than
hashed?


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.

Curphey> Ack and this would have stopped all that BH Gmail nonsense. 

2. Application should be sure that the server-side session is
invalidated upon logoff


Curphey> Ack


3. Application should be sure to change the session id upon login (to
prevent fixation)

Curphey >Ack

4. At this point, do you think anyone should be generating their own
tokens?  How about a "use the container provided session token"

Curphey > I think it should be a configuration option. Maybe there are
super-secure systems that want to use something above and beyond. I think we
should and will say "Use container provider" in the derived versions. 


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)

Curphey> The thought was where data is processed my multi-systems you can't
rely in the daa you placed in a store being the same as the data you will
later retrieve. It maybe semantics. 

2. I think we should specify whitelist here for both validation and
Encoding

Curphey > Ack

3. Canonicalization and Encoding should be split.  Input needs to be
canonicalized.  Output needs to be encoded.

Curphey > Let me chomp on this considering above


PREVENTING SPECIFIC ATTACKS

1. Forced browsing (or generalize parameter tampering)

Curphey> I (maybe wrongly) associate forced browsing with looking for web
server default files. Is this different ? noteToSelf(glossary).ToDo(); 

2. Don't allow arbitrary forwarding after an access control check

Curphey >Ack

3. The buffer overflow items could be combined (I'd prefer to just
require languages that are resistant)

Curphey > I think the configuration ie OWASP version etc will but if you
said that many big fin serves would fail for legacy C CGI that will never be
retired in my life time (well you know what I mean)

4. AppDOS - applications should minimize resources expended prior to
Authentication

Curphey > How would you test for this though?


DATA PROTECTION

1. Don't create your own encryption

Curphey > Taken care of by configuration. Will be in OWASP Reference
Implementation

2. Store keys safely

Curphey > Isn't this in key management generally ie in configuration (say
OWASP Reference Implementation) we can say smart card or hardware crypto
device or java keystore etc. 

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

Curphey > All noted. Could this be under Data Storage or is it separate?


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. 
_______________________________________________
Owasp-webcert mailing list
Owasp-webcert at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-webcert



More information about the Owasp-webcert mailing list