We need to talk about application security

Owen Pendlebury, Global Board of Directors at OWASP Foundation

Threats to the application layer is not a new thing, but it has been becoming more and more prevalent over the past number of years. The rise in attacks stems from the increase in high-value data being stored in constantly changing environments.

Akamai found the number of application attacks grew by 63% in 2017, while 73% of security incidents flagged by Alert Logic were application breaches. Yet why is there so little investment into the application layer, in comparison to endpoint protection?

Essentially, effective cyber security starts with awareness at all levels and the realisation that, at some point, your organisation will be attacked. The ‘it’s not if, but when’ has become somewhat of a cliché – but it is very true. Therefore, it’s imperative that an organisation understands its threat landscape and identifies the key assets, vulnerabilities and threat actors that put them at risk.

Organisations often have a significant budget put aside for costly security appliances in an effort to reduce their exposure. But, what many people fail to realise is that even with this type of investment there are many other areas of exposure.  It’s like a game of ‘whack-a-mole’, you get one vulnerable area and three more popup after. But the application layer is important to prioritise as an area that provides attackers with an ever-expanding attack surface.

The OWASP top 10 project used vulnerability data from organisations all over the world in order to classify the most common risks to organisations, associated with the application layer, that occur when applications are not developed with security in mind:

1. Injection – Occurs when untrusted data is interpreted as part of a command or query
2. Broken authentication – The misconfiguration of session management or authentication mechanisms that could allow an attacker to escalate their privileges or impersonate another user
3. Sensitive data exposure – Data that would normally be unavailable to an attacker is inadvertently accessible due to weak protection of applications or APIs being unencrypted
4. XML External Entities (XXE) – Use of older or poorly configured XML processors that can be manipulated to perform an action different from its normal workings
5. Broken access control – Restrictions on access to certain functionality or content are not properly enforced
6. Security misconfiguration – The configuration of key components has not been hardened in line with good practice which can disclose sensitive information to unauthorised users
7. Cross site scripting (XSS) – Untrusted user input is processed by the server without adequate validation or escaping
8. Insecure deserialisation – The features of native deserialisation mechanisms can be repurposed for malicious effect when accepting untrusted data
9. Using components with known vulnerabilities – Using components, such as libraries, frameworks, and other software modules that have known vulnerabilities associated with them
10. Insufficient logging and monitoring – Inadequate internal processes or monitoring capabilities for the identification of new attacks

Why this list is so staggering is because these coding flaws have not changed much over the years. With the presence of these issues in the application layer, it is clear there needs to be more awareness and guidance to aid developers in creating secure software.

Software developers are the foundation of any app. Therefore, in order to achieve secure software, developers must be supported and helped by the organisations they write code for. And as developers write the code, they need to embrace and practice a wide variety of secure coding techniques. This includes the user interface, business logic, the controller and the code database – all of these elements must be developed with security in mind.

To this end, there are a number of proactive controls a developer could use, and many of which our community love. For instance, define and document a standard for the required security functionality to be built into all software. This can include security requirements and verification criteria. Or, using security frameworks and libraries with embedded security, this helps software developer’s guard against security-related design and implementation flaws.

So, what can we do about it?

Speak and learn from your peers. It sounds simple but has a lot of value. And there are many conferences and training courses – ours included – which exist to promote software security awareness.

In fact, this is one of the main reasons why OWASP set up AppSec Europe, to provide attendees with insight into inspiring speakers for application security and cyber security, training sessions on various applications, networking, connections and exposure to the best practices in the industry. It’s only when developers, businesses and security bodies work together that we’ll stand a fighting chance in defending applications, networks and indeed, our own PII from cybercriminals.