OWASP Top 10 2017

Spanish overview of OWASP Top Ten

1. OWASP Top 10 - 2017

The Ten Most Critical Web Application Security Risks
@SuperSerch

2. ¿Qué es OWASP TOP 10?
•Documento que busca crear conciencia de los problemas de seguridad al
desarrollar sistemas
•Basado en más de 40 aportes de firmas de seguridad y una encuesta a
mas de 500 individuos, que representa información de ~100k
aplicaciones
•https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

3. ¿Qué es un riesgo de seguridad?

4. Cambios 2013 - 2017

5. A1 - Injection
•Injecciones en SQL, NoSQL, SO, XML y LDAP ocurren cuando datos no
confiables son enviados a un interprete como parte de una instrucción o
consulta. Un atacante puede utilizar estos datos para engañar al
interprete para ejecutar instrucciones arbitrarias o acceder a datos sin
contar con la autorización adecuada
•Pueden usarse para causar perdida de información, divulgar información
clasificada, negación de servicio, desconfianza en los datos, entre otros

6. A1 - Ejemplo SQL
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
id = "954' or 'a'='a"

7. A1 - Ejemplo SQL
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
PreparedStatement pstmt = conn.preparedStatement(query);

8. A1 - Ejemplo SQL
String query = "SELECT * FROM accounts WHERE custID=?";
PreparedStatement pstmt = conn.preparedStatement(query);
pstmt.setInt(1, 954)
ResultSet rs = pstmt. executeQuery();

9. A1 - Ejemplo NoSQL
db.users.find({username: username, password: password});
{
"username": {"$gt": ""},
"password": {"$gt": ""}
}

10. A1 - Mitigación
•Evitar usar los interpretes, para el caso de SQL equivale a usar queries
parametrizados (preparedStatement)
•Sanitizar las entradas
•https://www.owasp.org/index.php/
OWASP_Java_HTML_Sanitizer_Project
•https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

11. A2 - Broken Authentication
•Problemas al identificar adecuadamente al usuario, guardar contraseñas
en claro, cifradas o con digestiones de baja seguridad; debilidad en el
manejo de sesión, no evitar ataques de fuerza bruta, exponer los
identificadores de sesión en el URL
•Al impersonar a un usuario o administrador, todo el sistema está
comprometido

12. A2 - Mitigación
•Usar autenticación de dos factores
•Obligar a rotación de contraseñas con un cierto nivel de complejidad
•Tener timeouts en las sesiones de usuario
•Limitar o contar con retrasos incrementarles tras cada fallo de
autenticación
•Generar un nuevo identificador de sesión al autenticar al usuario, basado
en un buen algoritmo de aleatoriedad que sea seguro y use alta entropia

13. A3 - Sensitive Data Exposure
•Exponer datos sensibles (financieros, de salud, de identificación personal)
puede facilitar a un atacante realizar otro tipo de daños como robo de
identidad y fraudes crediticios
•Los datos sensibles deberían viajar y almacenarse siempre cifrados, y
tener precauciones extras antes de mostrarlos (reautenticación)
•Las contraseñas se deben almacenar digeridas y con SALT
•GDPR

14. A4 - XML External Entities (XXE)
•Es posible instruir a procesadores de XML a procesar entidades externas
mediante las cuales es posible hacer una inyección o extraer información
•Cualquier sistema que recibe XML (SOAP, SAML) puede ser vulnerable a
elementos como: <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

15. A4 - Mitigación
•Siempre que sea posible usar formatos de datos más simples (JSON,
protobuf)
•Tener actualizados todos los componentes que procesen XML
•Validar lo que se recibe contra una lista blanca de tags aceptados
•Deshabiltar el procesamiento de entidades externas y DTDs en los
procesadores de XML

16. A5 - Broken Access Control
•No se tienen las restricciones adecuadas de que es lo que un usuario
tiene permitido ver o hacer
•Se pueden realizar acciones no autorizadas, acceder a información de
otros usuarios o incluso alterarla
•http://example.com/app/accountInfo?acct=notmyacct
•http://example.com/app/getappInfo 

http://example.com/app/admin_getappInfo

17. A5 - Mitigación
•No permitir acceso a nada, excepto recursos públicos
•Contar con un único mecanismo de acceso y reusarlo en toda la
aplicación
•Limitar el acceso a llamadas a APIs por tiempo
•No pasar datos de identidad como parámetros o URL

18. A6 - Security Misconfiguration
•Es el resultado de configuraciones inseguras por defecto, configuraciones
incompletas o ad hoc, uso inapropiado de elementos de computo en la
nube, encabezados HTTP mal configurados y mensajes de error que dan
demasiada información al visitante
•No sólo es necesario configurar adecuadamente todos los Sistemas
Operativos, Firewalls, Bibliotecas y Aplicaciones, además se requiere
tenerlos actualizados prontamente

19. A6 - Mitigación
•Contar con un proceso REPETIBLE de hardening, de preferencia
automatizado
•Instalar lo mínimo necesario
•Contar con una tarea periodica de monitorear y actualizar los
componentes utilizados por vulnerabilidades conocidas
•Cuando se tienen tenants, contar con la adecuada separación de
servicios, de preferencia en diferentes hosts

20. A7 - Cross-Site Scripting (XSS)
•Ocurre cuando se permite que datos no confiables se incluyen en una
página web si escaparlos o realizar la validación/sanitización adecuada
•Un atacante puede ejecutar scripts en el navegador de la víctima, con lo
que puede secuestrar sesiones, alterar sitios web o redireccionar al
usuario a sitios maliciosos
•Tipos: Reflected, Stored & DOM

21. A7 - Contextos de Ejecución
•Cuerpo del HTML <div><%= request.getParameter("name") %></div>
•Atributos de HTML <input type="text" value="<%= dato %>">
•JavaScript <script> name = <%= nombre %> ; … </script>
•CSS <style> <%= color %>…</style>
•URL <a href="<%= parameter %>">Click</a>

22. A7 - Mitigación
•Usar frameworks y template engines que automáticamente escapen datos
•Escapar HTML de acuerdo al contexto en que se coloque los datos no
confiables
•Si se requiere recibir html desde una página, validar todos los tags contra
una lista blanca de elementos permitidos
•https://www.owasp.org/index.php/
XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

23. A8 - Insecure Deserialization
•El proceso de serialización/deserialización es muy complejo, si un
atacante puede alterar el flujo de datos puede alterar información o
ejecutar código al construir objetos con clases existentes
•Se incluyó a solicitud de la comunidad, es muy complejo realizar este tipo
de ataques por lo que existían muy pocos sitios que fueron vulnerados
por deserialización
•*Serialización de Lambdas

24. A8 - Mitigación
•Agregar checksums de seguridad a los streams de datos
•Asegurar que solo se puedan deserializar un grupo de clases específicas
•Aislar y correr con mínimos privilegios el código que deserializa

25. A9 - Using Components with Known
Vulnerabilities
•Componentes de software como bibliotecas, frameworks y similares
corren con los mismos privilegios que la aplicación que los contiene, si
estos tienen vulnerabilidades, estas pueden ser muy conocidas y poner
en riesgo la aplicación que los usa
•Struts 2.0 CVE-2017-5638
•Hearbleed
•Mirai Botnet

26. A9 - Mitigación
•Quitar dependencias no usadas, componentes innecesarios, ejemplos
•Tener un inventario de todas las dependencias con numero de versión
•Sólo obtener componentes de fuentes confiables
•Monitorear dependencias por si se encuentra una vulnerabilidad en ellas
https://www.owasp.org/index.php/OWASP_Dependency_Check

27. A10 - Insufficient Logging & Monitoring
•Sin el adecuado monitoreo y registro de eventos, un ataque podría pasar
desapercibido
•logs se guardan sólo de manera local
•No existen logs de eventos auditables como accesos correctos y fallidos,
transacciones de alto valor

28. A10 - Mitigación
•Asegurar que todas las fallas de acceso, y validación del lado del servidor se
registran con suficiente información de contexto para poder analizarlos
•Usar sistemas de centralización de Logs
•Asegurar que transacciones de alto valor cuenten con un camino auditable
con controles de integridad para evitar alteraciones o borrado de las mismas
•Contar con alertas y monitoreo que reporte las actividades sospechosas
para que se pueda actuar a tiempo
•Contar con un plan de respuesta a incidentes y recuperación de desastres
como NIST 800-61 rev 2

29. Gracias