[Owasp-topten] Some comments about RC1

Neil Smithline Neil at Smithline.net
Thu Feb 1 11:26:06 EST 2007

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. Who cares if there
   is a vulnerabilities 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 but has hard-to-explain corresponding attacks)? And why should
   I be worried about phishing (and what should I do about it) without
   understanding the vulnerabilities? Perhaps we need a top-ten attacks
   document as well? What are your thoughts? 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 not to be
      as secure."
      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."
      - When do URLs become unicode? There probably are a few
      preventions that need to come into place by then such as making sure that
      the URL and cert are in the character set you are expecting and don't
      include ones that have similar-looking characters.
      5. For A7, Preventing, I think a few things changes are needed:
   - I would add "When making trade-offs between protection and
      ease-of-use, consider requiring more complex authentication
mechanisms for
      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
might diverge
      the session ID in clear-text. I think the text should read
"Always make sure
      the secure session cookie is only transmitted over secure channels." 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 operating system 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
transmitting private
      - 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.

- Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-topten/attachments/20070201/f744f094/attachment.html 

More information about the Owasp-topten mailing list