In my previous blog post I discussed briefly why there was no change in the top two.
A3 - Sensitive Data Exposure
The OWASP Top 10 2013 list has sensitive data exposure listed at A6. In 2017 this moves up to the A3 position. What is Sensitive Data Exposure? Essentially this is a result of applications that provide inadequate protection of sensitive exposure, thus allowing the data to be easily obtainable. Sometimes this can be in the form of unencrypted passwords or customer information being stored on what an organisation thinks is a well-protected database. However this is not always the case, database could be storing data in an encrypted format the application presents this information in clear text when asked. The application could be fooled into providing information through an injection attack that results in a massive leak of sensitive data. Or worse still, a developer gets sloppy and posts login credentials or similar in a public code repository that could essentially be used to steal sensitive information (See the Uber breach 2017).
Uber joins the likes of Deloitte, Equifax and London Heathrow Airport as high profile examples of sensitive data exposure in 2017. And with GDPR looming in 2018 it’s more important than ever for organizations to ensure they are taking as many security measures as possible to protect sensitive data both at rest and in transit.
The mitigations for sensitive data exposure can be complex and outside the full scope of this blog, but ensuring that data are fully encrypted both in transit, and at rest; Store only the minimum amount of sensitive data, and anything else not required is either not captured at all or deleted after use. Think about key management, and how you store and protect passwords. Finally consider ensuring application forms don’t use autocomplete and have caching disabled where sensitive information is being captured.
A5 – Broken Access Controls
Whilst technically a ‘new category’ it is in fact a merger of A4 – Insecure direct object references and A7 – Missing function level access control. Broken Access controls are pretty open in nature. It happens when an end user, through the tampering of cookies, tokens, URLs or similar, gain access to data they shouldn’t be able to. For example, a piece of code that verifies the user is logged into the application but not what data that user can subsequently access. OWASP provides many different definitions of broken access controls. Ultimately the simplest way to look at it is: Should I have access to this data when logged in? If the answer is no, then Broken Access control.
To prevent this companies must ensure the DevOps team get into the mindset of ensuring the default stance on data access is none for example. (Or deny by default), and then working out from there employing good solid access controls to ensure only the right privilege is available to the right users.
A6 – Security Misconfigurations:
Although dropped from A5 to A6 for the 2017 list, Security Misconfigurations are still rife across many web applications. Not ensuring all software is up to date – the OS, code libraries, Web/App server, database – is one cause of security misconfigurations but there are many others – default accounts and passwords still available or not changed, error handling not configured correctly potentially resulting in sensitive information leakage. Unnecessary services, ports. The list can and often does go on.
Security misconfigurations can be reduced through the implementation of solid process. It starts with good solid processes – ensure you have identical hardened environments (Dev, QA and production), ensure you have a patch management process in place that not just addresses patches in OS, DB and applications but also in code libraries being used for the applications. And don’t neglect regular vulnerability scanning and audits to ensure the organisation is aware of and can address new vulnerabilities or missing patches.
A7 – Cross Site Scripting:
On the 2013 list, XSS held the number 3 position but for 2017 it dropped to A7. Whilst still an incredibly common attack that can lead to user accounts hijack, remote control of browsers, expose browser and clipboard history and contents – its overall risk rating diminishes according to OWASP.
DevOps can mitigate XSS easily using frameworks specifically designed to escape XSS, or through the implementation of a content security policy (CSP) as a defence in depth mitigation. XSS is both easy to exploit, easy to detect and easy to mitigate against, and as a result DevOps teams should not be delivering applications with this vulnerability present.
Gone (But not forgotten)
Both A8 Cross-Site Request Forgery (CSRF) and A10: Unvalidated Redirect and Forwards were dropped from the 2017 list, based on the feedback gathered by OWASP these dropped to #13 and #25 respectively in the ‘popularity’ list.
There is not much to say about both of these entries. Yet DevOps teams should remember that just because these have slipped outside the top 10 they are not to be ignored, rather teams should continue to ensure that coding practises they use are providing mitigations for these well documented vulnerabilities as well as the top 10.
In the final part of the blog we will look at the new entries - A4 XML External Entities, A8 Insecure Deserialization and A10 Insufficient Logging and Monitoring - and how they impact the overall DevOps Process.