Recent updates to the OWASP top 10 have been proposed and are up for comment.
- https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
- http://lists.owasp.org/pipermail/owasp-topten
- http://lists.owasp.org/pipermail/owasp-topten/2017-April/001381.html
The two big additions are:
- A7 – Insuficient Attack Protections
- A10 – Underprotected APIs
The OWASP top 10 has traditionally had more prescriptive titles, these depart from that and have earned some controversy. Whether or not these should be in the final OWASP top 10, these are important issues which everyone needs to be aware of.
A7 – Insufficient Attack Protection
Logging is essential for modern security operations and an absence of logging can waste enormous amounts of time for information security teams to pick apart what is happening in an application.
This is the first place OWASP mentions logging.
From an information security standpoint, logging basic usage activities in your application is important. Examples depend on the nature of your app, but common ones might be:
- Failed logins
- Successful logins
- Issuance of tokens
- Expiration of tokens
- Attempted use of expired tokens
The specifics in OWASP and the controversy fall into the problem of what to do once logging detects a condition which is important for the security of the application?
So A7 treads down the issue of response.
- Does the application actively slow down malicious activity?
- Does the application have *any* protections against people performing automated attacks?
And A7 then treads further into response tools. Does the logging to to an IPS? Should the IPS block the attack? Can a software patch be deployed? Can a virtual patch be deployed?
All of this goes too far for OWASP, annoying people, but from an information security standpoint, looking beyond the intentionally narrowed focus of OWASP, these are important issues.
If your application has no ability to detect or even log basic usage activities, how can anyone make any confident statement about the current status of the application’s controls?
A10 – Underprotected APIs
I’m not sure what the rationale was to include this in OWASP, although it’s certainly an issue which is appearing with higher frequency.
From conversations I’ve had with developers on this issue, a new school of application developers seem to view the Internet differently than the generation who came before. Segregation of presentation from data is now an accepted common practice and application architecture describes front ends and back ends in a way which contradicts how operations teams and security teams view them.
The message for these developers is that an API is just as much exposed to the Internet as any other component you have on your application or site. This never should have needed to be part of OWASP’s top-10, but here we are. It’s being highlighted.
Your APIs are subject to attack, just like your login pages or any other part of your web application.
What has Infosec been doing about this?
Although these items haven’t been part of the OWASP top-10 in the past, I and other infosec professionals encouraged developers to add these kinds of features or to be aware of these issues.
Without logging of any kind, Information security teams are reliant on tools such as custom Snort signatures and custom WAF (web application firewall) signatures. These are not ideal. They’re not necessarily inline with your QA process and they’re subject to break your application in unexpected ways.
Well documented API parameters with bounds checking and some understanding of the user community have helped infosec protect applications, but this is an expensive, error prone and generally not a very effective process.
The new OWASP top 10 places some of the burden of logging, having some kind of active response tools and treating APIs with the respect they deserve back on to the developers. The top 10 is up for discussion at this time. whether or not these make the cut for the “Top 10”, they’re certainly critical issues.