[Owasp-topten] Some comments about RC1
owasp-topten at smithline.net
Thu Feb 1 21:32:52 EST 2007
Sorry if this is a dup - I got a bounced email and want to make sure it gets
---------- Forwarded message ----------
I just started reading but have a few comments on this.
1. I'll start off with a general comment. I think the separation from
vulnerabilities and attacks is really a big problem. Neither seems complete
without the other. I agree that they are different and probably don't belong
in the same list, but they are also tightly integrated. Why would I care if
there is a vulnerability if I don't clearly understand the attacks that can
be used against it (XSS is a perfect example of a simple-to-explain
vulnerability that comes with a hard-to-explain corresponding attack)? And
why should I be worried about phishing (and what should I do about it)
without understanding the vulnerabilities that enable it? Perhaps we need a
top-ten attacks document as well? I'd be happy to work on one. That would
give a good place to document things like XSS Attacks, Injection Attacks,
Phishing Attacks, etc... And for each attack variants could be discussed
(eg: SQL Injection, command processor injection, etc...) as well as the
corresponding vulnerabilities that enable the attacks and the remediations
that prevent the attacks.
2. Review your "Preventing" bullets. Some end in periods, some don't.
They probably all should be sentences.
3. For A10, Preventing,
- Perhaps you should add something to the last bullet such as
"Keep up to date with vulnerabilities and remediations for them
such as the
recent problems with .pdf and .doc files."
- I'd add "Try to rely on the container or well-trusted and
integrated solutions for access control. Home-grown solutions tend to be
4. For A9, Preventing,
- I'd change the "ensure that communications between..." bullet to
include "Be wary of trusting your firewall or any network security as the
sole means of protecting data."
5. For A7, Preventing:
- I would add "When making trade-offs between protection and
ease-of-use, consider requiring more complex authentication
more sensitive operations."
- Change " Use the container provided session management
mechanism and no custom cookies" to " Use the container provided
session management and authentication mechanism or a well-trusted and
integrated session management and authentication mechanism."
Then add a new
bullet "Do not add custom cookies." I think restricting to the container
session and authentication cookies is not realistic in a world of
CA/Netegrity's and such. No reason to make guidelines that we
know will be
- I don't like "Create a new session upon successful
authentication". Just following that doesn't tell the developer never to
transmit the new session over HTTP. For example, if the user is in the
middle of a secure operation and clicks the help button they
the session ID in clear-text when referencing the help page over HTTP.. I
think the text should read "Always make sure that once authentication has
occurred the session cookie is only transmitted over secure channels and
that the authenticated session cookie cannot be guessed from the
unauthenticated session cookie." or something like that.
- I'd add either to the logout link bullet or after it "Ensure
that logout links immediately log the user out or present a pop-up to
confirm. Never have the logout link take the user to a page that asks for
confirmation." Too often logout links go to a confirmation page that is
never read and the user doesn't logout.
- I'd also add "Ensure all sessions have appropriate timeouts."
6. For A8, Preventing:
- I'd add "Try to avid relying on OS file and process protection but
use it whenever and wherever possible."
- To the private keys bullet or just afterwards I'd add "Never
transmit private keys over insecure channels. If possible, never transmit
private keys at all. Sneaker-net is the best means of
- I'd also add "When possible, hash rather than encrypt
Have to run more but I'm not sure what your schedule is so I figured I'd
send this off now and follow-up with more later.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten