This is the last part of my trilogy about OWASP Top-10 2017 risks. Two previous parts (one and two) described A1-A6 risks and this time I’d like to not just explain A7-A10 risks but also draw an intersection or overlap venn diagram of them. I hope this diagram would clarify why the questions about “OWASP Top-10 coverage” are inherently inaccurate.
Let’s start with the A7-A10 then.
I’m sure that everybody knows what this is.. But once again, this XSS risk in OWASP does not necessarily mean there is an XSS vulnerability under the covers. The same A7 risk can happens because of Response Splitting (a.k.a. CRLF injection), wildcard domains described in crossdomain.xml,Access-Control-Allow-Origin header or others. Keep in mind that OWASP A7 risk can be realized not just through stored (persistent), reflected or DOM-based XSS.
This is my favorite thing. If you read the previous part of this post, you might have noticed that I’ve already mentioned A4 (Xml External Entities, XXE) as my favorite issue. You are right, but I’m right as well at the same time. The fact that XML is a serialization format, automatically means that A4 XXE is completely included inside and covered by A8 Insecure deserialization risk. Everytime when we can claim that A4 risk happened it means immediately that the A8 risk is happened as well.
Besides XML, in recent years some other data formats became popular because of the attacks triggered through them. We should remember here OGNL serialization format,which was exploited in Struts2 and was used to hack Equifax in September 2017. Other examples include Java serialization exploits (take a look immediately at the yso tool if you never met it before) for JBoss, Jenkins, Liferay, etc. and Ruby marshaller (a.k.a. yaml-exploit)
This is “I told you so” risk type which we remember all the time when somebody exploits us though a publically available and well known exploit. Obviously all the other risk types intersect with this risk. I call this risk “lower orbit” meaning that all the other risks except A6 are located somewhere on this orbit.
This is the risk of unawareness, meaning you should not only have a logging and monitoring system, but also have all the alerts configured. From my personal point of view it means that you have the continuous security process established to mitigate this risk. At this point I can direct you to Microsoft-borned SDL and in particular to the last Response phase (<https://www.microsoft.com/en-us/sdl/process/response.aspx>) describes almost the same thing.
So, let’s draw something ;)
First at all, I can claim that the A6 (Security Misconfiguration) is a superclass over everything, just because each time when any other risk is realized, the A6 risk is realized as well. This means that all the risks from A1 to A5 and from A7 to A10 are parts of A6 Security Misconfigurations. We can also claim this outer zone of A6 and all the other OWASP Top-10 risks as a “Non OWASP Top-10 Security Misconfiguration issues” that should be covered by security process.
Secondly, we can be sure that all the issues have some overlaps with A9 (Known issues). Because any issue that realizes any OWASP Top-10 risk can be known and will be known after some time. This outer zone of A9 and all the other OWASP Top-10 risks can be named as “Non OWASP Top-10 Known issues” and indicate what should be covered by a patch management.
Authentication (A2) and authorization (A5 a.k.a. access control) intersect each other and A3 Sensitive data exposure as was mentioned before in the first and second parts of this work.
Since XML is a data serialization format, A4 (XXE) is completely included inside A8 Insecure data serialization.
All the other classes have no intersections except A6 and A9 which I prefer to call as a higher and lower OWASP Top-10 orbits.
Finally the OWASP Top-10 risks overlap diagram looks like this:
I hope this overlap diagram will help you understand OWASP Top-10 2017 risks a little better. Thanks for reading! I’ll appreciate any feedback via comments.
BTW, these three articles will be published together as a whitepaper on the Wallarm website soon.