I hope everybody have already read the latest OWASP Top-10 list (https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf). Let me share some useful insights about it.
First of all, OWASP Top-10 is NOT a vulnerability classification system. Rather it is a list of the most critical security risks for web application. What’s the difference? For example, the XSS risk (A-7) can be exploited through different vulnerabilities, not only through Cross Site Scripting (XSS) vulnerability, but also, for example through a Response Splitting (a.k.a. CRLF-injection) and many others. But the same labels for risks and vulnerabilities lead to confusion.
OK, but do we have a vulnerability classification system? No we do not! That’s the main reason why we are still under attack. The most promising attempt at a classification and assessment system is the CWE (Common Weakness Enumeration) but it’s still incomplete and very complicated to learn. CWE is designed to classify all the software errors, not only security issues and only for the web application. Another good attempt is WASC (http://projects.webappsec.org/f/WASC-TC-v2_0.pdf) designed to classify threats. Even though it is completely outdated (2010) it is still good enough and applicable because of its simplicity. Please remember, all the vulnerability types and classes that exist now are just tags and nothing more. We still have no complete classification of it. And this is important.
Let’s look at all the Top-10 points to understand in details what it does mean and what it doesn’t mean.
A2. Broken Authentication. Mainly it’s about session and password management. It’s strange a little bit to mix credential stuffing attacks, session ID disclosure in URLs and storing unhashed passwords in the database into one risk, but OK…
A3. Sensitive Data Exposure. In the official paper only cryptographic cases are covered, like unhashed passwords (yes, once again, we have already counted it as A2), plain/text transport protocols, mistakes of implementation of encryption protocols (like CA, CNAME, CRL/OCSP checks), etc. Now you may ask: “would it not it be better to call it encryption errors?” No… Because technically your stack traces and application errors disclosed worldwide are also subject to this risk. The same risk!
That’s all at the moment. I’ll publish the next part in next couple of weeks.