OWASP Top 10 2017 final version has been released!

In recent years, cloud, API, and other technologies widely used, the software development process to introduce agile development and DevOps to achieve the development of operation and maintenance work automation, version of the rapid iteration. The rapid expansion of the attack surface is also accompanied, the attacker can always find a new attack surface. Within this context, after four years we once again usher in OWASP Top 10 update.

OWASP Top 10 Historical

Since the release of the first edition in 2003, OWASP Top 10 has released six versions in 14 years ( 2003-2004-2007-2010-2013-2017 ). Among them, the history of the most important update was undoubtedly the 2010 version, the first use of risk management for the root causes of web security and management, the specific application of the security risk assessment method to get Top ranking. Subsequent versions have continued the risk assessment methodology. Prior to this, it is the formation of loopholes in the top ranking. In 2007, for example, the calculation method is based on  MITRE Vulnerability Trends for 2006, extract ten web application security issues.

OWASP Top 10 2017

The most important 2017 update for this release is the addition of three types of questions, “A4 2017 XML External Entities XXE), A8 2017 Insecure Deserialization, and A10 2017 Insufficient Logging & Monitoring”.

2017 and 2013 version mapping relationship see the following figure. Compared to the 2013 version, some of the risk factors also have some changes. In the case of XSS, the vulnerability detectability is reduced from “easy” to “average” by 2013, and server-side XSS vulnerabilities are easier to detect by code analysis or testing, and client XSS vulnerabilities are very difficult to identify.

A4 2017 XML External Entities (XXE)

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:
• Your application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
• Any of the XML processors in the application or SOAP-based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by the processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.
• If your application uses SAML for identity processing within the federated security or single sign-on (SSO) purposes. SAML uses XML for identity assertions and may be vulnerable.
• If your application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.
• Being vulnerable to XXE attacks likely means that your application is vulnerable to denial of service attacks including the billion laughs attack.

A8 2017 Insecure Deserialization

Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker.
This can result in two primary types of attacks:
• Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.
• Typical data tampering attacks such as access control-related attacks where existing data structures are used but the content is changed.
Serialization may be used in applications for:
• Remote/Inter-process Communication (RPC/IPC)
• Wire protocols, web services, message brokers
• Caching/Persistence
• Databases, cache servers, file systems
• HTTP cookies, HTML form parameters, API authentication tokens

A10 2017 Insufficient Logging & Monitoring

Insufficient logging, detection, monitoring and active response
occurs any time:
• Auditable events, such as logins, failed logins, and high-value transactions are not logged.
• Logs of applications and APIs are not monitored for suspicious activity.
• Alerting thresholds and response escalation as per the risk of the data held by the application is not in place or effective.
• Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts. For larger and high performing organizations, the lack of active response, such as real-time alerting and response activities such as blocking automated attacks on web applications and particularly APIs would place the organization at risk from extended compromise. The response does not necessarily need to be visible to the attacker, only that the application and associated infrastructure, frameworks, service layers, etc. can detect and alert humans or tools to respond in near real time.

Reference: OWASP