Estudio de los ataques contra website. OWASP

(1)

T rabajo F in de G ra do

GRAU D’ENGINYERIA TELEMÀTICA

Estudio de los ataques contra website. OWASP.

VÍCTOR CHAVARRÍA GONZÁLEZ

Tutor

Francisca Hinarejos

Escola Politècnica Superior

Universitat de les Illes Balears

(2)

(3)

Í NDICE GENERAL

Índice general i

Índice de figuras iii

Resumen v

1 Introducción 1

2 ¿Qué es una aplicación web? 3

2.1 Cliente. . . 5

2.1.1 Usuario . . . 5

2.1.2 Navegador. . . 5

2.2 Servidor . . . 9

2.2.1 Base de Datos . . . 10

2.2.2 Cookies . . . 10

2.3 Protocolo de comunicación . . . 11

2.3.1 Petición HTTP . . . 11

2.3.2 Respuesta HTTP . . . 12

3 Testing de aplicaciones web 15 3.1 Amenazas. . . 17

3.1.1 Análisis de las amenazas . . . 18

3.1.2 Cálculo de gravedad de una amenaza. . . 20

3.2 Técnicas. . . 21

3.2.1 Inspecciones y revisiones manuales. . . 22

3.2.2 Modelaje de las amenazas . . . 23

3.2.3 Revisión del código fuente . . . 24

3.2.4 Tests de penetración . . . 24

3.3 Ejemplo de buen programa de testing . . . 25

3.3.1 Claves para un buen programa de testing . . . 27

4 Aplicación de la metodología en OWASP Top 10 29 4.1 Metodología OWASP . . . 29

4.2 OWASP TOP10 . . . 29

4.3 T10 - Redirecciones y envíos no validados . . . 31

4.3.1 Ejemplo de ataque . . . 31

4.3.2 ¿Cómo defenderse? . . . 35

(4)

ii ÍNDICE GENERAL

4.4 T9 - Uso de componentes con vulnerabilidades conocidas . . . 35

4.5 T8 - Falsificación de Peticiones en Sitios Cruzados (CSRF) . . . 37

4.6 T7 - Inexistente Control de Acceso a nivel de funcionalidades. . . 40

4.7 T6 - Exposición de datos sensibles. . . 43

4.8 T5 - Configuración incorrecta de seguridad . . . 44

4.9 T4 - Referencia directa insegura a objetos . . . 45

4.10 T3 - Secuencia de comandos en sitios cruzados (XSS) . . . 48

4.10.1 Ejemplos de ataques . . . 49

4.11 T2 - Errores en la autenticación y la gestión de la sesión. . . 57

4.12 T1 - Inyección . . . 60

4.12.1 Ejemplos de ataques . . . 61

5 Conclusiones 69

A ANEXO I 71

Bibliografía 73

(5)

Í NDICE DE FIGURAS

2.1 Arquitectura WEB Cliente-Servidor . . . 4

2.2 Porcentaje de uso de los navegadores (Por StatCounter). . . 6

2.3 Primer navegador de la historia . . . 6

2.4 Esquema de un navegador . . . 7

2.5 Ejemplo de esquema DOM . . . 9

2.6 Cuota de uso de los diferentes servidores web [1] . . . 10

2.7 Esquema de petición HTTP . . . 11

2.8 Ejemplo de petición HTTP GET . . . 12

2.9 Ejemplo de petición HTTP POST . . . 12

2.10 Esquema de respuesta HTTP . . . 13

3.1 Fases principales del desarrollo de software . . . 17

3.2 Tabla de clasificación de la puntuación. . . 21

3.3 Tabla de priorización de riesgo. . . 21

3.4 Diagrama de esfuerzo del SDLC . . . 26

3.5 Proporción de técnicas de testing . . . 26

4.1 T10 - Esquema de la vulnerabilidad . . . 32

4.2 T10 - Pantalla delogin. . . 32

4.3 T10 - Sitio malicioso . . . 33

4.4 T10 - Back-End del sitio malicioso. . . 33

4.5 T10 -Logincon la redirección modificada . . . 33

4.6 T10 -Logindel lugar malicioso. . . 34

4.7 T10 - Redirección al lugar correcto. . . 34

4.8 T10 - Tabla de la Base de Datos con los credenciales robados . . . 34

4.9 T9 - Muestra de la IP del servidor . . . 36

4.10 T9 - Muestra de la IP del atacante . . . 36

4.11 T9 - Vulnerabilidad explotada . . . 37

4.12 T8 -Escenario de la vulnerabilidad . . . 38

4.13 T8 - Imágen maliciosa . . . 38

4.14 T8 - Script malicioso . . . 39

4.15 T8 - Valor de la Base de Datos previa al ataque . . . 39

4.16 T8 -Valor de la Base de Datos posterior al ataque . . . 40

4.17 T7 - Página de inicio de sesión . . . 41

4.18 T7 - Aplicación una vez logueado . . . 41

4.19 T7 - Código fuente de la aplicación . . . 42

4.20 T7 - Ejemplo de ataque . . . 42

(6)

iv Índice de figuras

4.21 T7 - Resultado del ataque . . . 42

4.22 T7 -Código securizado . . . 43

4.23 T6 - Base de datos no cifrada . . . 44

4.24 T6 - Base de datos cifrada. . . 44

4.25 T5 - Última fase de la instalación de la aplicación. . . 45

4.26 T5 - Panel de instalación oculto . . . 46

4.27 T4 - Captura de la aplicación web . . . 47

4.28 T4 - Petición original . . . 47

4.29 T4 - Petición manipulada . . . 48

4.31 T3 - Captura del foro objetivo . . . 50

4.32 T3 - Preparación del ataque . . . 50

4.33 T3 - Resultado del ataque XSS . . . 50

4.34 T3 - Código de la aplicación encargada de almacenar de los datos. . . 51

4.35 T3 - Método para sanear los datos introducidos. . . 52

4.36 T3 - Código de la aplicación encargada de almacenar los datos securizado. 52 4.37 T3 - Resultado de la repetición del ataque . . . 53

4.38 T3 - Diferencia en la Base de Datos de los elementos saneados y los no saneados. . . 53

4.39 T3 - Aplicación objetivo . . . 53

4.41 T3 - Script de recepción de los datos . . . 55

4.42 T3 - Base de Datos donde se guardan los valores robados . . . 55

4.43 T2 - Ataque XSS para robar el ID de la sesión . . . 58

4.44 T2 - Obtención del ID . . . 58

4.45 T2 - Valores originales de la cookie del atacante. . . 59

4.46 T2 - Valores alterados de la cookie del atacante . . . 59

4.47 T2 - Panel de administración de la aplicación.. . . 60

4.48 T1 - Ejemplo de inyección de código . . . 62

4.49 T1 - Petición al servidor . . . 63

4.50 T1 - Petición al servidor manipulada . . . 63

4.52 T1 - Aplicación que muestra el tiempo . . . 64

4.53 T1 - Tabla del tiempo de Columbia . . . 65

4.54 T1 - Petición HTTP. . . 65

4.55 T1 - Petición HTTP manipulada . . . 65

4.56 T1 - Resultado de la inyección de código . . . 66

4.57 T1 - Ejemplo de aplicación . . . 66

4.58 T1 - Datos alterados . . . 66

4.59 T1 - Método simple de técnica de escape . . . 68 Resumen

(7)

R ^ESUMEN

Las aplicaciones web han ido evolucionando y facilitando su desarrollo desde su creación. Si bien los cambios han evolucionado en nuevas funcionalidades, se han generado nuevos problemas, entre ellos, la falta de securización.

Típicamente a la hora de desarrollar una aplicación web no se le da importancia a hacer que esta segura, ya que normalmente se ignoran las consecuencias de estas vulnerabilidades. OWASP, una asociación, se dedica en exclusiva a estudiar y generar herramientas para la securización de las aplicaciones web. Entre la documentación que genera existe un compendio de las diez vulnerabilidades más comunes en las aplicaciones web. A lo largo del trabajo se propondrá una metodo- logía para tener en cuenta la seguridad de las aplicaciones web, y se ejemplificarán las diez vulnerabilidades más comunes según OWASP atacándolas.

Finalmente, se explicará como solventar estas vulnerabilidades y se observará que con pequeños cambios se pueden prevenir problemas futuros. Sin embargo, seguir una metodología no evita que sea necesario contar con personas formadas en el campo de la seguridad informática por tal de poder securizar las aplicaciones.

(8)

(9)

C

APÍTULO

1

I NTRODUCCIÓN

Las aplicaciones web nos envuelven. Las utilizamos para consultar el tiempo, hacer la compra, ver una película e incluso para relacionarnos. Se han convertido en un elemen- to más de nuestra sociedad con el que convivimos. Gracias a las a aplicaciones web se han creado nuevas oportunidades, pero también han aparecido nuevos desafíos y problemas. Al igual que se exige un control en elementos de consumo como podrían ser los vehículos o las viviendas, es lógico que en estas nuevas aplicaciones tan cotidianas se exija, tarde o temprano, el mismo control.

Este trabajo está estructurado en dos partes diferenciadas. Primeramente se expli- cará porqué es necesario crear aplicaciones seguras, además, se presenta una visión global de qué es la metodología OWASP. Esta metodología está enfocada a crear aplicaciones web de manera segura, proponiendo un método para realizar esta tarea. La segunda parte consiste en explicar el OWASP TOP 10, la lista de vulnerabilidades en aplicaciones web más comunes según OWASP. Además de mostrar ejemplos de explo- tación y proponer soluciones a las mismas.

Por tal de contextualizar y poder comprender los elementos básicos que posteriormente se desarrollarán, al principio, se realiza un resumen de la historia de la Web, explicando su evolución y los elementos más importantes que conforman una aplica- ción web.

No es objetivo de este trabajo explicar qué herramientas y cómo automatizar la de- tección de vulnerabilidades, ya que existen múltiples herramientas y múltiples sistemas para realizar esta tarea.

(10)

(11)

C

APÍTULO

2

¿Q UÉ ES UNA APLICACIÓN WEB ?

En la década de los 80 ya existían ordenadores aunque debido a su alto coste la función principal era la investigación científica. Estos ordenadores estaban interconectados mediante una red de datos. Cada uno de los ordenadores tenía porciones de informa- ción diferentes y en caso de que un investigador quisiera consultar datos repartidos en diferentes terminales debía acceder uno por uno a todos los terminales. Por lo tanto, la obtención de información era una tarea tediosa y compleja.

Tim Berners-Lee, un ingeniero de software del CERN, desarrolló un proyecto lla- madoWorldWideWeb cuyo objetivo era poder compartir la información sin tener que entrar en los diferentes terminales. Para ello, explotaría un nuevo concepto, el Hipertexto. La idea básica de hipertexto es muy sencilla, permitir a un usuario ir de un documento de texto a otro. En la década de 1990 Tim Berners-Lee desarrolló 3 estándares (HTML [2], URI[3] y HTTP [4]) Creando de esta manera lo que se conoce comoWeb[5].

Esta manera de visualizar la información, las páginas web, revolucionó la manera que teníamos de comunicarnos. Sin embargo, contaban con un problema, eran estáti- cas. La comunicación era del servidor, aquel que contenía la información, al usuario, aquel que la consumía (ver figura2.1). Por lo tanto, no existía la manera de separar a los usuarios en diferentes categorías, todos eran tratados de la misma manera. Anali- zándolo desde una perspectiva de seguridad, esto no provocaba grandes problemas dado que toda la información era pública. Por aquel entonces el mayor problema de seguridad consistía en que se alteraran los contenidos delsiteque se visitaba.

Todo cambió cuando se desarrolló lo que se conoce como Web 2.0, en este punto la comunicación era bidireccional. El rol del usuario ya no es simplemente aquel que consume la información, sino que solicita una información en concreto, genera nueva información y modifica o elimina la existente. Es decir, la Web se había convertido en un ente con el que se interactuaba.

(12)

2. ¿QUÉ ES UNA APLICACIÓN WEB?

Figura 2.1: Arquitectura WEB Cliente-Servidor

Es en este punto cuando nacen las aplicaciones web [6]. Existe cierta controversia sobre la diferencia entreWeb InteractivayAplicación webya que estrictamente una aplicación web debería ofrecer una funcionalidad al usuario sin necesidad de conexión, no obstante a lo largo de este trabajo se considerarán de igual manera [7].

El nacimiento de aplicaciones web trajo nuevos problemas de seguridad, esto se debe a que nació el diferente trato a los usuarios. Existe información que no debe ser pública para algunos usuarios. Las aplicaciones web permiten realizar operaciones que deben ser seguras, como por ejemplo operaciones bancarias, es de vital importancia que estas operaciones no se modifiquen, o no se realicen sin el consentimiento explícito del usuario. Además, a lo largo de los años se ha facilitado tanto el desarrollo de aplicaciones web que prácticamente cualquier persona puede crear su propia aplicación. El problema reside en que desarrollar una aplicación no significa desarrollarla de manera segura, es decir, funcionalidad no está ligado a seguridad [6].

La arquitectura habitual de una aplicación web consiste en un Cliente/Usuario, aquel que solicita la aplicación e interactuará con la misma. Habitualmente es una persona física, también conocido comoUsuario final. Un servidor, la entidad que proporciona la aplicación a los clientes, es aquella que guarda la información y se encarga de enviar la información. Finalmente también se debe considerar el protocolo mediante el cual estas dos entidades se comunican.

Un ejemplo de aplicación web sería Wikipedia, si realizamos la analogía más cer- cana al mundo físico consistiría en una biblioteca. Un cliente entra en la biblioteca y solicita un libro. El bibliotecario, que actúa como servidor, se encarga de procesar la petición del cliente y servirle lo que ha solicitado y el canal usado ha sido el aire.

A continuación se detallarán cuales son las partes importantes de esta arquitectura.

4

(13)

2.1. Cliente

2.1 Cliente

Cuando se menciona un cliente web se hace referencia a aquella aplicación, habitualmente controlada en última instancia por una persona física (ver sección2.1.1- Usuario), que consume un servicio a través de una red de telecomunicaciones. De esta manera el cliente se encarga de procesar los datos que le proporciona la entidad que ofrece el servicio.

En el caso de una aplicación web, el cliente mas común es el navegador, y el usuario, la persona.

2.1.1 Usuario

Como se ha mencionado en el párrafo anterior el usuario es aquella persona que inter- actúa con el cliente. Típicamente quien finalmente consume la información.

Este punto es relevante, sobre todo porque a la hora de tomar decisiones de desarrollo se ha de tener presente que el usuario corriente de aplicaciones web no es experto en las mismas, por lo tanto deben realizarse pensando en como una persona sin conocimientos en este campo pueda usarla.

Nadie va a usar una aplicación que no entiende, ya que dificulta la tarea y puede generar desconfianza. En términos de seguridad el usuario es una entidad que no se puede controlar y puede ser la parte más débil del esquema.

Un atacante siempre intentará atacar la parte más débil del esquema de la apli- cación web.

2.1.2 Navegador

La RAE define Navegador como: "Aplicación que, mediante enlaces de hipertexto, per- mite navegar por una red informática."[8].

La definición es válida, pero excesivamente escueta, un navegador interpreta y permite visualizar un documento web, es decir, es un software que se encarga de traducir el lenguaje de las aplicaciones para los usuarios, las personas, permitiendo de esta manera que se interactúe con las página web de manera sencilla.

El primer navegador fue desarrollado también por Tim Berners-Lee, cuyo nombre fueWorldWideWeby se lanzó una primera versión el 25 de Diciembre de 1990 [9]. La figura2.3muestra una imagen de como era aquel navegador.

Durante esa década surgieron navegadores de gran repercusión, comoNetScape(1994) eInternet Explorer(1995) pero en la primera década del nuevo milenio fue cuando nacieron los navegadores más populares hoy en día [10]:Safari(2003),Mozilla Firefox (2004) yGoogle Chrome(2008). La figura2.2muestra los navegadores más usados a día de hoy.

Pese a todo esto, los navegadores han ido avanzando y añadiendo diferentes componentes y mecanismos de seguridad para evitar vulnerabilidades.

Si bien hay múltiples opciones en el mercado, cada navegador normalmente consta de tres partes:

(14)

Figura 2.2: Porcentaje de uso de los navegadores (Por StatCounter)

Figura 2.3: Primer navegador de la historia

6

(15)

2.1. Cliente

Figura 2.4: Esquema de un navegador

• Controlador: la parte encargada de recibir la entrada del teclado o ratón y utiliza los programas clientes para acceder al documento.

• Intérpretes: el conjunto de entidades que se encargan de visualizar el documento en pantalla son los interpretes. Cabe destacar que este puede ser HTML, CSS, PHP, Java o JavaScript entre otros.

• Protocolo de cliente: la lógica y aquel que indica qué reglas se han de seguir para que el intercambio de información sea correcto. Dos ejemplos concretos de estas reglas son las definidas en los protocolos HTTP (que se menciona más adelante.

Sección2.3-Protocolo de comunicación), o FTP [11].

Como resumen, en la figura2.4se puede ver un esquema de las diferentes partes que forman un navegador.

Con la idea de profundizar en la seguridad de las aplicaciones y comprender mejor cómo funcionan las mismas, se entrará en algo más de detalle de varios conceptos sobre los que trabajan los navegadores. Estos conceptos son necesarios para entender el funcionamiento de algunos de los ataques que se pondrán en práctica:

1. HTML

Anteriormente se ha explicado que el nacimiento de la Web y por tanto de las aplicaciones web, está ligado al lenguaje HTML, es decir, al Hypertexto. HTML también es conocido comoLenguaje Marcador, ya que sus sigla sonHyperText MarkupLanguage.

El nombre viene dado de la industria de publicaciones de libros. Previa a la edi- ción de un libro, el editor anota diferentes marcas a lo largo del texto para indicar, por ejemplo, que parte del texto debe ir resaltada en negrita. De esta manera, el diseñador sabe cómo debe maquetar el texto para generar el libro final. HTML usa el mismo principio, el texto se rodea de etiquetas,tags, para que el interprete del navegador pueda procesarlas y muestre la aplicación web de la manera que se ha diseñado. Además estas etiquetas pueden contener valores para poder realizar de manera más precisa la maquetación.

(16)

Cabe destacar que las etiquetas siempre están encerradas entre los símbolos menor y mayor: <etiqueta>.

Existen dos tipos de etiquetas, las denominadasetiquetas de comienzoyfin, que actúan sobre aquello que están rodeando, por ejemplo:

<b>Este t e x t o sera procesado en negrita </b>

La primera etiqueta puede contener diferentes atributos, siempre opcionales, que permiten apurar más la maquetación, o operar sobre la porción de texto que se encierra. Sin embargo, la etiqueta de fin, no puede contener atributos, y siempre se precede por el carácter ”/”, que indica el cierre de la etiqueta.

Asimismo, existen etiquetas autocontenidas. Por ejemplo, en el caso de querer introducir una imagen, no es necesario usar una etiqueta de cierre, por lo tanto quedaría así:

En este ejemplo se ha usado la etiquetaimgpara indicar que se mostrará una imagen y el atributosrcpara indicar dónde se ha de ir a buscar la imagen [11].

2. JavaScript

Si bien HTML sirve para crear páginas web estáticas, es decir, la Web 1.0, para el nacimiento de la Web 2.0 es necesaria la aparición descripts. JavaScript es un lenguaje interpretado, es decir, no necesita que se compile previamente para ejecutarse, se ejecuta línea a línea a medida que este es interpretado. Además, la peculiaridad de JavaScript reside en que se ejecuta en el cliente, por lo tanto, no se sobrecarga el servidor con operaciones que pueden realizar los clientes.

Gracias a JavaScript, una aplicación web puede alterar su comportamiento, o apariencia en función de lo que el usuario realice sobre la misma sin cargar al servidor con excesivos cálculos.

Un ejemplo, supongamos una aplicación web que permite comprar diferentes productos con distintos precios. El usuario va añadiendo productos a su lista de la compra, gracias a los scripts, el precio total puede ser recalculado sin necesitar ninguna conexión adicional al servidor de la aplicación web [12].

3. CSS

Las etiquetas HTML permiten maquetar una aplicación web, ahora bien, una aplicación web está formada por múltiples documentos HTML, por lo tanto, ma- quetarlas una a una es una tarea muy tediosa. Para solventar este problema nació CSS,CascadeStyleSeets.

Las hojas de estilo (CSS) simplemente consisten en lo que se acaba de mencionar, un documento de texto que define como deben visualizarse los elementos que después conforman la página web [13].

8

(17)

2.2. Servidor

Figura 2.5: Ejemplo de esquema DOM

El problema reside en que manipular el CSS puede ser peligroso, ya que por ejemplo, existen atributos comobackground-imageque si se manipulan pueden permitir que una víctima lance una petición HTTP que no quería. También es posible alterar la visibilidad de una aplicación, ocultando elementos y provocando pérdidas al dueño de la aplicación [14].

4. DOM

DOM (DocumentObjectModel) es un estándar desarrollado por W3C [15] que define una API neutral que permite acceder y actualizar tanto el contenido, como la estructura y el estilo de un documento. Por lo tanto, se puede definir como Estructura lógica de los documentos y el modo en que se accede y manipula un documento. Esta estructura puede ser pensada como una estructura en árbol tal y como muestra la figura2.5[16].

Los documentos HTML están estructuados de manera jerárquica con dos elementos principales. Elheader, que contiene información sobre la aplicación web, y elbody, que contiene la aplicación propiamente con sus diferentes elementos.

Debido a la evolución de la web esta jerarquía también ha evolucionado. Si una aplicación debe modificar un elemento concreto de la misma, como una imagen, es necesario poder hacer referencia a esta. Esta es la funcionalidad de DOM.

Gracias a este modelo, mediante JavaScript se pueden crear webs dinámicas al tratar cada objeto de manera independiente. Comúnmente se puede observar como las aplicaciones acceden a estos documentos con funciones como:

document.getElementById(id).

2.2 Servidor

Como se ha definido anteriormente, un servidor no es más que aquella entidad, bien física, bien un software, en funcionamiento dentro de una máquina física, que ofrece

(18)

un servicio a los clientes que lo solicitan.

Los servidores pueden ofrecer múltiples servicios como puede ser: e-mail, intercambio de ficheros,streaming, o acceso a aplicaciones web. En este último caso, existen diversas aplicaciones para instalar un servidor web en un ordenador, no obstante la mayoría de los servidores web activos disponen de alguna versión deApache[17]. La figura2.6 muestra la cuota de los diferentes servidores en 2016.

Figura 2.6: Cuota de uso de los diferentes servidores web [1]

Los servidores de aplicaciones web alojan los documentos que se servirán a los clientes, pero también es común que almacenen datos. Por ejemplo, los nombres de usuario, direcciones de correo electrónico y las contraseñas de los usuarios que acceden a la aplicación. Para ello además del software que ofrece el servicio web, es común que también tengan instalado algún sistema de Gestión de Bases de Datos.

2.2.1 Base de Datos

Una Base de datos es una estructura de datos organizada, es decir, una colección de datos organizados basado en el modelo de datos relacional.

Al guardar datos sensibles, como información de tarjetas de crédito o contraseñas de usuarios, debería almacenarse de manera segura, usando un esquema de cifra que evite que se pueda recuperar el valor en claro. De esta manera, en caso de sufrir un ataque que robe los datos sensibles, el atacante no podrá obtener información sobre los datos robados, ya que estarían cifrados.

Los esquemas actuales de cifra actuales, como por ejemplo los utilizados para almacenar contraseñas, son complejos y escapan del objetivo de este trabajo.

2.2.2 Cookies

Cuando se diseñó la World Wide Web no se tuvo en cuenta que esta pudiera tener estado, es decir, a la misma petición se responde con la misma respuesta. No existía ningún vínculo que ligara el usuario con el servidor mas allá de esa conexión. Sin embargo, al 10

(19)

2.3. Protocolo de comunicación

Figura 2.7: Esquema de petición HTTP

introducir nuevas funcionalidades a la web, como por ejemplo, información privada que sólo debe ser visible para los usuarios registrados, es buena idea evitar que la misma petición tenga una respuesta diferente dependiendo de los privilegios de cada usuario.

Con esta finalidad se diseñó el mecanismo decookie, que en si mismo no es más que información de estado que tienen tanto el cliente como el servidor. De esta manera, cuando el cliente realiza una petición incluye en esta la cookie, logrando así que el servidor identifique al cliente y pueda recuperar el estado [11].

2.3 Protocolo de comunicación

Internet es un red de comunicación, para que todas las entidades que forman la red se puedan comunicar es necesario establecer protocolos con el objetivo de que el intercambio de información sea satisfactorio. En caso de las aplicaciones web el protocolo más conocido es elHyperTextTransferProtocol, conocido por sus siglasHTTP.

HTTP es un protocolo destinado al intercambio de ficheros web basado en el esquema pregunta-respuesta.

2.3.1 Petición HTTP

La figura2.7muestra el esquema de una petición HTTP. En el RFC de HTTP [18] se establecen una serie de métodos (tipos de mensajes que permiten realizar acciones en concreto) así como diferentes cabeceras, donde por ejemplo se indicará lacookie, el servidor o diferente información de control.

(20)

Figura 2.8: Ejemplo de petición HTTP GET

Figura 2.9: Ejemplo de petición HTTP POST

En caso de HTTP versión 1.1 la única cabecera obligatoria es la deHostque se puede observar en los ejemplos de peticiones a continuación.

Si bien existen diferentes métodos para una petición, se quieren destacar dos:

HTTP - GET

La petición GET sirve principalmente para solicitar un contenido alojado en un servidor web. La Figura2.8muestra un ejemplo real [19] de una petición web.

También es posible enviar pequeñas cantidades de información en las propias URL y las variables que estas pueden contener. No obstante, no se entrará en detalle de la composición de estas.

HTTP - POST

Así como GET se diseñó para solicitar información, POST se definió como método para enviar información (ver figura2.9).

Como se ha mencionado anteriormente, excepcionalmente GET permite enviar pe- queñas partes de información incluidas en la URL, pero esa no es su función principal, por ello la cantidad de información a enviar es limitada. Sin embargo, POST permite enviar la cantidad necesaria de información, no existen límites. Además, al no estar visibles en la URL después de ser enviados, se dice que es más seguro que GET, pero en ningún caso es un método seguro para enviar información por sí solo.

2.3.2 Respuesta HTTP

Los mensajes de respuesta (ver figura2.10) no tienen un gran interés para el objetivo de este trabajo, sólo cabe destacar que se establecen diferentes códigos de respuesta para informar al cliente si la petición ha sido correcta o ha existido algún tipo de problema durante la misma [18].

12

(21)

2.3. Protocolo de comunicación

Figura 2.10: Esquema de respuesta HTTP

Ahora bien, HTTP tiene un problema, no ofrece ningún tipo de seguridad. La red es una entidad no controlada y la información pasa por mucho nodos intermedios antes de llegar al destinatario final, por lo tanto, es susceptible de ser atacada durante el trayecto, ya sea modificándola, borrándola o directamente generar nuevas respuestas a peticiones que nadie ha hecho.

Teniendo en cuenta la cantidad de información privada o sensible que se transfiere hoy en día, es necesario establecer algún mecanismo para securizar esta información. Si bien no es posible evitar estos ataques, sí que es posible establecer métodos de control para que en caso de sufrir algunos de estos ataques, se puedan detectar y descartar los mensajes atacados.

Con esta idea nacióHTTP sobre TLSo comúnmente conocido como HTTPs. No es objetivo de este trabajo tratar su funcionamiento, sin embargo es necesario conocer que HTTPs proporciona servicios deautenticación,integridad,confidencialidadyno repudio. Para ello se sirve deTLS, un añadido a la capa de transporte que establece servicios de seguridad.

(22)

(23)

C

APÍTULO

3

T ESTING DE APLICACIONES WEB

Hoy en día la sociedad no puede concebir un vehículo como un coche o un avión, sin que pase las pruebas de seguridad apropiadas. Toda la industria de la automoción sabe de la importancia de estas pruebas. Los diseñadores tienen en cuenta la seguridad en diversos campos, existen diseños que permiten al coche absorber mayor fuerza en caso de impacto evitando tanta fuerza como sea posible a los usuarios. Incluso los vendedores saben que la seguridad vende y se apresuran a mencionar el sistema del que dispone un vehículo para alertar de un posible peligro durante el trayecto.

¿En el mundo informático, esto es así? Desgraciadamente no. En el caso de las aplicaciones web es crítico, ya que están abiertas a todo el mundo. De nada sirve tener un sistema de cifra indescifrable basado en una palabra clave secreta, si la clave es fácilmente accesible. Denis Verdon, jefe deInformation Securityen laFidelity National Financialexplicó en la OWASP AppSec de 2004:Ïf cars were built like applications [...]

safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency manuevers, brake effectiveness, side impact, and resistance to the theft"[20]

¿Qué significatesting?

En lengua castellana,testingse entiende comopruebas de software. Sin embargo, existe algún matiz más. Por testing se entenderá la comparación del estado de un sistema o aplicación frente a un conjunto criterios.

Así, en caso de que un mensaje sufra alguna alteración esta debe ser detectable, incluso evitar que un sistema de cifra sea descifrado por un ataque de fuerza bruta en un periodo de 300 años. El problema consiste en cómo definir de manera clara y precisa los criterios. Usando el segundo ejemplo, se tendrían que definir las condiciones del ataque de fuerza bruta, o en un criterio más general, como podría ser la detección en caso de alteración de los mensajes. Definir como y cuando se detectan las alteraciones es algo complicado.

(24)

3. TESTING DE APLICACIONES WEB

¿Por qué realizar testing?

En el mundo de la ingeniería de software existe el dogma de que no se puede controlar aquello que no se puede medir, heredada de la cita"De acuerdo con la nueva física, lo que no se puede medir no existe físicamente."[21].

La seguridad no es una excepción, no es un ente abstracto que no se pueda medir. Como se ha mencionado anteriormente, se pueden definir reglas y es importante saber cuan seguro es un software. En caso de un mal funcionamiento de una aplicación web, o una mala securización de la misma, se puede poner en riesgo tanto al usuario como a la entidad propietaria de la aplicación. El primer aspecto que se vería afectado sería la reputación de la entidad propietaria de la aplicación.

Si planteamos el escenario en el cual una vulnerabilidad se encuentra en la aplicación web de una entidad bancaria, su reputación se verá afectada y esto puede crear desconfianza en los clientes provocando pérdidas indirectas a la empresa.

También pueden provocar costes económicos de manera directa, y la cuantía de los mismos puede ascender a cifras muy importantes. En Junio de 2002, el US National Institute of Standards(NIST) estimó el coste en los Estados Unidos provocado por software inseguro en 66 Billones de dólares [22]. No obstante, el dato relevante es que con una mejor infraestructura de testing se hubiera ahorrado más de una tercera parte de estos costes, es decir, 22 Billones de dólares.

¿Cuándo testear?

En la actualidad existen diversas metologías para el desarrollo de software, desde los más completos, como elISO/IEC 12207, hasta métodos más prácticos como elScrumo los métodosAgile. Cada uno de estos métodos tiene su particularidad, pero es habitual encontrar unCíclo de Desarrollo del Software(SDLC Software Development Life Cycle) tal y como el que se muestra en la figura3.1.

Si tomamos como premisa un desarrollo lineal, cuanto más avanzado esté el mismo, en caso de encontrar alguna vulnerabilidad, más pasos se tendrán que revertir.

Es posible que se tenga que volver a rediseñar algunas partes del proyecto. Por lo tanto se puede concluir que, como norma general, el tiempo que se tarda en descubrir una vulnerabilidad es directamente proporcional al coste que supone solventarla.

Es por ello que las pruebas se deben realizar en todas las fases del desarrollo, ya que solo de esta manera se tendrá la oportunidad de solventarlas minimizando el impacto que puedan tener en el producto.

¿Qué testear?

Para poder desarrollar un software es necesaria la combinación de diversos recursos, tanto humanos, como tecnológicos. Un grupo de desarrolladores, jamás podrá llevar a cabo ningún proyecto si no cuenta con unos recursos tecnológicos.

Es posible agrupar estos recursos en tres grandes categorías.

16

(25)

3.1. Amenazas

Figura 3.1: Fases principales del desarrollo de software

• Recursos Humanos: Persona que, de un modo o otro, esté involucrada en el proyecto.

• Procesos: Normas y/o estándares que establecen cómo deben llevarse a cabo las diferentes acciones en el desarrollo del software.

• Tecnología: Elementos que finalmente conforman el software en sí, por ejemplo, en caso de una aplicación web, los servidores que dan soporte a la misma o el lenguaje usado para su desarrollo.

Estos tres campos son elementos claves para el desarrollo, por lo tanto es importante realizar pruebas en los tres. Hay que asegurarse que aquellas personas que están trabajando en el desarrollo tienen la habilidad y la concienciación adecuada para evitar cometer vulnerabilidades, o corregirlas de manera eficien- te cuando sea necesario. Los procesos han de ser claros y se deben adecuar al proyecto y a las personas que trabajan en el mismo. Finalmente, la tecnología también se ha de poner a prueba.

3.1 Amenazas

Al hablar de seguridad una de las principales preguntas que todo el mundo se puede hacer es¿Contra qué nos hemos de proteger?La respuesta no es simple, cada día sur- gen nuevas vulnerabilidades y problemas de seguridad. La securización es una batalla muy injusta y desigual.

Es una batalla desigual porque la cantidad de personas con los conocimientos necesarios para establecer seguridad es muy inferior a la cantidad de información

(26)

a securizar. Además hay infinidad de personas dispuestas a atacar sistemas ajenos, desde los conocidos comoscript kiddies, personas que bajan una aplicación con la que ejecutar un ataque sin tener conocimientos de que están realizando, hasta expertos en seguridad con una dudosa moralidad. La combinación de todos estos aspectos plantea un escenario plagado de amenazas.

Otro de los puntos a destacar es la imposibilidad de securizar todo perfectamente.

Esto quiere decir que allá donde se haya dejado una pequeña vulnerabilidad es donde se va a sufrir el ataque. Este aspecto es muy importante y grave, ya que un despiste puede comprometer todo el sistema, haciendo inútiles el resto de buenas prácticas.

3.1.1 Análisis de las amenazas

Securizar la asplicaciones web es dificil, posteriormente, en la sección3.2-Técnicasse mostrarán diferentes técnicas para facilitar la tarea. Sin embargo, antes de aplicar estas técnicas es conveniente realizar un estudio sobre cuáles son las amenazas existentes. Al realizar este estudio surgirán diferentes preguntas que se deben intentar contestar para determinar cuales de estas amenazas y de qué manera pueden afectar a la aplicación que se quiere auditar.

OWASP [23] propone una serie de métricas y preguntas para establecer la gravedad de las amenazas, de esta manera se pueden distribuir de manera más eficaz los recursos disponibles para poder securizar las aplicaciones. Sin embargo es solo una propuesta, cada organización es libre de desarrollar los puntos clave y sus métricas para adaptar el análisis a su aplicación.

La metodología de OWASP analiza cada amenaza desde dos perspectivas, la probabilidad de que esta suceda y el impacto que puede producir. Cada una de estas perspectivas se subdividirá en dos nuevas para desglosar las amenazas. Dentro de cada subdivisión se asignarán valores numéricos en una escala de 1 a 10, según el impacto de la amenaza. Gracias a este desglose, se podrá calcular una media y finalmente crear una tabla para analizar el riesgo y poder priorizar qué amenazas son las que deben resolverse primero.

Probabilidad de amenaza

Existen vulnerabilidades altamente complejas de explotar y otras que son muy senci- llas, de tal manera que las puede explotar cualquier persona sin conocimientos. De esta manera, la probabilidad de que la vulnerabilidad sea atacada varía, cuantos más atacantes potenciales tenga una vulnerabilidad mayor es la probabilidad de que sea explotada.

Para poder obtener un valor de probabilidad de que una amenaza suceda se calcu- lará el valor medio de las siguientes características:

Perfil del atacante

• Nivel de habilidad

¿Qué conocimientos son necesarios para realizar el ataque? Pentesting (1), Redes y 18

(27)

3.1. Amenazas

programación (3), Usuario avanzado (6), habilidades técnicas básicas (5), ninguna habilidad técnica (9).

• Motivaciones

Si un agente realiza el ataque, obtendrá una recompensa: alta (9), normal (4), o no obtendrá recompensa (1)

• Coste de oportunidad

¿Qué recursos y oportunidades se deben usar para explotar la vulnerabilidad?

Es necesario un gran equipo o acceso completo al sistema (0), acceso o recursos especiales (4), simple acceso o recursos (7) o no es necesario ningún tipo de acceso o recurso (9).

• Rol del atacante

¿Qué roles pueden atacar el sistema? Desarrolladores (2), administradores de sistemas (2), usuarios de la intranet (4), socios (5), usuarios autenticados (6), usuarios anónimos de Internet (9).

Además del perfil del atacante, para calcular la probabilidad de que la amenaza sea explotada también se han de tener en cuenta factores propios de la vulnerabilidad.

Factores de la vulnerabilidad

• Dificultad de descubrimiento

Es: prácticamente imposible (1), difícil (3), fácil (7), se puede descubrir con herramientas automatizadas (9)

• Facilidad de explotación

Se puede explotar de: una manera teórica (1), difícilmente (3), fácilmente (5) o con herramientas automatizadas (9)

• Conocimiento de la vulnerabilidad

Se debe evaluar si es una vulnerabilidad desconocida (1), oculta (3), obvia (6), o de conocimiento público (9).

• Detectabilidad

En caso de ser explotada, ¿cómo puede un gestor percatarse de que ha sido explotada? Fácilmente observable en la aplicación (1), queda en el log y se genera un reporte (3), mediantes logs sin reportes (8), no queda registrada en el log (9).

A continuación se mencionaran los factores a tener en cuenta para analizar el impacto de la vulnerabilidad.

Impacto de la vulnerabilidad

Como en el caso anterior, se derivan dos subsecciones,impacto técnicoy elimpacto en el negocio.

(28)

Impacto técnico

• Pérdida de confidencialidad

¿Cuantos datos pueden divulgarse? Una mínima porción de datos no sensibles (2), una porción mínima de datos críticos (6), una gran cantidad de datos no sensibles (6), una gran catidad de datos críticos (7), se divulgan todos los datos (9).

• Pérdida de la integridad

¿Cómo y cuantos datos se pueden corromper? Pocos datos y una corrupción suave (1), pocos datos pero alta corrupción (3), muchos datos pero corrupción suave (5), muchos datos y altamente corruptos (7), todos los datos totalmente corruptos (9).

• Pérdida de servicios

¿Qué servicios pueden dejar de ofrecerse? Algunos servicios secundarios (1), algunos servicios primarios (1), la mayoría de servicios secundarios (5), la mayoría de servicios primarios (7), todos los servicios (9).

• Trazabilidad

¿Se puede identificar al atacante? Totalmente identificable (1), es posible (7), completamente anónimo (9).

Impacto en el negocio

• Impacto financiero

Las pérdidas son menores que el coste de reparación de la vulnerabilidad (1), pérdidas anuales mínimas (3), pérdidas significativas en el computo anual (7), bancarrota (9).

• Daño en la reputación

La reputación de la empresa se ve resentida de manera mínima (1), pérdida de acuerdos comerciales (4), pérdida del fondo de comercio (5), o daño a la marca (9).

• Legalidad

La vulnerabilidad afecta a los acuerdos legales de manera menor (2), producen una clara violación (5), una violación grave del acuerdo (7).

• Privacidad

¿Qué información personal puede revelarse? De un individuo (3), cientos de personas (5), miles de personas (7), millones de personas (9).

3.1.2 Cálculo de gravedad de una amenaza

Una vez evaluadas las amenazas, OWASP propone un método para establecer un es- tándar de gravedad. De esta manera se obtendrá qué amenazas serán más graves que otras. .

Para cada una de las amenazas se han puntuado diversos factores de 0 a 9. A conti- nuación, se calculará la puntuación de cada uno de los factores explicados, es decir, 20

(29)

3.2. Técnicas

Figura 3.2: Tabla de clasificación de la puntuación

Figura 3.3: Tabla de priorización de riesgo

tanto para laProbabilidad de la amenazacómo elImpacto de la vulnerabilidadse obtendrá el valor medio de cada subapartado, que será el valor medio de cada apartado.

El valor numérico obtenido será un valor entre el 0 y 9, que se clasificará según la tabla mostrada en la figura3.2.

Con el factor de riesgo de cada amenaza, se usará la siguiente tabla de la figura 3.3para establecer el riesgo para cada una de las amenazas, de esta manera se podrá priorizar cuales solventar primero.

Según OWASP algunas vulnerabilidades no valen la pena solventarse, ya que el coste para solucionar la vulnerabilidad pueden superar el coste de que la amenaza se explote, aunque concreta que pueden existir daños en la reputación.

Personalmente no creo en esa filosofía, ya que es contradictoria, el coste para solventar una amenaza es solo uno de los múltiples factores, además se ha de tener en cuenta que afecta a otras entidades.

3.2 Técnicas

A continuación se explicarán varias técnicas que propone OWASP [20] para realizar la labor de testing. No se debe usar una simple técnica, se tendrán que usar varias ya que

(30)

cada una dispone de una serie de ventajas e inconvenientes, incluso puede que alguna técnica no aplique al proyecto que se está desarrollando. Estas técnicas se pueden categorizar de la siguiente manera:

• Inspecciones y revisiones manuales.

• Modelado de las amenazas.

• Revisión del código.

• Tests de penetración.

3.2.1 Inspecciones y revisiones manuales

Pese a ser un concepto simple, las inspecciones y revisiones manuales pueden ser una de las técnicas más poderosas. Al revisar cómo funciona o por qué se ha implementado de una manera específica alguna característica, se puede obtener información relevante de seguridad. No obstante, no conviene caer en el error de simplemente analizar el código fuente de la aplicación. Existen varias maneras para destapar vulnerabilidades, por ejemplo, realizar entrevistas con el equipo de desarrollo de la aplicación es también una inspección manual, tan válida como revisar la documentación generada durante el desarrollo.

Esta técnica puede hacer que los procesos de seguridad sean más sencillos de entender a las personas encargadas del proyecto, además de asegurarse que los desarrolladores utilizan las herramientas y políticas adecuadas para una implementación segura de una aplicación.

Las ventajas y desventajas de esta técnica son las siguientes:

Ventajas

• No se depende de ninguna tecnología.

• Aplicable a múltiples escenarios.

• Alta flexibilidad.

• Favorece el trabajo en equipo.

• Aplicable de manera temprana en el SDLC.

Desventajas

• Alto coste temporal.

• No siempre se puede acceder al material o consultar a los desarrolladores.

• Es necesaria una buena formación para obtener resultados adecuados.

22

(31)

3.2. Técnicas

3.2.2 Modelaje de las amenazas

Una aplicación puede ser vulnerable en múltiples campos diferentes. Modelar y analizar en qué lugares puede ser vulnerable es muy recomendable. Si los desarrolladores saben dónde se ubican los riesgos más graves pueden centrar sus recursos en prevenir- los.

El modelaje debe hacerse cuanto antes y se debe ir revisando a medida que el proyecto avanza. Existen algunos estándares para clasificar los posibles riesgos, aun así, una taxonomía adecuada debe contemplar los siguientes aspectos:

• Descomposición de la aplicación. Mediante el análisis manual se debe comprender el funcionamiento, funcionalidad y conectividad de la aplicación.

• Definición y clasificación de los recursos.Conocer los recursos de los que se disponen y clasificarlos según la relevancia en nuestra organización. Solo si se conoce lo que se tiene se pueden evaluar los daños o costes que puede producir una vulnerabilidad.

• Explorar las vulnerabilidades potenciales.Teniendo presente que se pueden presentar en cualquier campo de la aplicación, en algún proceso, apartado técni- co o el diseño de la misma.

• Explorar las amenazas potenciales.Analizar el sistema desde el punto de vista de un atacante es de gran ayuda para descubrir nuevas amenazas. El análisis de los escenarios posibles es una herramienta muy útil.

• Creación de estrategias de prevención.El desarrollo de herramientas de control y mitigación de las amenazas de manera realista es uno de los objetivos. No todas las amenazas se podrán solventar, pero probablemente se podrán paliar sus efectos.

Cabe destacar que no existe una manera perfecta de realizar este modelaje ni una manera incorrecta. Normalmente al realizar esta técnica se obtienen diferentes diagra- mas y esquemas que plantean los escenarios en los cuales se es vulnerable, como por ejemplo, los casos de uso de uso en un diagrama UML [24].

Las ventajas y desventajas de esta técnica son las siguientes:

Ventajas

• Análisis desde el punto de vista de un atacante.

• Flexibilidad.

• Temprano en el SDLC.

Desventajas

• Un buen análisis de las amenazas no significa obligatoriamente un buen software.

(32)

3.2.3 Revisión del código fuente

El código fuente de una aplicación es, a fin de cuentas, la aplicación en sí. Es donde se reflejan todos los aspectos de la misma, por lo tanto algunas vulnerabilidades no se pueden detectar de otra manera que no sea con el análisis del código fuente. No existe ninguna otra herramienta mejor para conocer qué realiza una aplicación.

Por todos estos aspectos el código siempre debería ser entregado a un analista de seguridad. De esta manera se puede dejar de un lado el análisis decaja negray pasar a caja blancay poder descubrir, entre otras cosas, debilidades criptográficas, el uso de funciones débiles, código malicioso, obsolescencia programada, etc.

Cabe destacar que la revisión del código no tiene porque ser estríctamente manual, aunque sí que es conveniente. Se pueden usar herramientas para buscar vulnerabilidades en el mismo, como puede serZAP, sin embargo, la revisión manual será siempre más precisa que una revisión automática.

Es una técnica muy potente, pero también muy costosa, por eso es importante conocer sus ventajas e inconvenientes:

Ventajas

• Completo y efectivo.

• Muy preciso.

• Rápida de ejecutar.

Desventajas

• Es necesario un conocimiento muy amplio para aplicarse.

• Se pueden dejar de lado vulnerabilidades existentes en librerías de terceros.

• No se pueden detectar de manera rápida los problemas producidos a tiempo real.

• El código actual puede diferir del código que se analiza.

3.2.4 Tests de penetración

También conocido comopentestingse trata de una técnica decaja negracomúnmente asociada al hacking ético. Consiste en probar de manera remota una aplicación con la finalidad de encontrar vulnerabilidades sin conocer cómo funciona la aplicación.

Típicamente se accede a la aplicación desde una perspectiva de un usuario malicioso en búsqueda de vulnerabilidades que se intentarán explotar. Es habitual requerir de una cuenta de usuario válida.

Esta técnica es conocida en la securización de redes o sistemas operativos, siendo muy eficaz en ambos casos. Desgraciadamente, esto no se traduce en una eficacia cuando se trata de aplicaciones web, y no es causa de una mala adaptación del Pentesting, sino por la naturaleza de la web. Los tests de penetración suelen basarse en herramientas automatizadas y debido a la heterogeneidad de las aplicaciones, normalmente es 24

(33)

3.3. Ejemplo de buen programa de testing

una técnica con pobres resultados.

Sus problemas se pueden resumir en una frase de Gary McGraw:"Si no superas un test de penetración sabes que tienes un grave problema. Si lo superas, no sabes si tienes un problema"[20].

Así mismo es una buena idea lanzar tests de penetración frecuentemente, analizando sus principales ventajas e inconvenientes se puede deducir que aunque sea rápido y barato, depende de la aplicación y de la profundidad de la prueba. Sus ventajas y desventajas son:

Ventajas

• Puede ser rápido y barato.

• Los conocimientos necesarios son menores que la revisión del código.

• Comprueba el código que está expuesto.

Desventajas

• Muy tardío en el SDLC.

• Solo se realiza el testing sobre la parte frontal de la aplicación.

3.3 Ejemplo de buen programa de testing

Tal y como se ha visto en la sección3.2-Técnicasno existe una selección correcta o incorrecta de técnicas a aplicar a la hora de ejecutar un programa de testing, y no siempre es una tarea fácil seleccionar algunas de ellas. De manera ideal se deben testear todas las áreas posibles, aunque no siempre es posible, ´lo que provoca que muchas organizaciones se basen exclusivamente en los tests de penetración. Pese a no ser del todo efectivo, si las circunstancias no permiten acceder al código fuente, siempre será mejor realizar un test de penetración que no hacer nada.

Se deben intentar equilibrar las técnicas en las diferentes fases de desarrollo, tes- teando el máximo de campos posibles y lo antes posible. Durante la fase de desarrollo típicamente se realizan más esfuerzos en algunas áreas que en otras. La figura3.4 muestra la proporcionalidad entre las diferentes áreas. De este diagrama se puede concluir que, si donde se realizan más esfuerzos es durante la fase de definición, diseño y desarrollo, sería lógico realizar algunos tests durante estas fases, ya que un fallo que provoque rehacerlas o modificarlas implicaría un coste muy elevado.

Un ejemplo de diagrama sobre el esfuerzo que se debe aplicar a las diferentes técni- cas es el mostrado en la figura3.5.

Las inspecciones manuales se pueden realizar en fases muy tempranas del SDLC, por ello es conveniente invertir gran parte de los recursos que se disponen en ellos. Estas técnicas nos permitirán ahorrar costes a largo plazo.

(34)

Figura 3.4: Diagrama de esfuerzo del SDLC

Figura 3.5: Proporción de técnicas de testing

26

(35)

3.3. Ejemplo de buen programa de testing

3.3.1 Claves para un buen programa de testing

Cuando se afronta el problema de securizar una aplicación es necesario tener un buen programa, un guión que seguir para optimizar y saber qué se debe hacer y qué se ha hecho. Una estrategia adecuada nos permitirá integrar el testing dentro del diagrama de desarrollo del software.

A continuación se explicarán algunas claves que se deben contemplar para desarrollar un buen programa de testing según OWASP.

Definir los objetivos

No se debe testear sin sentido y cualquier cosa, si se sabe qué se quiere conseguir se podrá conseguir, de otra manera no se sabrá qué se ha conseguido y qué no.

Típicamente se considera proveer confidencialidad, integridad y disponibilidad como los objetivos principales. No obstante existen otros objetivos posibles como asegurarse que los controles de seguridad están implementados de manera correcta, o solventar las diferentes amenazas posibles encontradas usando lo explicado en el apartado3.1.1-Análisis de las amenazas.

Documentar los requisitos de seguridad

Cada aplicación tendrá unos requisitos de seguridad propios y únicos. Así, es de una importancia capital entender los requisitos de la aplicación para obtener una información de alto nivel sobre los requisitos de seguridad de la misma.

Una buena manera de documentar consiste en realizar unachecklistcon las regulaciones aplicables, los estándares usados y las políticas que afectan a la aplicación. Gracias a esta lista muchos requisitos saldrán a la luz. Dicho lo anterior, elaborar otra lista con los requisitos de seguridad sobre la funcionalidad del proyecto permitirá ajustar más la seguridad. Por ejemplo, exigir una complejidad mínima para las claves de los usuarios, como podría ser una longitud mínima.

Si existe una buena documentación de los requisitos, la implementación será más sencilla.

Validar los requisitos de seguridad

Al implementar la seguridad pueden existir algunos fallos o vacíos que no se hayan tenido en cuenta. El objetivo principal de la securización de la información es identificar estos vacíos en los controles, ya sean carencias en la autenticación, autorización o cifrado. Si se trata el tema con más detalle se puede considerar la evaluación de los riesgos, por ejemplo, la identificación de vulnerabilidades potenciales que afecten a la integridad y confidencialidad de los datos.

Existen varias herramientas para validar los requisitos, por ejemplo el modelaje de las amenazas durante el diseño. La validación se puede realizar en diferentes fases del SDLC, por ello es importante documentar las diferentes vulnerabilidades encontradas. Solo de esta manera se podrán revisar y validar en un futuro.

Clasificar las amenazas y las contramedidas

Las vulnerabilidades en una aplicación se pueden producir por causas muy diferentes y las maneras de solventarlas también pueden ser muy dispares. Es recomendable clasificar estas amenazas, por ejemplo, en base a su naturaleza

(36)

(Spoofing, denegación de servicio, elevación de privilegios...).

Microsoft desarrolló un ejemplo de categorización de amenazas,Cheat Sheet:

Web Application Security Frame[25] que, pese a no mantener el proyecto, puede ser muy útil para realizar una primera clasificación.

Analizar los riesgos y las técnicas de seguridad.

Además de existir multitud de riesgos diferentes y de múltiple naturaleza, no todos afectan de la misma manera al sistema. Unos pueden comprometer el sistema entero, otros una pequeña parte no excesivamente importante, o tener un impacto moderado. Si se analizan los riesgos que se tienen se pueden priorizar los de mayor gravedad.

Al conocer los riesgos que se pueden producir se puede actuar de manera más eficaz analizando qué técnica aplicar para poder descubrir y mitigar las consecuencias de una posible explotación del fallo.

28

(37)

C

APÍTULO

4

A PLICACIÓN DE L A M ^ETODOLOGÍA OWASP ^A

LOS DIFERENTES TIPOS DE ATAQUE DE

OWASP T ^OP 10

OWASP[26] (OpenWebAplicationSecurityProtocol) es una organización colaborativa sin ánimo de lucro dedicada a la seguridad web. Sin embargo, no es una organización más, destaca por un fuerte código ético y los principios en los que se basa.

OWASP nació en el año 2001 [27] en los Estados Unidos, pero hoy en día y gracias a su filosofía tan abierta se ha convertido en una organización internacional con co- laboradores alrededor del mundo y un referente para el desarrollo de software [28].

Esta proyección internacional es fruto de la capacidad de poner toda su información pública, la facilidad para colaborar en la misma y la calidad de herramientas libres desarrolladas de manera cooperativa por los miembros de la asociación.

4.1 Metodología OWASP

OWASP es una organización muy transversal, como tal establece metodologías para la securización de aplicaciones web en todo el ámbito del ciclo de desarrollo del software.

Todo lo explicado en la sección 3-Testing de aplicaciones webestá basado en la guía de testing de OWASP [20]. Por lo tanto forma parte de la metodología de OWASP, pero no es la única, existen más referencias. Por ejemplo una guía completa para desarrolladores, además de varios artículos de menor tamaño que complementan a estos dos.

4.2 OWASP TOP10

Llegados a este punto del trabajo se debe tener una idea amplia de lo que significa testing, por qué es importante y cómo identificar amenazas. Sin embargo, OWASP

(38)

4. APLICACIÓN DE LA METODOLOGÍA ENOWASP TOP10

realiza periódicamente un estudio de las vulnerabilidades más comunes en la red, este estudio es conocido como elOWASP TOP 10[29]. Es necesario darle a este estudio la importancia que merece. Si analizamos los riesgos de estos ataques es muy probable que sean al menos, alto. Además de fácilmente identificables y explotables.

Por este motivo a lo largo de lo que queda de trabajo se simularan técnicas de pentesting (Explicadas en la sección3.2-Técnicas) para estudiar el funcionamiento de estas vulnerabilidades y realizar un estudio de la amenaza que suponen. Finalmente, se propondrá mínimo una solución para cada una de las vulnerabilidades.

Para poner a prueba e ilustrar las diez vulnerabilidades derivadas del documento OWASP Top 10 ha sido necesaria la creación de un laboratorio para el mismo. Cabe destacar que la mayoría de las pruebas se han realizado de manera local mediante el navegador Mozilla Firefox, usando el framework XAMPP y diversas herramientas como WebGoat o ZAP. Es importante mencionar que se ha intentado utilizar la mayoría de herramientas externas ofrecidas por OWASP para poder establecer el laboratorio.

La idea inicial era usar WebGoat, ya que debería estar diseñado específicamente para esta tarea. Sin embargo, debido a sus limitaciones y fallos, finalmente se ha optado por desarrollar o modificar aplicaciones de proyectos anteriores. De esta manera se ha podido ilustrar como un mal desarrollo de software, obviando todas las fases de testing y la metodología explicada anteriormente son causa directa de vulnerabilidades.

Además, en algunos casos se ha usado el laboratorio provisto por Offensive Security en el curso OSCP.

Todos los ataques han sido realizados en un entorno controlado y privado, en ningún caso se ha puesto en riesgo o se ha atacado ningún servicio externo o sin consentimiento expreso. Los detalles que se mencionarán a continuación tienen pu- ramente un objetivo académico y en ningún caso debe usarse esta información para atacar servicios externos.

Las pruebas de ahora en adelante son pruebas que responden a un vector de ataque en concreto y una vulnerabilidad en concreto. Una vez conseguido el objetivo, explotar la vulnerabilidad explicada, se ha detenido la fase de explotación. Debido a esto, solo se mostrará el impacto mínimo derivado de estas vulnerabilidades, es decir, con una combinación de técnicas de hacking a diversas vulnerabilidades se pueden llegar a conseguir fases de explotación mucho más avanzadas, como ejecución de código malicioso, elevación de privilegios, o denegación de servicio. Estos son solo ejemplos de aplicaciones vulnerables, las vulnerabilidades pueden ser explotadas de múltiples maneras haciendo imposible abarcar todas las maneras de explotación de cada una de estas vulnerabilidades.

Las vulnerabilidades se mostrarán de menor importancia a mayor. El resumen de la lista es la mostrada en la tabla4.1

30

(39)

4.3. T10 - Redirecciones y envíos no validados

OWASP TOP 10 T1 – Inyección

T2 – Errores en la autenticación y la gestión de la sesión T3 – Secuencia de comandos en sitios cruzados (XSS) T4 – Referencia directa insegura a objetos

T5 – Configuración incorrecta de seguridad T6 – Exposición de datos sensibles

T7 – Inexistente Control de Acceso a nivel de funcionalidades T8 – Falsificación de peticiones en sitios cruzados (CSRF) T9 -Uso de componentes con vulnerabilidades conocidas T10 – Redirecciones y envíos no validados

Cuadro 4.1: OWASP TOP 10 2013

4.3 T10 - Redirecciones y envíos no validados

OWASP TOP10 plantea como una de las principales vulnerabilidades las redirecciones y reenvíos no validados. Esto quiere decir que una aplicación web realiza una redirección sin validar donde se está reenviando al usuario.

Suponiendo el escenario de la figura4.1), que es con el que se trabajará en el ejemplo:

Un usuario navega a través de una aplicación web que dispone de varias páginas donde realizar ellogin. Al existir varios lugares donde hacer ellogin, es común que una vez realizado ellogin, la aplicación redirija a la dirección anterior. Si se consigue alterar esta dirección, llevando al usuario a otra aplicación con el mismo aspecto, es probable que piense que ha realizado elloginde manera incorrecta y vuelva a introducir sus credenciales, depositando sus credenciales en un sitio no seguro. Una vez los datos han sido robado, el sitio web malicioso vuelve a redirigir al original, pero como el usuario ya ha introducido sus credenciales, a simple vista cree que todo ha ido bien.

Los dos grandes problemas de este ataque son: se explota la confianza del usuario en la aplicación web original y el segundo es que, a menos que el usuario esté completamente seguro de haber introducido correctamente sus credenciales es prácticamente imperceptible por el usuario.

4.3.1 Ejemplo de ataque

Como se ha mencionado anteriormente, se trabajará en el escenario de una aplicación web, con un formulario deLog Inque puede redirigir a una ruta anterior mediante un parámetro en la URL. La figura4.2muestra como existe el parámetroreden la URL.

Este parámetro indica donde se redirigirá al usuario una vez se realice ellogin.

Un atacante prepara unsite, con unfront-endclonado ver figura4.3) sin embargo, elback-endmodificado. El proposito de estesitees que realizar elloginse guarde la información en una base de datos y se redirija alsiteoriginal. En la figura4.4se puede ver como se ha preparado elsitemalicioso.

Un atacante podría modificar la URL y enviarla a un usuario, alterando el redirec- cionamiento alsitemalicioso. En este caso solo se tendría que enviar la siguiente URL

(40)

Figura 4.1: T10 - Esquema de la vulnerabilidad

Figura 4.2: T10 - Pantalla delogin

al usuario (ver figura4.5):

http : / / l o c a l h o s t / top10 /10/ index . php? red =[ Site_Malicioso ] En el escenario que ejemplifica este ataque:

http : / / l o c a l h o s t / top10 /10/ index . php? red=http : / / l o c a l h o s t / t f g / atack10 / Ocurriría que el usuario accedería a la pantalla delogindelsiteauténtico. Sin embargo, al loguearse, le redirigiría a la aplicación maliciosa, figura4.6. Si no se ha percatado de este cambio, es probable que vuelva a introducir los credenciales, de esta manera el atacante habría robado los credenciales. La figura4.8muestra cómo se han robado los datos.

La figura4.7no vuelve a solicitar ellogin, ya que elloginfue correcto, por lo tanto la sesión se abrió al realizar el inicio de sesión original. Gracias a las sesiones, si el ataque 32

(41)

4.3. T10 - Redirecciones y envíos no validados

Figura 4.3: T10 - Sitio malicioso

Figura 4.4: T10 - Back-End del sitio malicioso

Figura 4.5: T10 -Logincon la redirección modificada

(42)

Figura 4.6: T10 -Logindel lugar malicioso

Figura 4.7: T10 - Redirección al lugar correcto.

Figura 4.8: T10 - Tabla de la Base de Datos con los credenciales robados

34

(43)

4.4. T9 - Uso de componentes con vulnerabilidades conocidas

ha tenido éxito, el usuario no se habrá dado cuenta de que en el transcurso de sulogin las credenciales han sido robadas.

4.3.2 ¿Cómo defenderse?

Una manera efectiva de solventar esta vulnerabilidad es crear una lista de lugares validados a los que realizar una redirección. De esta manera cualquier otra dirección a la que se vaya a redirigir al usuario será bloqueada por la propia aplicación web.

4.4 T9 - Uso de componentes con vulnerabilidades conocidas

Muchas aplicaciones web nuevas se basan o usan aplicaciones ya funcionales, por ejemplo, simplemente al instalar el servidor sobre el cual se va a lanzar la aplicación hay decisiones que tomar. Como se ha explicado anteriormente en el apartado2.2 -Servidor, existen diversos componentes en los que basarnos. Es común usar otras herramientas para ahorrar tiempo y esfuerzo, como podría serWordPress[30],phpBB [31], o librerías de uso público.

El problema reside en cuando se usan componentes que son vulnerables, y estas vulnerabilidades son conocidas, por ejemplo, usar un módulo deOpenSSLcon una versión entre la 1.0.1 y la 1.0.1f es un error, ya que es conocido que son vulnerables al Heartbleed[32]. Además de la multitud de herramientas y dependencias entre ellas, cada una de estas versiones va actualizándose, y puede que la nueva versión introduzca vulnerabilidades, o que corrija fallos de seguridad en las anteriores. Existen listas de exploitsque indican de manera muy precisa, cuál es la vulnerabilidad, en qué versiones está presente y cómo explotarla. Una de estas listas conocidas es Exploit-DB [33].

Por lo tanto, es muy importante estar al día y actualizar todos los componentes de los cuales depende la aplicación web. Esto es bastante más complicado de lo que parece ya que es probable que algunas librerías que se usan en la aplicación web dependan a su vez de otras librerías, además de que pueden existir problemas de compatibilidad al actualizar algunos módulos.

4.4.1 Ejemplo de ataque

Para este ejemplo, se tomará un servidor que está utilizando el programaSLMail, un servidor de correo POP3. Se tomará control del servidor (enviando unashellal atacante) mediante una vulnerabilidad conocida en este programa, concretamente la CVE-2003- 0264[34], pese a lograr el ataque debido a esta vulnerabilidad, no es propósito de este trabajo explicar cómo funciona. El exploit que se usará es el 643 de la lista de Offensive Security [35].

El servidor dispone de la IP: 11.10.4.22 (ver figura4.9), mientras que la IP del atacante es la 11.10.0.213 (ver figura4.10).

A continuación se lanza el exploit, pero previamente se debe poner a escuchar alguna aplicación para recibir lashell, en este casonetcat. La imagen4.11muestra como se pone a escuchar a netcat y como recibe lashelldel atacante. Si se compara

(44)

Figura 4.9: T9 - Muestra de la IP del servidor

Figura 4.10: T9 - Muestra de la IP del atacante

36

Estudio de los ataques contra website. OWASP

T rabajo F in de G ra do

GRAU D’ENGINYERIA TELEMÀTICA