El documento analiza las herramientas disponibles para automatizar la seguridad de aplicaciones web durante el ciclo de desarrollo de software. Describe diferentes tipos de herramientas como análisis estático de código, dinámico y en tiempo real, así como híbridas. Además, compara el rendimiento de diversas herramientas populares y concluye que la combinación de múltiples herramientas proporciona los mejores resultados.

1. Análisis de herramientas disponibles para
automatizar el análisis de la seguridad de una
aplicación WEB durante el ciclo de vida de
desarrollo de software (SDLC)
[Fuente: informe VERACODE volumen 3]
22/10/2012 Juan Ramón Bermejo Higuera

2. EVOLUCIÓN DE LOS VECTORES DE ATAQUE
 1980,s - Physical
 1990,s - Network
 2000,s - E-mail, Application and Wireless
 2010 - Client-Side, Mobile and Social
Networking
[Fuente: TRUST WAVE REPORT 2011]
22/10/2012 Juan Ramón Bermejo Higuera

3. [Fuente: TRUST WAVE REPORT 2011]
22/10/2012 Juan Ramón Bermejo Higuera

4. [Fuente: TRUST WAVE REPORT 2011]
22/10/2012 Juan Ramón Bermejo Higuera

5. [Fuente: IBM RISK AND TREND REPORT 1 MID 2012
22/10/2012 Juan Ramón Bermejo Higuera
]

6. [Fuente: IBM RISK AND TREND REPORT 1 MID 2012
22/10/2012 Juan Ramón Bermejo Higuera
]

7. [FUENTE: informe VERACODE volumen 4 DATOS de 2011-2012]
22/10/2012 Juan Ramón Bermejo Higuera

8. [FUENTE: informe VERACODE volumen 4 DATOS de 2011-2012]
22/10/2012 Juan Ramón Bermejo Higuera

9.  J2EE
 .net
 C/C++
 PHP
 ColdFusion
 ANDROID
[FUENTE: informe VERACODE volumen 4 DATOS de 2011-2012]
22/10/2012 Juan Ramón Bermejo Higuera

10. OWASP TOP TEN
http://www.owasp.org/index.php/Top_10
22/10/2012 Juan Ramón Bermejo Higuera

11. [FUENTE: informe VERACODE volumen 4 DATOS de 2011]
22/10/2012 Juan Ramón Bermejo Higuera

12. Cross Site Scripting (XSS) se materializa cuando se dan estos dos
pasos:
 Los datos entran a la aplicación a través de entradas no validadas
como una petición HTTP.
 La aplicación incluye los datos en un contenedor dinámico que se
envía al navegador Web del usuario sin la apropiada validación de
contenido malicioso.
La variedad de ataques basados en XSS es casi ilimitada, pero
comúnmente incluye transmisión de datos privados como cookies u
otra información de sesión al atacante o redirigir la víctima a un
contendor Web que el atacante controla
22/10/2012 Juan Ramón Bermejo Higuera

13.  Los atacantes pueden modificar el
comportamiento normal del navegador usando
un cliente de ataque que permite modificar
cualquier petición HTTP
 Los atacantes buscan patrones en URLs, campos
ocultos y valores de cookies, comentarios en una
petición-respuesta HTML, manipulan
parámetros URL o realizan ingeniería inversa de
código JavaScript
22/10/2012 Juan Ramón Bermejo Higuera

14.  Los programadores, confían de forma equivoca, en los valores
transmitidos en cookies, campos ocultos y cabeceras HTTP
 Validación de los campos de entrada y salida. Tratar al cliente
como si no existiera. No permitir que el cliente almacene secretos
o que realice ningún tipo de validación, efectuando validación de
entrada y salida en el lado del servidor.
 Mantenimiento del estado de sesión. Crear fuertes identificadores
de estado de sesión, limitar el tiempo de vida de la sesión
 Usar marcos de trabajo que usen mecanismos de validación
incorporados, pensando en la seguridad, como puedes ser Apache
Struts.
22/10/2012 Juan Ramón Bermejo Higuera

15.  SAST – análisis estático código fuente
ejecutable.
 DAST – análisis dinámico.
 RAST – análisis en tiempo real.
 HÍBRIDAS ( sast – dasd / sast –rast /
sast-dasd- rast)
22/10/2012 Juan Ramón Bermejo Higuera

16. 22/10/2012 Juan Ramón Bermejo Higuera

17.  Analizan todo el código
 Falsos negativos / falsos positivos
 Grados de usabilidad distintos
 Requieren auditoria posterior
 Detecciones 41 - 81%
 Falsos positivos 21 – 78 %
 Correlación 2 tools  93 % detecciones
22/10/2012 Juan Ramón Bermejo Higuera

18.  Fortify SCA.
 Checkmarx Cx.
 Klocwork inshight.
 Veracode (SaaS).
 Lapse+. (lab. Evalues . U.Carlos III)
 Findbugs. (open source)
*[Fuente: Gartner magic cuadrant]
22/10/2012 Juan Ramón Bermejo Higuera

19.  Tipo de caja negra  test de penetración
 Problemas para testear toda la aplicación
 Limitadas a un subconjunto de vulnerabilidades:
 Problemas con: SESSION HIJACKING or INFORMATION LEAKAGE
 Falsos positivos  auditoría posterior
 Aprendizaje y prueba de vulnerabilidades en runtime
22/10/2012 Juan Ramón Bermejo Higuera

20. 22/10/2012 Juan Ramón Bermejo Higuera

21.  XSS.
 SQLI.
 PATH TRANSVERSAL.
 COMMAND INJECTION.
 DEFECTOS DE CONFIGURACIÓN.
 PROBLEMAS RELACIONADOS CON JAVASCRIPT.
 FILE INCLUSION.
 XPATH INJECTION.
 HTTP RESPONSE SPLITING.
22/10/2012 Juan Ramón Bermejo Higuera

22. *[Fuente: Gartner magic cuadrant]
 Hp Webinspect
 IBM Appscan
 Acunetix
 Whitehat
 Ntospider
 Cenciz
 Parasoft
22/10/2012 Juan Ramón Bermejo Higuera

23.  Tipo de caja BLANCA. Actúan directamente sobre el
código ejecutable, observando el entorno de
ejecución de los procesos peticiones y respuestas a la
aplicación.
 No tienen falsos positivos.
 Pueden incidir en el rendimiento de la aplicación.
22/10/2012 Juan Ramón Bermejo Higuera

24.  El análisis dinámico RAST es preciso, no necesita hacer
abstracciones y puede ser tan rápido como la propia
ejecución del programa excepción hecha de las
comprobaciones adicionales que tiene que realizar.
 Las comprobaciones se pueden optimizar en gran
medida mediante el background de SAST para proteger
una aplicación web en tiempo real desplegada en
producción.
22/10/2012 Juan Ramón Bermejo Higuera

25.  Generar un informe, después de la detección sin más.
SECURITYSCOPE de Fortify es un ejemplo de este tipo.
También ACUSENSOR, como funcionalidad añadida a
ACUNETIX
 Bloquear el intento de ataque, como hace RTA de Fortify.
RTA presenta muchas similitudes en cuanto a arquitectura.
Difieren en el concepto de lo que se hace cuanto se
detecta una vulnerabilidad: bloqueo o informar.
 Sanear la petición maligna a la aplicación web, corrigiendo
los valores de entrada a la aplicación. SANER es un ejemplo
de este tipo [Balzarotti et Co. 2008].
22/10/2012 Juan Ramón Bermejo Higuera

26. 22/10/2012 Juan Ramón Bermejo Higuera

27.  SecurityScope (HP FORTIFY)  informa
 RTA ( HP FORTIFY)  bloquea
 Glassbox (IBM) (java solo)  informa
 Securfly (livishs)  bloquea, informa o “sanea” la
entrada
 Quotium Technologies  test cases para java
.net y PHP
22/10/2012 Juan Ramón Bermejo Higuera

28.  SAST – DAST (Veracode SaaS)
 SAST – RAST ( jnuke – securfly - amnesia ) (java)
 DAST – RAST (Acunetix + Acusensor) (php, .net)
 SAST- DAST - RAST (Fortify 360) (IBM Appscan)
22/10/2012 Juan Ramón Bermejo Higuera

29. TOOL PRECISIÓN RECALL FP F-MEASURE
TP/TP+FP TP/TOTAL 2xPRECISIONxRECALL
VUL. / PRECISION+RECALL
FORTIFY SCA 0,346 0,740 0,653 0,471
LAPSE + 0,326 0,805 0,788 0,464
KLOCWORK 0,362 0,545 0,450 0,435
CHECKMARX 0,321 0,653 0,575 0,430
VERACODE 0,460 0,400 0,195 0,427
FINDBUGS 0,410 0,105 0,067 0,167
22/10/2012 Juan Ramón Bermejo Higuera

30. CORRELACIÓN DE RESULTADOS ENTRE PAREJAS DE
HERRAMIENTAS,
154 CASOS DE TEST
CHECKMARX – LAPSE+ 142
LAPSE+ – KLOCWORK 139
FORTIFY SCA - LAPSE+ 133
FORTIFY SCA - KLOCWORK 130
FORTIFY SCA - CHECKMARX 127
CHECKMARX – KLOCWORK 123
22/10/2012 Juan Ramón Bermejo Higuera

31.  GRUPO I.
 % VP (Detecciones Correctas)  > 80 %
 % FP (Detecciones Incorrectas)  4 herramientas > 50 %  auditoría obligatoria.
 Combinación 2 herramientas  92%.
 Combinación de 4 herramientas  95 %
 GRUPO II.
 No se detectan 30 vulnerabilidades de 62 posibles.
 16 de 32 categorías no cubiertas por 5 de las herramientas evaluadas.
22/10/2012 Juan Ramón Bermejo Higuera

32. 22/10/2012 Juan Ramón Bermejo Higuera

33. Fuente:
Veracode
report, volumen
4
22/10/2012 Juan Ramón Bermejo Higuera

34. 22/10/2012 Juan Ramón Bermejo Higuera