OWASP TOP

10
Versión 2017

1
SOBRE El Proyecto Abierto de Seguridad en Aplicaciones
Web (OWASP por sus siglas en inglés) es una
comunidad abierta dedicada a permitir que las

OWASP organizaciones desarrollen, adquieran y mantengan

aplicaciones y APIs en las que se pueda confiar.

2
OWASP TOP 10 VERSIÓN 2017
El cambio de versión de 2013 a 2017 agrega varios puntos nuevos, incluyento dos seleccionados
por la comunidad – A8:2017 Deserialización Insegura y A10:2017 Registro, Detección y
Respuestas Activas Insuficientes. Dos diferenciadores clave son las versiones anteriores del
OWASP Top 10 son las notables devoluciones de la comunidad y la gran cantidad de datos
recopilados de docenas de organizaciones, siendo posiblemente la mayor cantidad de datos
jamás reunidos en la preparación de un estándar de seguridad de aplicaciones.
Uno de los principales objetivos del OWASP Top 10 es educar a los desarrolladores,
diseñadores, arquitectos, gerentes y organizaciones sobre las consecuencias de las debilidades
más comunes y más importantes de la seguridad de las aplicaciones web. El Top 10 proporciona
técnicas básicas para protegerse contra estas áreas con problemas de riesgo alto, y proporciona
orientación sobre cómo continuar desde allí.

3
CAMBIOS DE
VERSIÓN 2013 A
2017
Nuevos riesgos, respaldados en datos:
 A4:2017 – Entidades Externas XML (XXE)

Nuevos riesgos, respaldados por la comunidad:

 A8:2017 – Deserialización Insegura

 A10:2017 – Registro y Monitoreo

Insuficientes
Fusionados o retirados, pero no olvidados:
 A4 – Referencia Directa Insegura a Objetos y
A7 – Ausencia de Control de Acceso a las
Funciones (fusionados en A5:2017 – Pérdida
de Control de Acceso)
 A8 – Falsificación de Peticiones en Sitios
Cruzados (CSRF)
 A10 – Redirecciones y reenvíos no validados

4
 OWASP Top 10 se centra en la identificación de
los riesgos más serios para una amplia gama de
organizaciones. Para cada uno de estos riesgos se
ha determinado un esquema de calificaciones.
Sólo las organizaciones saben los detalles
específicos de su negocio. Para una aplicación
determinada, podría no existir un agente de
amenaza que pueda ejecutar el ataque en cuestión.
Los valores que se otorgan a cada franja son los
siguientes:
 Amarillo, riesgo con calificación de 1

 Naranja, riesgo con calificación de 2

 Rojo, riesgo con calificación de 3

¿CÓMO SE CÁLCULA EL
RIESGO?
5
 Las fallas de inyección, como SQL, NoSQL, OS o

A1: 2017 LDPA ocurren cuando se envías datos no confiables

a un intérprete, como parte de un comando o
consulta. Los datos dañinos del atacante pueden

INYECCIÓN engañar al interprete para que ejecute comando

involuntarios o acceda a los datos sin la debida
autorización.

6
RIESGOS Y SUGERENCIAS DE
A1:2017
Una aplicación es vulnerable a los ataques de este tipo cuando:
 Los datos suministrados por el usuario no son validados, filtrados, o sanitizados por la
aplicación.
 La opción preferida es utilizar aun API segura, que evite el uso de un interprete por completo y
proporcione una interface parametrizada. Se debe migrar y utilizar una herramienta de Mapeo
Relacional de Objetos (ORMs).
 Se invocan consultas dinámicas o no parametrizadas, sin codificar los parámetros de forma
acorde al contexto.
 Realice validaciones de entrada de datos en el servidor, utilizando “listas blancas”. De todos modos,
esto NO es una defensa completa ya que muchas aplicaciones requieren el uso de caracteres
especiales, como en campos de texto, APOs o aplicaciones móviles.

7
RIESGOS Y SUGERENCIAS DE
A1:2017
 Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas ORM, para
extraer registros adicionales sensibles.
 Para cualquier consulta dinámica residual, escape caracteres especiales utilizando la sintaxis de
caracteres especifica para el intérprete que se trate.
 Los datos dañinos se usan directamente o se concatenan, de modo que el SQL o comando
resultante contiene datos y estructuras con consultas dinámicas, comando o procedimientos
almacenados.
 Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la fuga masiva de registros en
caso de inyección SQL.

8
EJEMPLOS DE ESCENARIOS
DE ATAQUE
 Escenario 1: la aplicación utiliza datos no confiables en la construcción del siguiente
comando SQL vulnerable:
String query = “SELECT * FROM accounts WHERE custID = ‘” +
request.getParameter(“id”) + “’”;
 Escenario 2: la confianza total de una aplicación en su framework puede resultar en consultas
que aún son vulnerables a inyección, por ejemplo, Hibernate Query Language (HQL):
Query HQLQuery = sesión.createQuery(FROM accounts WHERE custID = ‘” +
request.getParameter(“id”) + “’”);
En ambos casos, el atacante puede modificar el parámetro “id” en su navegador para enviar:
‘or ‘1’ = ‘1 . Por ejemplo:
http://example.com/app/accountView?id=‘or ‘1’ = ‘1

9
EXPERIENCIA PROPIA
Los cambios realizados en las consultas SQL en los anteriores ejemplos de escenarios de ataque
cambian sus significados, devolviendo todos los registros de la “accounts”. Ataques más
peligrosos podrían modificar los datos o incluso invocar procedimientos almacenados.
Soluciones propuestas:
 Utilizar los tipos de datos que ofrecen los lenguajes de programación para verificar que el dato
recibido es válido y que no contiene datos adicionales maliciosos.
 Por ejemplo, se pueden utilizar los tipos int o long al momento de recibir el campo id cuando se
quiere realizar una consulta por id.
 En Java, se puede definir una etiqueta @PathVariable para recibir datos en las peticiones y realizar
validaciones automáticas sobre el dato recibido:
@GetMapping(value = “id”)
public ResponseEntity<AccountDTO> findById(@PathVariable @Min(1) Long id)
 {…}
10
EXPERIENCIA PROPIA
 Definir tipos de datos de los resultados de las consultas a la fuente de datos.
 Ejemplo, si se desea consultar un objeto Account por su id se debe preparar al código para que
reciba un único objeto especifico:
Account findById(Long id);
Así, en caso de que, de alguna manera, se realice una inyección, el código generará error al recibir una
lista y no un único objeto.
 Siempre utilizar el ORM para realizar las consultas a la fuente de datos.
 El ORM no es infalible, pero ayuda a realizar muchas validaciones de sintaxis y validación de las
consultas realizadas, incluso durante la etapa de compilación.

11
EXPERIENCIA PROPIA
 Al realizar consultas personalizadas porque las que ofrece el ORM no son suficientes, no
utilizar SQL nativo sino la sintaxis que ofrece el ORM.
 Por ejemplo, se desea realizar una consulta que involucra 2 tablas (accounts y customers) para
consultar todas las cuentas de un cliente. La consulta, en caso de Java con JPA/Hibernate, se debería
crear utilizando la siguiente sintaxis:
@Query(“SELECT account
FROM Account account,
Customer customer
WHERE account.customer.id = customer.id
AND customer.id = :customerId”)
List<Account> findByCustomerId(@Param(“customerId”) Long customerId);
De esta manera, la consulta se asegura que lo que recibe es en realidad un long y funciona con la
configuración de DataSource/Entities que se haya realizado en el proyecto.

12
A2: 2017 PÉRDIDA Las funciones de la aplicación relacionadas a autenticación
y gestión de sesiones son implementadas correctamente,

DE permitiendo a los atacantes comprometer usuarios y

contraseñas, token de sesiones, o explotar otras fallas de
implementación para asumir la identidad de otros usuarios
AUTENTICACIÓN (temporal o permanentemente).

13
RIESGOS Y SUGERENCIAS DE
A2:2017
La confirmación de la identidad y la gestión de sesiones del usuario son fundamentales para
protegerse contra ataques relacionados con la autenticación.
Pueden existir debilidades de autenticación si la aplicación:
 Permite ataques automatizados como la reutilización de credenciales conocidas, cuando el
atacante ya posee una lista de pares de usuario y contraseñas válidos.
 Implemente autenticación multi-factor para evitar ataques automatizados, de fuerza bruta o reúso de
credenciales robadas.
 Permite ataques de fuerza bruta y/o ataques automatizados.
 No utilice credenciales por defecto en su software, particularmente en el caso de administradores.

14
RIESGOS Y SUGERENCIAS DE
A2:2017
 Permite contraseñas por defecto, débiles o muy conocidas, como “Password1”, “Contraseña1”
o “admin/admin”.
 Implemente controles contra contraseñas débiles. Cuando el usuario ingrese una nueva clave, la
misma puede verificarse contra la lista del Top 10000 de peores contraseñas.
 Posee proceso débiles o inefectivos en el proceso de recuperación de credenciales, como
“respuestas basadas en el conocimiento”, las cuales no se pueden implementar de forma
segura.
 Alinear la política de longitud, complejidad y rotación de contraseñas con las recomendaciones de la
Sección 5.1.1 para Secretos Memorizados de la Guía NIST 800-63 B’s u otras políticas de contraseñas
modernas, basadas en evidencias.

15
RIESGOS Y SUGERENCIAS DE
A2:2017
 Almacena las contraseñas en texto claro o cifrados de hashing débiles.
 Mediante la utilización de los mensajes genéricos iguales en todas las salidas, asegúrese que el
registro, la recuperación de credenciales y el uso de APIs, no permiten ataques de enumeración de
usuarios.
 No posee autenticación multi-factor o fue implementada de forma ineficaz.
 Limite o incremente el tiempo de respuesta de cada intento fallido de inicio de sesión. Registre todos
los fallos y avise a los administradores cuando detecten ataques de fuerza bruta.

16
RIESGOS Y SUGERENCIAS DE
A2:2017
 Expone Session Ids en las URL, no la invalida correctamente o no la rota satisfactoriamente
luego del cierre de sesión o de un periodo de tiempo determinado.

17
EJEMPLOS DE ESCENARIOS
DE ATAQUE
 Escenario 1: relleno automático de credenciales y el uso de lista de contraseñas conocidas son
ataques comunes. Si una aplicación no implementa protecciones automáticas, podrían
utilizarse para determinar si las credenciales son válidas.
 Escenario 2: la mayoría de los ataques de autenticación ocurren debido al uso de contraseñas
como único factor. Las mejores prácticas requieren la rotación y complejidad de las
contraseñas y desalientan el uso de claves débiles por parte de los usuarios. Se recomienda a
las organizaciones utilizar las prácticas recomendadas en la Guía NIST 800-63 y el uso de
autenticación multi-factor (2FA).
 Escenario 3: los tempos de vida de las sesiones de aplicación no están configurados
correctamente. Un usuario utiliza una computadora pública para acceder a una aplicación. En
lugar de seleccionar logout, el usuario simplemente cierra la pestaña del navegador y se aleja.
Un atacante usa el mismo navegador una hora más tarde, la sesión continúa activa y el usuario
se encuentra autenticado.

18
EXPERIENCIA PROPIA
Los problemas descritos en el A2:2017 se pueden atacar de la siguiente manera:
 Política de contraseñas seguras:
 Los usuarios deben crear contraseñas de, al menos, 12 caracteres; debe incluir minúsculas y
mayúsculas, números, y caracteres especiales.
 Las contraseñas no deberían contener el nombre de usuario, ni el nombre del usuario, su documento
de identidad y, de ser posible, su fecha de nacimiento.
 Rotación de contraseñas:
 Una política de vencimiento de contraseñas cada 60 días.
 El usuario no debería poder reutilizar contraseñas.

19
EXPERIENCIA PROPIA
 Manejo de sesiones:
 Cerrar la sesión automáticamente cuando se detecte más de 10 minutos de inactividad.
 Pedirle al usuario que confíe en el equipo en el cual inicia sesión. Esta verificación se puede hacer por
correo electrónico, en caso de que el usuario no verifique el equipo, se debe cerrar la sesión.
 Inicio de sesión:
 Se debería solicitar al usuario que además de ingresar su usuario y contraseña, utilice autenticación
multi-factor tales como un token enviado por correo/SMS y una herramienta de autenticación como
las ofrecidas por Microsoft o Google.
 Notificar al usuario por el canal de preferencia (correo, SMS, Slack, Whatsapp, etc) cada nuevo inicio
de sesión.

20