Taller ofrecido por Gastón Marichal y Marcos Manicera (ambos de Uruguay) durante la 3ra edición del Argentesting 2018 En este taller discutiremos por qué es importante verificar la seguridad y cómo se pueden incorporar tareas de seguridad dentro del testing funcional. Presentaremos cómo se relaciona la seguridad con la lógica de negocio, tan conocida por los testers y qué aspectos deberíamos verificar para disminuir los posibles puntos de vulnerabilidad de la misma. El taller tiene como objetivo presentar un enfoque de pruebas funcionales relacionado a verificar ciertos aspectos de seguridad de nuestros sistemas. Basado en las guías del OWASP, en el taller se muestran que posibles vulnerabilidades relacionadas a la lógica de negocios que de no ser controladas, podría generar grandes problemas de seguridad. Conocimientos previos requeridos Conocimientos básicos de desarrollo de software como HTML, HTTP, Arquitectura básica de sistemas. Conocimiento básico de testing. Requerimientos Este taller no requiere computadora. Gastón Marichal https://www.linkedin.com/in/gmarichal/ Marcos Manicera https://www.linkedin.com/in/mmanicera/

3. HABLEMOS DE SEGURIDAD

8. INTRODUCCIÓN

9. Introducción - Objetivos
Poner a prueba los mecanismos de seguridad de la
aplicación y su adecuación con estándares y buenas
prácticas de seguridad.
Disminuir la cantidad de vulnerabilidades de seguridad
que llegan a producción.

11. ¿Por qué en testing?
• Incorporar otro nivel de seguridad en etapas
tempranas.
• Si llega a Producción, ya es demasiado tarde.
• Cuanto antes se detecte, menor será el costo de arreglo
• La seguridad no es solo tarea de hackers

12. ¿Por qué en testing?
• Está relacionado con el testing funcional de la aplicación (conocido
por el tester).
• Se tiene acceso a la documentación y características del sistema
fácilmente.
• Se tiene un mayor conocimiento de la aplicación.
• Se realizar de forma controlada en ambientes de test y pre-
producción.

13. ¿Cómo lo haremos?
Incorporando:
• Test funcional de seguridad como una actividad dentro
del ciclo de testing en mis aplicaciones
Pruebas de abuso

14. Pruebas de abuso
• Utilizar las funcionalidades de la aplicación de una
manera no pensada.
• Se busca manipular las reglas de negocio, para
obtener un beneficio.
• Explotar controles deficientes y cursos alternativos no
pensados.

15. Consideraciones
• No es un test de seguridad completo.
– Se enfoca únicamente en las funcionalidades
• No suplanta a un test de penetración.
– El test de penetración es otra barrera de seguridad necesaria

16. Organización del seminario
En este taller vamos a:
• Debatir sobre aspectos de seguridad
• Mostrar casos de abuso sobre una aplicación web y ejemplos de
posibles vulnerabilidades
• Brindar recomendaciones y buenas prácticas de seguridad para
nuestras aplicaciones

17. Tabla de contenido
Manejo de
Sesiones
Lógica de
Negocio
Control de
Acceso
Despliegue

18. Manejo de Sesiones

19. Manejo de sesiones
Inicio de sesión
Gestión de contraseñas
Actualización de los datos Gestión de la sesión

20. Inicio de Sesión
Mecanismo por el cual el sistema valida que la entidad es
quien dice ser.
Distintas formas:
– Algo que conozco - Usuario / Password
– Algo que poseo - Certificado Digital / Access Key
– Algo que soy - Biometría

21. Inicio de Sesión - Buenas prácticas
Nombres de usuario no deben diferenciar mayúsculas y
minúsculas.

22. Inicio de Sesión - Buenas prácticas
Evitar enumeración de usuarios
¿Qué deduzco de estos dos mensajes?

23. Inicio de Sesión - Buenas prácticas

24. Inicio de Sesión - Buenas prácticas
Evitar este tipo de mensajes:
"Login for User failed: invalid password"
"Login failed, invalid user ID"
"Login failed; account disabled"
"Login failed; this user is not active"

25. Inicio de Sesión - Buenas prácticas
Bloquear usuarios tras varios intentos fallidos.
– Bloquear temporalmente la cuenta
• Tiempos incrementales (20 seg, 1 min, 5 min)
– Bloquear la sesión si continúan los intentos.
– Agregar Captcha en la pantalla tras varios intentos del
usuario.
– Estos controles deben estar del lado del servidor.

26. Inicio de Sesión - Buenas prácticas
Mantener un log de cada intento de autenticación
fallida.
– Almacenando:
• IP Origen
• Usuario utilizado
• Resultado

27. Inicio de Sesión - Buenas prácticas
Evitar credenciales por parámetro y credenciales en texto
claro.

28. Inicio de Sesión
DEMO
Inicio de sesión forzoso
- Evitar enumeración de usuarios
- Bloquear tras n intentos fallidos
- Realizar controles en el servidor

29. Gestión de las contraseñas
Fortaleza de las contraseñas:
• Una contraseña se considera fuerte cuando es difícil de
adivinar por medio de un atacante.
• Deben estar alineada a los requerimientos del
proyecto/sistema.

31. Gestión de las contraseñas
Fortaleza de las contraseñas
– Largo (mínimo y máximo)
– Juegos de caracteres (a-z,A-Z,0-9, especiales)
– Periodo de validez
– Histórico
– Etc.

32. Gestión de las contraseñas
Recuperación de la contraseña
• Enviar un token utilizando otro canal.
– E-mail, sms, etc.
– Válido por única vez, por cierto tiempo.
• Cambio de la contraseña o creación de una nueva no predecible.
– La contraseña no debe ser recuperable.

33. Gestión de las contraseñas
Recuperación de la contraseña
• No bloquear el login del usuario.
• Bloquear la sesión web tras varios intentos fallidos.
• No pedir nuevo email.
– Enviar al mail que tiene registrado el usuario.

34. Gestión de las contraseñas
Recuperación de la contraseña
• Evitar el uso de las Preguntas Secretas.
– Actualmente son muy fáciles de obtener
– Información del usuario:
• Redes sociales
• Página de la empresa
• Ingeniería Social

35. Gestión de las contraseñas
DEMO
Recuperación de la contraseña:
Si es posible adivinar una preguntas secretas, entonces
no es segura!
“Equipo favorito de futbol”
“Ciudad de Nacimiento”
“Apellido de la madre”
“Nombre de la primer mascota”

36. Gestión de las contraseñas

38. Actualización de los datos – Buenas practicas
Siempre se debe pedir contraseña para confirmar cambios de:
– Username
– E-mail
– Password
Ya que son utilizados para:
– Iniciar sesión.
– Recuperar contraseña.
– Notificar los cambios.

39. Actualización de los datos – Buenas practicas
Notificar dicho cambio al usuario:
– Email (original)
– Sms
– Llamada

40. Gestión de la sesión.
• Proceso por el cual el servidor conserva el estado de una entidad
con la cual está interactuando.
• Almacenadas en el servidor utilizando un identificador de sesión,
que deben ser únicos por usuario y difíciles de predecir.
• Enviado entre el cliente y el servidor en cada pedido y respuesta.

41. Gestión de la sesión.

42. Gestión de la sesión.
Evitar fijación de
sesión

43. Gestión de la sesión.
Cierre de sesión:
– Logout: Manual al salir del sistema
– Expiración: Automática, luego de un tiempo determinado de
inactividad.
– Destruir sesión en el servidor

44. Gestión de la sesión.
DEMO
Cierre de sesión: Logout manual
Verificar mecanismos de destrucción de sesiones, si estos
Faltan/Fallan la sesión puede no cerrarse y permitir que otros
usuarios operen bajo mi sesión.

45. Gestión de la sesión.

46. Gestión de la sesión.

47. Gestión de la sesión.
DEMO
Cierre de sesión: Robo de sesión
Ingresar con la misma sesión de un usuario autenticado,
aunque haya cerrado sesión.

48. LÓGICA DE NEGOCIO
https://www.owasp.org/index.php/Testing_for_business_logic#Business_Logic_Test_Cases

49. Lógica de Negocio - Definición
• Son las reglas mediante las cuales se rige el sistema.
• Conformado por las funcionalidades del sistema.
• Es única para cada aplicación.
• Documentada en casos de uso.

50. Lógica de Negocio - Explotación
Se necesita pensar diferente
– Fuera del uso convencional del sistema
– Utilizar la creatividad y experiencia
Es un trabajo manual
– Difícil de automatizar
– Requiere conocer el sistema, sus reglas y procedimientos de
negocio (Documentación)

51. Lógica de Negocio - Atacante
¿Qué busca un atacante?
• Intentar explotar la lógica del negocio
• Obtener ventajas/beneficios extras
• Aprovechar funcionalidades/controles deficientes

52. Lógica de Negocio - ¿Qué hacer?
• Debemos pensar como un atacante
• Conocer el software y sus características
• Detectar posibles puntos de vulnerabilidad
• Verificarlos ejecutando casos de mal uso o abuso del
software

53. Lógica de Negocio
1. Validación de datos de la lógica de negocio
2. Capacidad para manipular solicitudes
3. Controles de integridad
4. Timing de procesos
5. Limitar uso de funciones (cantidad)
6. Evasión de flujo normal de trabajo
7. Carga de archivos no esperados y/o maliciosos

54. Lógica de Negocio
Validaciones de datos de la lógica de negocio
– El sistema no debe “confiar” en los datos que recibe, un atacante puede
insertar datos lógicamente inválidos
– Los datos pueden ser manipulados durante el proceso
• Etapas de un workflow
• Puntos de comunicación con otros sistemas
• Tráfico HTTP
– Deben existir mecanismos que validen estos datos.

55. Lógica de Negocio
Validaciones de datos de la lógica de negocio
– Con solo verificar los datos en el cliente no es suficiente,
se puede interceptar el tráfico y enviar datos lógicamente
inválidos

56. Lógica de Negocio
Ej.: Validaciones de datos de la lógica de negocio
Sub-sistema de
Compras
Sub-sistema de
Despacho

57. Lógica de Negocio
Validaciones de datos de la lógica de negocio
¿Como probar?
• Detectar los puntos de entrada o comunicación del sistema.
• Realizar un testeo exploratorio ingresando o modificando datos
lógicamente inválidos en el sistema:
– Utilizando la UI.
– Capturando y modificando el tráfico HTTP.
• También revisar comunicación entre sistemas.

58. Lógica de Negocio - Verificación
DEMO
Validaciones de los datos
Realizar una transferencia con otro tipo de moneda

59. Lógica de Negocio - Verificación
DEMO
Validaciones de los datos
Realizar una transferencia con saldos negativos
- 1000

60. Lógica de Negocio
Capacidad para moldear solicitudes
– El atacante puede saltear la GUI y enviar información directamente al
servidor.
– Mediante un proxy se envían peticiones HTTP POST/GET con valores
inválidos para la lógica de negocio
– Incompatibles, no soportados, no esperados
– Se busca poder predecir o adivinar parámetros
– Exponer funcionalidades o pantallas ocultas del sistema.

61. Lógica de Negocio
• Ej.: Capacidad para moldear solicitudes
PurchaseTicket?newUser=1
10% off
PurchaseTicket?newUser=0
10% off
PurchaseTicket?newUser=1

62. Lógica de Negocio
Capacidad para moldear solicitudes
¿Qué debe hacer el sistema?
• Contar con chequeos lógicos en los lugares clave para prevenir que se
acepten este tipo de peticiones.
• Bloquear peticiones que no provengan de un usuario verificado
• Evitar que el sistema delate su propia estructura

63. Lógica de Negocio
Capacidad para moldear solicitudes
¿Como probar?
• Revisar en busca de funcionalidades y campos que puedan ser
predecibles o estar ocultos.
• Observar el tráfico HTTP en busca de valores que sean predecibles o
adivinables (autoincrementales, etc).
• Observar el tráfico HTTP en busca de funcionalidades ocultas como
pantallas de desarrollo o testeo.

64. Lógica de Negocio
DEMO
Capacidad para moldear solicitudes
Consultar estado de cuenta de otros usuarios, cambiando la
información que viaja en la URL.
-
Mediante un proxy, buscar código comentado y acceder a un objeto
de test.

65. Lógica de Negocio
Controles de integridad
– Los campos ocultos o no editables que muestran información
al usuario, pueden ser manipulados en el cliente.
– El sistema no debe confiar en que estos valores no serán
alterados por un usuario.

66. Lógica de Negocio
Controles de integridad
– Si se expone información de negocio al usuario (cantidades,
precios, stock, etc.) , se debe mantener una copia en el servidor
y utilizarla para los procesos.
– Los procesos o funcionalidades no deben depender de estos
valores ocultos o no editables.

67. Lógica de Negocio
Controles de integridad
– ¿Como probar?
• Buscar componentes que manipulen o actualicen información.
• Revisar el tráfico HTTP en busca de campos ocultos o no editables.
• Intentar modificar dicha información con valores inválidos.

68. Lógica de Negocio
Controles de integridad - Recomendación
GUI
Controles
Canal de comunicación
Cliente

69. Lógica de Negocio
DEMO
Controles de integridad
Reducir el porcentaje de recargo de un prestamos,
manipulando la taza de recargo del mismo (GUI).

70. Lógica de Negocio
Timing de procesos
• Identificar funcionalidades del sistema que puedan ser afectadas
por el transcurso del tiempo.
• Obtener ventajas basadas en el tiempo de operación con el
sistema.
– Precios variantes en el correr del día
– Bloquear temporalmente otros usuarios

71. Lógica de Negocio
Ej.: Timing de procesos

72. Lógica de Negocio
Ej.: Timing de procesos
10:00
Price: 100
15:00
Price: 150
20:00
Price: 200

73. Lógica de Negocio
DEMO 9 - Timing de procesos
PENDIENTE

74. Lógica de Negocio
Limitar uso de funciones (cantidad)
– Normalmente los sistemas poseen funciones u operaciones
que deben tener un control sobre la cantidad de veces que se
utiliza.
– Si estos controles no se implementan correctamente, un
usuario mal intencionado podría abusar de algún activo u
operación en el sistema.

75. Lógica de Negocio
Ej.: Limitar uso de funciones (cantidad)
– Reutilizar un descuento.
– Confirmar varias veces una acción.
– Cambiar o Forzar contraseñas.

76. Lógica de Negocio
Limitar uso de funciones (cantidad)
– ¿Como probar?
– Identificar las funciones u operaciones que no deberían ser
ejecutadas más de una cierta cantidad de veces.
– Intentar ejecutarlas más de la cantidad de veces permitidas,
mediante browser o tráfico http.

77. Lógica de Negocio
Limitar uso de funciones (cantidad)
– ¿Como probar?
Ej.: Luego de obtener un “premio”, navegar hacia atrás y
volver a intentarlo.
Ej.: Abrir varias ventanas iguales y realizar la misma
operación en paralelo.

78. Lógica de Negocio
Demo
Limitar uso de funciones (cantidad)
Sobre utilizar un descuento de “primera compra” para
siempre obtener el beneficio.

79. Lógica de Negocio
Evasión del flujo normal de trabajo
– ¿Que es?
– Permite al atacante eludir el flujo normal o esperado de
trabajo.
– No seguir la secuencia normal de operaciones.

80. Lógica de Negocio
Ej.: Evasión del flujo normal de trabajo
– Saltear algún paso del flujo de trabajo donde no se cuenten
con mecanismos de control que dirijan las operaciones hacia
el orden correcto.

81. Lógica de Negocio
Evasión del flujo normal de trabajo
– ¿Como probar?
– Saltear o ejecutar ciertos pasos de la aplicación en un orden
no deseado del flujo lógico.
– Forzar una acción que no es la esperada en esa etapa del
proceso.

82. Lógica de Negocio
Evasión del flujo normal de trabajo
– ¿Como probar?
– Identificar aquellas transacciones en las cuales se maneje
algún activo como puntos o créditos. Cancelar o reducir la
oferta final de cada transacción y verificar que los
puntos/créditos se ajusten correctamente.

83. Lógica de Negocio
Evasión del flujo normal de trabajo
– ¿Como probar?
– Para cada formulario, introducir valores iniciales válidos en
sus campos. Posteriormente intentar editar o eliminar dichos
valores dejando los mismos en un estado inválido y confirmar.

84. Lógica de Negocio
DEMO
Evasión del flujo normal de trabajo
Aceptar un préstamo que aún no fue aprobado.

85. Lógica de Negocio
Carga de archivos no esperados y/o maliciosos
– ¿Que es?
– Verificar cualquier funcionalidad de subida de archivos para
el usuario.
– Al igual que con los datos, el sistema no debe confiar nunca
en estos archivos.

86. Lógica de Negocio
Carga de archivos no esperados y/o maliciosos
– ¿Qué puede ocurrir?
• Un archivo no esperado y trancar la ejecución.
• Un archivo para explotar luego con otra vulnerabilidad (página web,
javascript, .exe)
• Un archivo que al ser parseado/ejecutado realiza acciones indebidas.

87. Lógica de Negocio
Ej.: Carga de archivos no esperados y/o maliciosos

88. Lógica de Negocio
Carga de archivos no esperados y/o maliciosos
– ¿Como probar?
– Ubicar las funcionalidades en las que un usuario puede realizar
la subida de un archivo.
– Diferentes tipos de archivos, archivos maliciosos, múltiples
archivos

89. Lógica de Negocio
Carga de archivos no esperados y/o maliciosos
– ¿Como probar?
– Mantener una lista de archivos aceptables y comparar siempre
contra ella.
– Realizar la subida de archivos indebidos.
– Verificar que los mecanismos de validación prevengan la carga.

90. Lógica de Negocio - Verificación
DEMO
Carga de archivos no esperados y/o maliciosos

91. CONTROL DE ACCESO - ROLES / PERMISOS

92. Control de Acceso
• Es el control selectivo y restrictivo a un recurso.
• La aplicación funciona correctamente.
• Probar quién lo puede hacer.

93. Control de Acceso
1. Ausencia de control de acceso a funciones.
2. Exposición de datos sensibles.
3. Referencia directa insegura a objetos.

94. Control de Acceso
Ausencia de control de acceso a funciones.
– ¿Qué es?
– Un usuario obtiene acceso a funciones privilegiadas que no
debería.
– Se realiza el control de acceso en la interfaz de usuario, pero
no, en la ejecución la acción.

95. Control de Acceso
Ausencia de control de acceso a funciones.
– ¿Como probar?
– La interfaz de usuario la controla el navegador.
– Se debe buscar:
• Botones deshabilitados.
• Botones ocultos.
• Links ocultos.

96. Control de Acceso
DEMO
Ausencia de control de acceso a funciones.
Aprobarse un préstamo, habilitando un botón en la GUI.

97. Control de Acceso
Exposición de datos sensibles.
– ¿Qué es?
– Cierta información puede ser considerada sensible.
• Datos personales, información financiera o laboral.
– Depende de la industria y las regulaciones
gubernamentales.

98. Control de Acceso
Exposición de datos sensibles.
¿Como probar?
Almacenamiento: Logs, archivos intermedios.
– Interfaz: información sensible puede ser enviada al navegador y
estar oculta: Hidden, display = None, etc.
• Cachés intermedios y del navegador:
– chrome://cache o about:cache

99. Control de Acceso
DEMO
Exposición de datos sensibles.
Inspeccionar las transferencias y visualizar el saldo de una
cuenta de terceros.

100. Control de Acceso
Referencia directa insegura a objetos.
– ¿Qué es?
– Exposición de una referencia a un objeto de implementación
interno sin verificar control de acceso
• Archivo, Carpeta, Base de Datos
– Un atacante pueden manipular estas referencias para acceder a
datos no autorizados

101. Control de Acceso
DEMO
Referencia directa insegura a objetos.
Ingresar a un estado de cuenta cambiando los
parámetros en la URL

102. DESPLIEGUE

103. Despliegue
Configuración de seguridad incorrecta:
– Configurar correctamente los Usuarios, roles y permisos que el
sistema tendrá en Producción.
– Revisar y depurar:
• Objetos y roles creados en test.
• Objetos no utilizados u obsoletos (Developer Menu, Objetos viejos, etc.
– Optar por un tráfico HTTPS y URL cifradas

104. Despliegue
DEMO
Configuración de seguridad incorrecta
Acceder a objetos de desarrollo/test que no se
depuraron en producción.

105. Referencias
•OWASP - Testing guide 4.0
https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf
•OWASP - Testing for business logic
https://www.owasp.org/index.php/Testing_for_business_logic
•OWASP - Authentication Cheat Sheet Español
https://www.owasp.org/index.php/Authentication_Cheat_Sheet_Español
•OWASP - TOP 10
https://www.owasp.org/index.php/Top_10_2013-Top_10
•Symantec - Internet Security Threat Report
https://www.symantec.com/content/dam/symantec/docs/reports/istr-22-2017-en.pdf

106. ¿Preguntas?
Marcos Manicera
mmanicera@qalified.com
@marcosmanicera
Gaston Marichal
gmarichal@qalified.com
@gamarichal