https://resources.infosecinstitute.

com/topic/owasp-top-10-application-security-risks-2013-vs-
2017/
APPLICATION SECURITY

OWASP top 10 application security

risks: 2013 vs 2017
April 2, 2018 byYassine Aboukir
The Open Web Application Security Project (OWASP) is a global, nonprofit
organization aiming to improve the security of applications and raise awareness
of secure coding practices. They create new tools for both individuals and
organizations, and build practical, knowledge-based documentation for the
security community.

The OWASP Top 10 is a list of common and critical security vulnerabilities that
could affect applications. The first version was released back in 2003, which
was updated in 2013. However, as OWASP puts it, “change has accelerated
over the last four years, and the OWASP Top 10 needed to change.”
Using feedback from firms specializing in application security and data from
surveys filled by over 500 individuals, OWASP issued a new release candidate
in April 2017. The first release was controversial and pushed back by the
AppSec community, so OWASP had to make new changes and issued a new
draft in August. The latter was finally adopted and published in November 2017.
This article clarifies the new web security risks as defined by OWASP, and
draws a comparison between 2013 and 2017 versions by listing all the changes
that have taken place.

Comparative table of 2013 and 2017 OWASP Top 10 Lists (Image from OWASP)
OWASP 2013 vs 2017: What has remained the same?
The A1 – Injection class of vulnerabilities tops both lists as the risk will remain
present as long as applications blindly trust user input and do not have a proper
sanitization mechanism in place. SQL injection, for instance, is still hackers all-
time favorite attack vector, and according to Verizon, SQL injection is involved
in nearly a quarter of incidents where card details are compromised.
OWASP 2013 vs 2017: What has changed?
A2 – Broken authentication and Session Management was shortened and
renamed Broken Authentication which makes sense since the latter is more
general and includes sessions-related issues.
A3 – Cross-Site Scripting (XSS) has dropped in ranking to hold the 7th
position after it was the 3rd in 2013 list. Although XSS is still a severe risk that
would lead to session hijacking, remote code execution in the victim’s browser,
etc., most frameworks are now automatically escaping XSS by design, such as
the latest Ruby on Rails, React JS, etc.
A4 – Insecure Direct Object References was merged with A7 – Missing
Function Level Access Control into a new category called A5 – Broken
Access Control. Both categories were relatively similar and share the same
root cause, which is missing control access. It all boils down to a simple
question: Am I supposed to have access to this data when logged in? As a
result, merging both categories is logical and expected based on the AppSec
community feedback over the past years.
A5 – Security Misconfiguration is still a relevant issue, but dropped in the list
by one ranking to settle in the 6th position.
Sensitive Data Exposure was listed as A6 in OWASP 2013. In 2017, it moves
up to the A3 position. Sensitive data exposure has been a huge issue in the
past few years, which resulted in very alarming security breaches at Uber,
Deloitte, Equifax and other large companies. This is especially concerning with
GDPR on the horizon.
OWASP 2013 vs 2017: What risks were retired?
A8 – Cross-Site Request Forgery (CSRF) was retired and dropped from the
2017 list. This does not mean the risk doesn’t exist anymore. According to
OWASP, the reason behind this is “many frameworks include CSRF defenses,
[CSRF] was found in only 5% of applications.”
Similarly, A10 – Unvalidated Redirects and Forwards was retired from the
list. According to OWASP, “while found in approximately in 8% of applications, it
was edged out overall by XXE.” Open redirect itself is a relatively low severity
issue. It is usually exploited for phishing purposes but is still a weakness
attackers abuse and chain with other vulnerabilities in order to achieve a higher
security impact.
It is important to keep in mind just because these have slipped outside the
OWASP Top 10, it does not mean they should be ignored. Rather,
organizations must continue to ensure the coding practices they use are
mitigating these well-documented vulnerabilities, as well as those in the current
OWASP Top 10.
OWASP 2013 vs 2017: What new risks were added?
Based on the community insights and supported data, OWASP added three
new classes of security risks to the list:
1. A4 – XML External Entities (XXE)
This is a class of attacks that target applications using XML parsers. The attack
takes place when an XML user input contains a reference to an external entity,
which then is processed by a misconfigured XML parser.
A successful exploitation leads to disastrous consequences, such as accessing
web server resources, conducting an SSRF attack to scan ports and enumerate
internal network, denial of service when chained with billion laughs attack, etc.
This particular attack has been around for decades, but it has only recently
received attention as high-profile companies such as Facebook, Twitter and
Google are also finding themselves vulnerable via bug bounty programs.
Most XML parsers are vulnerable to XXE by default, but the proper way to
mitigate XXE is to completely disable DTDs (external entities).
2. A8 – Insecure deserialization
This attack takes advantage of how applications make use of serialization and
deserialization. Serialization is the process of converting objects into data
format, commonly JSON and XML, to store them or use them in
communications. Deserialization is the opposite process which takes formatted
data and structures it into objects.
The attack, however, targets the deserialization process through untrusted user
input. Attackers abuse deserialization features when the application is
deserializing untrusted user input. A successful exploitation allows it to carry out
 denial of service (DoS) attacks, bypass access controls and eventually remote
code execution.
3. A10 – Insufficient logging & monitoring
This is more of a lack of control than a vulnerability. It’s nevertheless very important to
have proper mechanisms in place to log and monitor all kinds of events and activities,
whether operational or security related. These logs are indispensable to detect malicious
activity or unauthorized breaches in a timely manner; the lack of this control only
benefits attackers, giving them a persistence access or pivot to others’ systems.
According to OWASP, a lack of proper logging and monitoring carries the following
risks:
 Auditable events, such as logins, failed logins and high-value transactions are not logged.
 Warnings and errors generate no, inadequate or unclear log messages.
 Logs of applications and APIs are not monitored for suspicious activity.
 Logs are only stored locally without any Cloud backup.
 Appropriate alerting thresholds and response escalation processes are not in place or effective.
 Penetration testing and scans by
DAST tools (such as
OWASP ZAP) do not trigger alerts.
 The application is unable to detect, escalate or alert for active attacks in real time or near real
time.
Source
 OWASP Top 10 – 2017, OWASP
Posted: April 2, 2018
---

SEGURIDAD DE LA APLICACIÓN

Los 10 principales riesgos de seguridad

de las aplicaciones de OWASP: 2013
frente a 2017
2 de abril de 2018 porYassine Aboukir
Compartir:
El Proyecto de seguridad de aplicaciones web abiertas (OWASP) es una organización
global sin fines de lucro que tiene como objetivo mejorar la seguridad de las
aplicaciones y crear conciencia sobre las prácticas de codificación segura. Crean nuevas
herramientas tanto para individuos como para organizaciones, y crean documentación
práctica basada en el conocimiento para la comunidad de seguridad.

El OWASP Top 10 es una lista de vulnerabilidades de seguridad comunes y críticas que

podrían afectar las aplicaciones. La primera versión se lanzó en 2003, que se actualizó
en 2013. Sin embargo, como dice OWASP, "el cambio se ha acelerado en los últimos
cuatro años, y OWASP Top 10 necesitaba cambiar".

Utilizando los comentarios de empresas especializadas en seguridad de aplicaciones y

datos de encuestas realizadas por más de 500 personas, OWASP emitió una nueva
versión candidata en abril de 2017. La primera versión fue controvertida y la comunidad
de AppSec la rechazó, por lo que OWASP tuvo que hacer nuevos cambios y emitió un
nuevo borrador en agosto. Este último fue finalmente adoptado y publicado en
noviembre de 2017.
Este artículo aclara los nuevos riesgos de seguridad web definidos por OWASP y hace
una comparación entre las versiones de 2013 y 2017 enumerando todos los cambios que
se han producido.

Tabla comparativa de las listas OWASP Top 10 de 2013 y 2017 (Imagen de  OWASP )

OWASP 2013 vs 2017: ¿Qué ha permanecido igual?

La clase de vulnerabilidades A1: Inyección encabeza ambas listas, ya que el riesgo
permanecerá presente mientras las aplicaciones confíen ciegamente en la entrada del
usuario y no tengan un mecanismo de desinfección adecuado. La inyección SQL, por
ejemplo, sigue siendo el vector de ataque favorito de los piratas informáticos de todos
los tiempos y, según Verizon, la inyección SQL está involucrada en casi una cuarta
parte de los incidentes en los que se comprometen los datos de la tarjeta.
OWASP 2013 vs 2017: ¿Qué ha cambiado?
A2: La autenticación rota y la gestión de sesiones se acortaron y se
renombraron Autenticación rota , lo que tiene sentido ya que esta última es más
general e incluye problemas relacionados con las sesiones.
A3: Cross-Site Scripting (XSS) ha descendido en la clasificación para ocupar la
séptima posición después de haber sido la tercera en la lista de 2013. Aunque XSS sigue
siendo un riesgo grave que conduciría al secuestro de sesión, la ejecución remota de
código en el navegador de la víctima, etc., la mayoría de los marcos ahora escapan
automáticamente de XSS por diseño, como el último Ruby on Rails, React JS, etc.
A4: referencias de objetos directos inseguros se fusionó con A7: control de acceso
de nivel de función faltante en una nueva categoría llamada A5: control de acceso
roto. Ambas categorías eran relativamente similares y comparten la misma causa raíz,
que es la falta de control de acceso. Todo se reduce a una simple pregunta: ¿Se supone
que debo tener acceso a estos datos cuando inicie sesión? Como resultado, la fusión de
ambas categorías es lógica y esperada según los comentarios de la comunidad de
AppSec en los últimos años.
A5: la configuración incorrecta de seguridad sigue siendo un problema relevante,
pero cayó en la lista por un ranking para ubicarse en la sexta posición.
La exposición de datos confidenciales se incluyó como A6 en OWASP 2013. En
2017, sube a la posición A3. La exposición de datos confidenciales ha sido un gran
problema en los últimos años, lo que resultó en brechas de seguridad muy alarmantes en
Uber, Deloitte, Equifax y otras grandes empresas. Esto es especialmente preocupante
con GDPR en el horizonte.
OWASP 2013 vs 2017: ¿Qué riesgos se retiraron?
R8: la falsificación de solicitudes entre sitios (CSRF) se retiró y se eliminó de la lista
de 2017. Esto no significa que el riesgo ya no exista. Según OWASP, la razón detrás de
esto es que "muchos marcos incluyen defensas CSRF, [CSRF] se encontró en solo el
5% de las aplicaciones".
Del mismo modo, A10 - Redireccionamientos y reenvíos no validados se retiró de la
lista. Según OWASP, "si bien se encuentra en aproximadamente el 8% de las
aplicaciones, XXE lo superó en general". La redirección abierta en sí misma es un
problema de gravedad relativamente baja. Por lo general, se explota con fines de
phishing, pero sigue siendo una debilidad de la que los atacantes abusan y se encadenan
con otras vulnerabilidades para lograr un mayor impacto en la seguridad.
 Es importante tener en cuenta que el hecho de que estos se hayan deslizado fuera del
OWASP Top 10 no significa que deban ignorarse. Más bien, las organizaciones deben
continuar asegurándose de que las prácticas de codificación que utilizan mitiguen estas
vulnerabilidades bien documentadas, así como aquellas en el OWASP Top 10 actual.
OWASP 2013 vs 2017: ¿Qué nuevos riesgos se agregaron?
Según los conocimientos de la comunidad y los datos compatibles, OWASP agregó tres
nuevas clases de riesgos de seguridad a la lista:
1. A4: entidades externas XML (XXE)
Esta es una clase de ataques que se dirigen a aplicaciones que utilizan analizadores
XML. El ataque tiene lugar cuando una entrada de usuario XML contiene una referencia
a una entidad externa, que luego es procesada por un analizador XML mal configurado.
Una explotación exitosa conduce a consecuencias desastrosas, como acceder a los
recursos del servidor web, realizar un ataque SSRF para escanear puertos y enumerar la
red interna, denegación de servicio cuando se encadena con un ataque de miles de
millones de risas, etc.
Este ataque en particular ha existido durante décadas, pero solo recientemente ha
recibido atención ya que compañías de alto perfil como Facebook, Twitter y Google
también se encuentran vulnerables a través de programas de recompensas por errores.
La mayoría de los analizadores XML son vulnerables a XXE de forma predeterminada,
pero la forma correcta de mitigar XXE es deshabilitar por completo las DTD (entidades
externas).
2. A8 – Deserialización insegura
Este ataque se aprovecha de cómo las aplicaciones utilizan la serialización y la
deserialización. La serialización es el proceso de convertir objetos en formato de datos,
comúnmente JSON y XML, para almacenarlos o usarlos en las comunicaciones. La
deserialización es el proceso opuesto que toma datos formateados y los estructura en
objetos.
Sin embargo, el ataque tiene como objetivo el proceso de deserialización a través de la
entrada de un usuario que no es de confianza. Los atacantes abusan de las funciones de
deserialización cuando la aplicación está deserializando la entrada de un usuario que no
es de confianza. Una explotación exitosa le permite llevar a cabo ataques de denegación
de servicio (DoS), eludir los controles de acceso y, finalmente, la ejecución remota de
código.

3. A10 – Registro y monitoreo insuficientes

Esto es más una falta de control que una vulnerabilidad. Sin embargo, es muy
importante contar con mecanismos adecuados para registrar y monitorear todo tipo de
eventos y actividades, ya sean operativos o relacionados con la seguridad. Estos
registros son indispensables para detectar actividades maliciosas o infracciones no
autorizadas de manera oportuna; la falta de este control solo beneficia a los atacantes,
brindándoles un acceso persistente o un pivote a los sistemas de otros. De acuerdo con
OWASP, la falta de registro y monitoreo adecuados conlleva los siguientes riesgos:
 Los eventos auditables, como inicios de sesión, inicios de sesión fallidos y transacciones de alto
valor no se registran.
 Las advertencias y los errores generan mensajes de registro inexistentes, inadecuados o poco
claros.
 Los registros de aplicaciones y API no se supervisan en busca de actividad sospechosa.
 Los registros solo se almacenan localmente sin ninguna copia de seguridad en la nube.
 Los umbrales de alerta apropiados y los procesos de escalada de respuesta no están
implementados o no son efectivos.
 Las pruebas de penetración y los análisis de las herramientas DAST (como OWASP ZAP ) no
activan alertas.
 La aplicación no puede detectar, escalar o alertar sobre ataques activos en tiempo real o casi
en tiempo real.
Fuente
 Top 10 de OWASP – 2017 , OWASP
Publicado: 2 de abril de 2018