6 ms·

Understanding the OWASP list

148 points by flywithdolp 7y ago

rtempaccount1 7y ago
The OWASP Top 10 is intended as an awareness tool to help raise visibility of web app. security issues. I'd agree with the article that it gets misused (a lot) as some kind of checklist that, if you apply, you can have a "secure" application. Ironically OWASP has several other great projects that are designed to provide methodologies to improve application security like ASVS https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Application_S... and at a more organizational level, OWASP SAMM https://owaspsamm.org/ https://owaspsamm.org/ . Where I do feel some frustration with this article is where , to me, it feels like it's suggesting that "shift left security" (the idea that security activities should take place earlier in the development lifecycle) is any any way a new concept. The idea of doing more application security work early in the development process has been around at least 20 years and probably more. Instead of having new buzzwords for it, to try and make it more attractive, I'd be much more interested in a study of why after all this time it's still not uncommon to see a first security touchpoint for a project be a penetration test done 2 weeks before go-live.
- deleted 7y ago
  [deleted]
- joeyrideout 7y ago
  I agree. Unfortunately, a lot of security tools get misused in general. (Don't get me started on CVSS!) I like ASVS and hope that it becomes more popular. Other control standards like CAIQ/CCM are also useful depending on the application. OWASP SAMM I haven't used yet but I want to have a look! My org uses BSIMM currently. Happy to see an open alternative. Edit: To be fair, I've noticed "shift left" emerge as a buzzword alongside the popularity of DevOps and DevSecOps. There has been a meaningful improvement in tooling that allows for earlier testing, so I'll concede the new buzzword :)
  - tptacek 7y ago
    CVSS is worthless; the only way to misuse it is to use it at all.
    - carty76ers 7y ago
      I’ve never used it, but could you elaborate on why it’s worthless? And what alternatives do you use?
      - wglb 7y ago
        It is an answer to the wrong question.
        dspillett 7y ago
        That is no more helpful in terms of the extra explanation requested than the original response... Kind of "is it possible to be more vague here?" "yes, yes it is'.
      - deleted 7y ago
        [deleted]
      - kerng 7y ago
        It is a tool to have a discussion, not a solution to risk management. Security is one of the few fields that uses qualitative measurements, and any attempt of applying more quantitative techniques faces a lot of resistance. CVSS in isolation is pretty good, but for risk management it lacks "context". A higher level framework would be needed for that. A bug can have a CVSS score of 10 (critical), and still have little to no impact to the business. It's all about context. I don't think it even ever intended to be more then a data point to consider for risk management but dev
    - TeMPOraL 7y ago
      Seconding others; could you elaborate? I've been involved in some work tangential to the security space, and keep encountering some of those "enterprise security for management framework" buzzwords, things like Lockheed KillChain, VERIS framework and similar. I keep wondering if there's any actual value coming from that direction?
- t34543 7y ago
  I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.
  - javagram 7y ago
    Sometimes it’s the other way though, e.g. enabling a framework level XSRF protection mechanism is usually very easy for a greenfield project but it’s ignored by many developers in my experience until a security audit comes through and finds the problem - now every form in the app has to be re-tested to verify the mitigation was applied.
  - throwaway_bad 7y ago
    Eh, can't only blame product managers for this. Developers don't like security features that make development slower either. I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies. Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.
    - dspillett 7y ago
      > can be safely deprioritized until your app gets complex enough to need it I'd accept "until your app looks like it might leave proof-of-concept classification". And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.
  - dspillett 7y ago
    And in a situation where there are multiple products the matter gets more complex and competing priorities mean the wrong vice is made more often. I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.
kingofpee 7y ago
Never heard of OWASP before Do programmers really follow it? Is it a status quo for companies to make sure their software follow OWASP top 10 like a checklist?
- statictype 7y ago
  Yes. Its an important bullet point in RFPs for enterprise software.
  - kingofpee 7y ago
    So OWASP compliance is a thing as much as GDPR compliance in the enterprise world?
    - ownagefool 7y ago
      Not really. GDRP results in major fines thus has major funding. OWASP is something someone might tack on, but most of the people involved have little to no ability to check.
    - tptacek 7y ago
      No. There is no such thing as OWASP certification. The only teeth OWASP "compliance" might have is a contractually agreed MUSTFIX disposition for vulnerabilities that are on the OWASP Top 10 (which would be pretty silly and is not something I've ever seen done).
- Jedi72 7y ago
  Yes, I'm guessing you haven't ever Googled 'web app security' or similar.
- rtempaccount1 7y ago
  OWASP is a not-for-profit industry group not a governmental initiative. However it's generally the most used "standard" for web application security and some regulations will use OWASP projects as references for what things should be considered for security
fulafel 7y ago
There are multiple lists, some for purpouses other than web app implementation. Some examples: https://www.owasp.org/index.php/OWASP_Cloud-Native_Application_Security_Top_10 https://www.owasp.org/index.php/OWASP_Cloud-Native_Applicati... https://www.owasp.org/index.php/OWASP_Mobile_Top_10 https://www.owasp.org/index.php/OWASP_Mobile_Top_10 https://www.owasp.org/index.php/OWASP_Proactive_Controls https://www.owasp.org/index.php/OWASP_Proactive_Controls
petra 7y ago
The lift scala framework offers protection against many of the OWASP vulns automatically: https://seventhings.liftweb.net/security https://seventhings.liftweb.net/security Can this be improved to include support for all the OWASP ?if not, why ?
jpalomaki 7y ago
I think most should be actually checking the "OWASP Application Security Verification Standard Project" [1] instead of just the Top 10 list. The application security verification standard has quite clear requirements that you can just feed into your software development process. The requirements are split to three different levels, L1, L2 and L3. L1 requirements are more or less straightforward, standard application development stuff. L2 and L3 go more into processes. The idea is also that the L1 requirements can be verified by external penetration testing, without access to source code. I would say the L1 requirements are something everybody involved in creating web apps professionally should check. Maybe some the requirements don't make sense for your particular application, but for those cases it is a good exercise to write down why not. [1] https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Application_S... (the document can be downloaded from the links on the right side)
- lol768 7y ago
  ASVS is a good idea, but it has forever lost its credibility for me after the following recommendation appeared in one of its published documents (2.13 I believe, level 1 ASVSv3): >Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack against the encryption routine I think this has been fixed, but I don't understand why encryption (which implies reversibility) was ever advocated over a proper password hashing method such as BCrypt or PBKDF2. And no, using terms like "one way encryption" would not be any better - it shows a general lack of understanding.
  - tptacek 7y ago
    There is a general lack of understanding. OWASP is a shambolic volunteer project and its outputs are uneven at best. I would be particularly wary of OWASP when it comes to specialist topics, and cryptography is a great example of that.
    - rtempaccount1 7y ago
      OWASP may be a shambolic volunteer project, but it's interesting that, in many areas, it's still the best thing available for the last 18 years...
unixhero 7y ago
Yup. And add MITRE ATT&CK to that list

148 points by flywithdolp 7y ago

The OWASP Top 10 is intended as an awareness tool to help raise visibility of web app. security issues. I'd agree with the article that it gets misused (a lot) as some kind of checklist that, if you apply, you can have a "secure" application. Ironically OWASP has several other great projects that are designed to provide methodologies to improve application security like ASVS https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Application_S... and at a more organizational level, OWASP SAMM https://owaspsamm.org/ https://owaspsamm.org/ . Where I do feel some frustration with this article is where , to me, it feels like it's suggesting that "shift left security" (the idea that security activities should take place earlier in the development lifecycle) is any any way a new concept. The idea of doing more application security work early in the development process has been around at least 20 years and probably more. Instead of having new buzzwords for it, to try and make it more attractive, I'd be much more interested in a study of why after all this time it's still not uncommon to see a first security touchpoint for a project be a penetration test done 2 weeks before go-live.

deleted 7y ago
[deleted]
joeyrideout 7y ago
I agree. Unfortunately, a lot of security tools get misused in general. (Don't get me started on CVSS!) I like ASVS and hope that it becomes more popular. Other control standards like CAIQ/CCM are also useful depending on the application. OWASP SAMM I haven't used yet but I want to have a look! My org uses BSIMM currently. Happy to see an open alternative. Edit: To be fair, I've noticed "shift left" emerge as a buzzword alongside the popularity of DevOps and DevSecOps. There has been a meaningful improvement in tooling that allows for earlier testing, so I'll concede the new buzzword :)
- tptacek 7y ago
  CVSS is worthless; the only way to misuse it is to use it at all.
  - carty76ers 7y ago
    I’ve never used it, but could you elaborate on why it’s worthless? And what alternatives do you use?
    - wglb 7y ago
      It is an answer to the wrong question.
      - dspillett 7y ago
        That is no more helpful in terms of the extra explanation requested than the original response... Kind of "is it possible to be more vague here?" "yes, yes it is'.
    - deleted 7y ago
      [deleted]
    - kerng 7y ago
      It is a tool to have a discussion, not a solution to risk management. Security is one of the few fields that uses qualitative measurements, and any attempt of applying more quantitative techniques faces a lot of resistance. CVSS in isolation is pretty good, but for risk management it lacks "context". A higher level framework would be needed for that. A bug can have a CVSS score of 10 (critical), and still have little to no impact to the business. It's all about context. I don't think it even ever intended to be more then a data point to consider for risk management but dev
  - TeMPOraL 7y ago
    Seconding others; could you elaborate? I've been involved in some work tangential to the security space, and keep encountering some of those "enterprise security for management framework" buzzwords, things like Lockheed KillChain, VERIS framework and similar. I keep wondering if there's any actual value coming from that direction?
t34543 7y ago
I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.
- javagram 7y ago
  Sometimes it’s the other way though, e.g. enabling a framework level XSRF protection mechanism is usually very easy for a greenfield project but it’s ignored by many developers in my experience until a security audit comes through and finds the problem - now every form in the app has to be re-tested to verify the mitigation was applied.
- throwaway_bad 7y ago
  Eh, can't only blame product managers for this. Developers don't like security features that make development slower either. I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies. Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.
  - dspillett 7y ago
    > can be safely deprioritized until your app gets complex enough to need it I'd accept "until your app looks like it might leave proof-of-concept classification". And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.
- dspillett 7y ago
  And in a situation where there are multiple products the matter gets more complex and competing priorities mean the wrong vice is made more often. I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.

kingofpee 7y ago

Never heard of OWASP before Do programmers really follow it? Is it a status quo for companies to make sure their software follow OWASP top 10 like a checklist?

statictype 7y ago
Yes. Its an important bullet point in RFPs for enterprise software.
- kingofpee 7y ago
  So OWASP compliance is a thing as much as GDPR compliance in the enterprise world?
  - ownagefool 7y ago
    Not really. GDRP results in major fines thus has major funding. OWASP is something someone might tack on, but most of the people involved have little to no ability to check.
  - tptacek 7y ago
    No. There is no such thing as OWASP certification. The only teeth OWASP "compliance" might have is a contractually agreed MUSTFIX disposition for vulnerabilities that are on the OWASP Top 10 (which would be pretty silly and is not something I've ever seen done).
Jedi72 7y ago
Yes, I'm guessing you haven't ever Googled 'web app security' or similar.
rtempaccount1 7y ago
OWASP is a not-for-profit industry group not a governmental initiative. However it's generally the most used "standard" for web application security and some regulations will use OWASP projects as references for what things should be considered for security

fulafel 7y ago

There are multiple lists, some for purpouses other than web app implementation. Some examples: https://www.owasp.org/index.php/OWASP_Cloud-Native_Application_Security_Top_10 https://www.owasp.org/index.php/OWASP_Cloud-Native_Applicati... https://www.owasp.org/index.php/OWASP_Mobile_Top_10 https://www.owasp.org/index.php/OWASP_Mobile_Top_10 https://www.owasp.org/index.php/OWASP_Proactive_Controls https://www.owasp.org/index.php/OWASP_Proactive_Controls

petra 7y ago

The lift scala framework offers protection against many of the OWASP vulns automatically: https://seventhings.liftweb.net/security https://seventhings.liftweb.net/security Can this be improved to include support for all the OWASP ?if not, why ?

jpalomaki 7y ago

I think most should be actually checking the "OWASP Application Security Verification Standard Project" [1] instead of just the Top 10 list. The application security verification standard has quite clear requirements that you can just feed into your software development process. The requirements are split to three different levels, L1, L2 and L3. L1 requirements are more or less straightforward, standard application development stuff. L2 and L3 go more into processes. The idea is also that the L1 requirements can be verified by external penetration testing, without access to source code. I would say the L1 requirements are something everybody involved in creating web apps professionally should check. Maybe some the requirements don't make sense for your particular application, but for those cases it is a good exercise to write down why not. [1] https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Application_S... (the document can be downloaded from the links on the right side)

lol768 7y ago
ASVS is a good idea, but it has forever lost its credibility for me after the following recommendation appeared in one of its published documents (2.13 I believe, level 1 ASVSv3): >Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack against the encryption routine I think this has been fixed, but I don't understand why encryption (which implies reversibility) was ever advocated over a proper password hashing method such as BCrypt or PBKDF2. And no, using terms like "one way encryption" would not be any better - it shows a general lack of understanding.
- tptacek 7y ago
  There is a general lack of understanding. OWASP is a shambolic volunteer project and its outputs are uneven at best. I would be particularly wary of OWASP when it comes to specialist topics, and cryptography is a great example of that.
  - rtempaccount1 7y ago
    OWASP may be a shambolic volunteer project, but it's interesting that, in many areas, it's still the best thing available for the last 18 years...

unixhero 7y ago

Yup. And add MITRE ATT&CK to that list