@OWASP top 10 ... in English
In order to raise security awareness broadly in our teams (repetition is the mother of learning), I was guided to talk about OWASP 10 to them. Well, reading the cheat sheet, there were stuff in there that I ... just didn't get. So, I consulted our in-house Cloud Security Architect and had him explain things to me, a favour which I thought I'd pay forward. This article, then, will highlight some parts of the top 10 which either was hard to grasp, or where our CSA gave additional insights.
Next off, does the input makes sense? For example, does it make sense to set a payment, an invoiced value or time spent to a negative value? Is the total request payload size reasonable for what the user (or attacker) is trying to do? What is reasonable, then? Here, you need to start monitoring early to get a sense for what a "reasonable request" is.
Second off, be aware of whom you are calling. Or, in other words, don't automatically trust responses from external APIs. Those APIs could both be compromised, giving you malicious data back, be downright wrong (e.g. due to versioning issues) or have other unforeseen issues. An API call is a seam in your system, which you need to be diligent about - catch metrics, check if the responses make sense and learn as you go.
Want more? Check out Troy Hunt's OWASP Top 10 for .NET developers. Through there, you can get access to his pluralsight course and where he'll be talking on security next.
If you have access to PluralSight, our CSA recommended these courses in particular:
A1 Injection
Is the posted response still in the encoding you sent out (UTF-8)? Here, what we want to protect ourselves from, is for an attacker to force our poor web server to start spewing out logs due to unhandled exceptions, giving the attacker more information. So, before you even start processing the request - does it have the appropriate encoding? If not, it's appropriate to return 400 Bad Request. We can be unapologetically obtuse here, logging the error on the server side, but leaving little information to the client.Next off, does the input makes sense? For example, does it make sense to set a payment, an invoiced value or time spent to a negative value? Is the total request payload size reasonable for what the user (or attacker) is trying to do? What is reasonable, then? Here, you need to start monitoring early to get a sense for what a "reasonable request" is.
A4 Insecure Direct Object References
Our CSA highlighted two points here: First off, be aware of whom is calling you (authentication) and what that person (or system) is allowed to do (authorization). If the caller is a reporting system (for whatever reason), then it does not make sense that it should call any Set-methods of your overbloated WCF-service (I'm reaching for examples here ... ), even though it could have access to them through a shared WSDL.Second off, be aware of whom you are calling. Or, in other words, don't automatically trust responses from external APIs. Those APIs could both be compromised, giving you malicious data back, be downright wrong (e.g. due to versioning issues) or have other unforeseen issues. An API call is a seam in your system, which you need to be diligent about - catch metrics, check if the responses make sense and learn as you go.
A7 Missing Function Level Access Control
Keep your different system assets separate. Logs should be written to a physically separate spot from the content files of your web. Your configuration should be on a different spot than your images etc. etc.Want more? Check out Troy Hunt's OWASP Top 10 for .NET developers. Through there, you can get access to his pluralsight course and where he'll be talking on security next.
If you have access to PluralSight, our CSA recommended these courses in particular:
Comments