Los problemas de seguridad a nivel aplicación podemos organizarnos en 2 tipos de problemas: Security Bugs o Bugs de Sintaxis y Business Logic Flaws, conocidos también como Design Flaws. El primer tipo de riesgo, que incluye entre otros 2 de los problemas más conocidos como SQL Injection o XSS, está basado en bugs de programación que afortunadamente pueden ser detectados mediante herramientas AST (Application Security Testing) de forma automática reportando el fichero y la línea del problema. A pesar de esta ventaja, el resto de los problemas que podemos englobar dentro de la categoría de Business Logic Flaws que representan aproximadamente el otro 50% del problema, no pueden ser detectados por las soluciones AST. Los problemas de seguridad de tipo Business Logic Flaws son problemas relacionados con el dominio de la aplicación que actualmente son detectados mediante procesos de pen-testing de forma manual y su resolución en muchos casos implica un rediseño completo de las aplicaciones. El objetivo de este charla es la presentación de un enfoque de protección de los business logic flaws integrado dentro del SDLC, junto con mecanismos para la automatización del proceso de pen-testing de este tipo de riesgos. Siguiendo un enfoque práctico, dentro de la charla haremos uso de aplicaciones de referencia dentro del ecosistema de Spring como PetClinic (Spring MVC y REST) y de herramientas de auditoría como Burp Suite.

1. Protection and Verification
of Business Logic Flaws
XI OWASP Spain Chapter Meeting

2. Roberto Velasco
Seguridad Software
desde 2001
Arquitectura Software
desde 2004
Fundador Proyecto
Open-Source Hdiv
CEO
en Hdiv Security
Sobre mí

3. Índice
1. Security Bugs & Business Logic Flaws
2. Explotación - Business Logic Flaws
3. Protección - Business Logic Flaws
4. Limitaciones en la automatización de la protección
5. Verificación – Business Logic Flaws
6. Recomendaciones

4. Security Bugs &
Business Logic Flaws
XI OWASP Spain Chapter Meeting

5. Security bugs
• Errores de seguridad que siguen un patrón concreto,
común en todas las aplicaciones
Ejemplos: SQL Injection,XSS, etc.
• Pueden ser detectados por herramientas AST
(Application Security Testing)
• El ataque para explotar estos problemas sigue
habitualmente patrones conocidos

6. Business Logic Flaws o Design Flaws
• No siguen un patrón común y dependen de cada
dominio o negocio
Ejemplos: Control de acceso, Binding, Alteración de workflow,
etc.
• No detectables por herramientas AST
• Los ataques para explotar estos problemas no
tienen forma de ataque

7. • Unauthenticated Web Service
• Encryption key stored next to
data
• Step N of workflow can be
skipped
• Race condition
• Fail-open logic
• User X can edit thing Y
50%
• SQL Injection
• Cross Site Scripting
• XML Attacks
• Directory Traversal
• Weak Crypto Algorithm
• Java Object Deserialization
• Other use of known bad API
50%
Security bugs vs. Business Logic Flaws
Business Logic FlawsSecurity Bugs

8. • Soluciones AST adecuadas para
la detección
• La industria en ciberseguridad
se ha centrado en la protección
de este tipo de riesgos (WAF y
ahora RASP)
Seguridad – Estado del Arte
• No se pueden detectar por AST
• Los WAFs más avanzados están
basados en procesos de
aprendizaje.
• Problemas:
• Costo de implantación
• Falsos positivos
• No todo se puede aprender, existen
cambios en tiempo real
Business Logic FlawsSecurity Bugs

9. Estado del Arte - Gartner
All of the AST tools share significant
weakness in the area of detecting
business logic flaws as well as more
deliberate, malicious flaws like logic
bombs and back doors.
Reliance on positive security models
(whitelists or policies derived from
automatic web application behavior
learning engines) in prevention mode
and automatic deployment of virtual
patches are rare.Gartner, A Guidance Framework for Establishing and
Maturing an Application Security Program, 23 December
2016. Gartner Foundational
AST WAF

10. Cómo Explotar los
Business Logic Flaws
XI OWASP Spain Chapter Meeting

11. Cómo explotar los Business Logic Flaws
• Modificar los valores de los parámetros
• Eliminar/Añadir parámetros
• Intentar consumir nuevas URLs
• Manipular el tiempo y el estado
• Actualizar cookies
• Añadir nuevas cabeceras
• etc.
Veamos algunos ejemplos reales…

12. Casos reales basados en modificación del contrato
Ejemplo Técnica de ataque Descripción
CSRF
OWASP A8 2013
Usuarios de ebay realizaban pujas
inconscientemente
Insecure Direct Object Reference
OWASP A4 2013
Tampering del identificador de usuario
en servicio web, pudiendo acceder a la
cuenta de otro usuario
Binding
OWASP ASVS
V5 Malicious input handling
Cabecera adicional añadida a la petición
con valor “localhost”, consiguiendo
acceder como Administrador
Binding
OWASP ASVS
V5 Malicious input handling
Parámetro extra añadido a un formulario
que permitía suplantar la identidad de
otra persona
Broken Access Control
OWASP A5 2017
Exposición involuntaria de los métodos
HTTP
JMX Console

13. Demo
Manipulación de parámetros:
el usuario X accede a Y
Binding
URL Tampering
1
2
3
https://hdivsecurity.com/videos/owasp-spain-demo

14. Cómo protegerse de los
Business Logic Flaws
XI OWASP Spain Chapter Meeting

15. • Librerías de Seguridad: Spring Security, Java EE, etc.
• Código propietario
Cómo protegerse de los Business Logic Flaws
mediante enfoques tradicionales

16. • Problemas particularmente complejos para resolver
con soluciones tradicionales:
• Domain ACL o seguridad a nivel registro
• Binding (añadir o eliminar parámetros)
• Problemas de workflow: rompiendo el flujo normal de
navegación
Cómo protegerse de los Business Logic Flaws
mediante enfoques tradicionales

17. ¡ No funciona en la práctica !
• Las estadísticas de seguridad muestran que casi todas las
aplicaciones tienen al menos una vulnerabilidad
crítica
• Incluso las grandes empresas tienen estos problemas
(Apple, Github, Stack Overflow, etc.)
• Los pen-testers lo confirman

18. Origen del problema
• Todo está abierto por defecto
• Debemos proteger la aplicación manualmente
haciendo uso de librerías o código propietario
• La seguridad depende de las personas

19. Debemos automatizar la protección
No podemos automatizar la protección para el 100%
de los business logic flaws, pero podemos automatizar
al menos una parte significativa de ellos.

20. • Ataques de manipulación de contrato
• El cliente modifica, añade o elimina algún tipo de dato en
la petición (request)
• Ataques de abuso del contrato
• El ataque respeta el contrato
• El cliente hace un uso malicioso o abusivo del
contrato
Tipos de ataques – Business Logic Flaws

21. Datos No Editables
Datos Editables
View: OR
Showing 1 – 15 of 24 items
Title Author
Amazon Elastic Compute Cloud (EC2) Getting
Started Guide
Amazon Web Services
Purchased: May 11, 2017:
Price: $0.00
Order Details
View Product Page
GO

22. Petición
Respuesta
Petición rechazada
Filtro
Extensión de Frameworks
Web y Librerías de APIs
Petición
válida
Lógica de
Negocio
1
2

23. Demo
Manipulación de parámetros:
el usuario X accede a Y
1
2
3 Binding
URL Tampering4
Instalación de Hdiv
https://hdivsecurity.com/videos/libraries-installation
https://hdivsecurity.com/videos/owasp-spain-demo-protected-by-hdiv

24. Casos reales basados en modificación del contrato
Ejemplo Técnica de ataque Protegido Cómo ha sido protegido
CSRF
OWASP A8 2013
Sí
Añadimos un token aleatorio a cada URL. El
atacante no conoce el valor de este
parámetro
Insecure Direct Object
Reference
OWASP A4 2013
SÍ
El servidor detecta ataques de integridad
contra datos en servidor
Binding
OWASP ASVS
V5 Malicious input handling
NO
Se trata de una header que proviene de
client-side
Binding
OWASP ASVS
V5 Malicious input handling
SÍ
El servidor controla los parámetros válidos
durante el binding
Broken Access Control
OWASP A5 2017
SÍ
El servidor define qué está permitido,
rechazando el resto. Por defecto todo es
GET
JMX Console

25. Limitaciones de la
proteccion frente a
Business Logic Flaws
XI OWASP Spain Chapter Meeting

26. Limitaciones de este método
• Las cajas de texto permiten texto libre
• Ataques de abuso del contrato
• 1000 peticiones por segundo a una operación con acceso
• Ataques relacionados con estado y tiempo
• Ejemplo:
1. Disponemos de un carrito en un e-commerce
2. Pasamos a pagar el pedido en PayPal
3. Actualizamosel carrito con productosmás caros
4. Pagamos, obteniendo un pedido con más productos al precio anterior

27. Verification
(Burp Suite Extension)
https://hdivsecurity.com/videos/verification

28. Recomendaciones
XI OWASP Spain Chapter Meeting

29. Recomendaciones
1. Hacer uso de soluciones AST para la detección de
security bugs (SQL Injection, XSS, etc.)
2. Integrar la protección frente a los Business Logic Flaws
en la Arquitectura (SDLC)
3. Realizar un pen-testing manual para la detección de
posibles problemas pendientes

30. Ruegos & Preguntas
XI OWASP Spain Chapter Meeting
Roberto Velasco
roberto@hdivsecurity.com