With the growth of complexity, it is increasingly difficult to achieve cyber security and avoid having your critical infrastructure damaged. In these circumstances, software security issues are trending.

Bearing in mind threats arising from vulnerabilities of applications, an active Open Web Application Security Project (OWASP) community dedicated itself to enabling development, purchase and maintenance of trustworthy apps and APIs. OWASP sets its sights on providing awareness in web application security, regularly publishing their TOP 10 list of vulnerabilities

In this article we will bring closer what is OWASP TOP 10, list the most common web application security risks, compare the 2017 list version with previous release and suggest next steps in web application security.

What is OWASP TOP 10?

OWASP delivers free and open application security tools and standards, as well as plenty of valuable materials on security testing, secure code development and review. What is more, OWASP regularly prepares the OWASP Top 10 list. The list presents top 10 vulnerabilities that are most commonly found in web applications, what makes them easy to exploit. The attacks result not only in security breaches of your web app – stealing data or taking over your infrastructure – but more importantly, in harming the reputation of your company.

OWASP TOP 10 – 2017 Web Application Security Risks.

Take a look at the most common cyber security threats identified by OWASP.

– A1:2017 Injection

Injection flaws, such as SQL or LDAP injection, occur when an attacker sends untrusted data to an interpreter that is executed as a command or query without proper authorisation. It can result in data loss, corruption, disclosure to unauthorised parties and even a complete takeover.

How to prevent Injection?

Keep data separate from commands and queries. Use a safe API. Conduct application security testing.

– A2:2017 Broken Authentication and Session Management

Incorrectly configured user and session management authentication could allow attackers to compromise passwords, keys, or session tokens, or take control of users’ accounts to assume their identities temporarily or permanently. This can result in identity theft, money laundering and disclosure of highly sensitive information.

How to prevent Broken Authentication?

Implement multi-factor authentication if possible, as well as strong password checks. Do not ship or deploy with any default credentials.

– A3:2017 Sensitive Data Exposure

Many applications and APIs don’t properly protect sensitive data, such as financial, health records or other personal information. This could enable attackers to access such information to commit fraud or steal identities.

How to prevent Sensitive Data Exposure?

Classify data according to legal regulations. Do not store sensitive data unnecessarily. Make sure to encrypt all the data at rest and in transit.

– A4:2017 XML External Entity (XXE)

Old or poorly configured XML processors evaluate external entity references within XML documents. They can be used for attacks, including remote code execution, to scan internal system and to disclose internal files.

How to prevent XXE?

Patch or upgrade all XML processors and libraries. Use static application security testing (SAST) tools to inspect dependencies. Train your developers to identify and mitigate XXE.

– A5:2017 Broken Access Control

Wrongly configured or missing restrictions on authenticated users allow them to access unauthorised functionality or data. Attackers can access other users’ accounts, view sensitive documents and modify data and access rights.

How to prevent Broken Access Control?

Implement access control mechanisms. Conduct penetration tests to detect improperly functioning access controls.

– A6:2017 Security Misconfiguration

This is a common result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured security headers and verbose error messages containing sensitive information.

How to prevent Security Misconfiguration?

Regularly patch and upgrade systems, frameworks and components. Conduct Dynamic Application Security Testing (DAST).

– A7:2017 Cross-Site Scripting (XSS)

Cross-site scripting (XSS) flaws take place whenever an application includes untrusted data in a new web page without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser, that can hijack user sessions, redirect users to malicious websites or deface websites.

How to prevent XSS?

Separate untrusted data from active browser content. Use frameworks automatically escaping XSS by design. Apply best coding practices, like input validation and encoding data.

– A8:2017 Insecure deserialization

Insecure deserialization can lead to remote code execution. It can also be used to perform injection, replay and privilege escalation attacks.

How to prevent Insecure Deserialization?

Never accept serialized objects from untrusted sources, nor use serialization mediums that only permit primitive data types. Conduct penetration testing.

– A9:2017 Using Components with Known Vulnerabilities

For many companies, this risk should perhaps be top of the list. It is common that developers don’t know what components (such as libraries, frameworks, modules) are in their applications. Working with apps and APIs that use components with known vulnerabilities can result in exploiting insecure components and taking over the infrastructure or stealing sensitive data.

How to prevent using components with known vulnerabilities?

Obtain only resources from official sources over secure links. Monitor for unmaintained libraries and components. Analyse components of your software.

– A10:2017 Insufficient Logging and Monitoring

Insufficient logging and monitoring together with inefficient integration with security response systems allow attackers to attack systems further, maintain persistence, extract or destroy data and pivot to other systems.

How to avoid Insufficient Logging and Monitoring?

Ensure all failures (login, access control, server-side input validation) can be logged in to identify suspicious accounts and monitor this regularly. Conduct penetration tests.

OWASP TOP 10 2017 – differences with previous release

As the technology and architecture of developing applications rapidly and significantly changes, the OWASP list of TOP 10 web application security risks needs to continuously adapt to the new reality. Substantial community feedback and extensive data aggregated from participating organisations helped in preparation of the new app security threat list. Although in many ways the list looks very similar to a previous version, extensive connection with the business sector ensures OWASP list addresses the most up-to-date and important risks threatening organisations and touches key issues of modern software.
The most important differences with the previous OWASP TOP 10 2013 release are as follows:

Merging Broken Access Control Categories

‘A4-Insecure Direct Object References’ and ’A7-Missing Function Level Access Control’ categories from OWASP Top 10 2013 were merged into a single category ‘A4-Broken Access Control’. This eliminated any possible confusion arising from the wording of previous categories and facilitated a focus on key point of this category.

Removing Open URL Redirects and Forwards Category

’A10-Unvalidated Redirects and Forwards’ category was removed from the Top 10 list as available studies proved it was not as common as it had been in the past.

Adding new issues supported by the Community

’A8-Insecure Deserialization’ and ‘A10-Insufficient Logging and Monitoring Categories were added based on the community’s forward-looking insight into weakness categories.

Adding new issue supported by Data

‘A4-XML External Entities (XXE)’ Category was added due to support by data sets gathered by security testing tools (SAST).

Web Application Security – next steps

Over the years OWASP TOP 10 list evolved into the most common security compliance checklist. Eliminating OWASP TOP 10 vulnerabilities is a great starting point and a good way to decrease a risk of security breaches. But remember – it is only the first step towards security of your code and the whole organisation! There are numerous other issues that could possibly undermine an overall security of your web application.

Standard breach detecting time exceeds 200 days and is usually detected not by internal processes, but rather by external parties. There is still a lot to be done in terms of cyber security!

Consider implementing true standards such as the OWASP Application Security Verification Standard (ASVS). Focus on approaching application security, use available tools wisely and make security an integral part of your business culture. If this is beyond your scope, think about employing an external cyber security team which will provide guidance and conduct a web application security assessment. When choosing a company, it is worth considering those that beyond telling you what security issues your application has, are also able to effectively tackle identified vulnerabilities through their programmers.