[Owasp-topten] Some comments about RC1

[Neil Smithline]

Sorry if this is a dup - I got a bounced email and want to make sure it gets
through.

- Neil

---------- 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
      less 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."
   5. For A7, Preventing:
   - 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
      broken.
      - 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 divulge
      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
transmitting private
      keys."
      - I'd also add "When possible, hash rather than encrypt
      passwords."

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/683dcb30/attachment.html