trabajo de grado uso prÁctico de encabezados http para

Trabajo de Grado

USO PRÁCTICO DE ENCABEZADOS HTTP PARA MEJORAR LA SEGURIDAD EN EL PROTOCOLO

Andrés Iván Anturi Figueroa

Universidad de Los Andes

Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación

Bogotá, 2020

2

Trabajo de Grado


Andrés Iván Anturi Figueroa

Asesora

Sandra Julieta Rueda Rodríguez, Ph.D.

Profesora Asociada

Universidad de Los Andes

Facultad de Ingeniería

Departamento de Ingeniería de Sistemas y Computación

Bogotá, 2020

3

TABLA DE CONTENIDO

Resumen .......................................................................................................................................... 5

1 Introducción ........................................................................................................................... 6

2 Descripción del problema ................................................................................................. 8 2.1 Descripción HTTP ...................................................................................................................... 8 2.2 Descripción navegadores ........................................................................................................ 9 2.3 Descripción mensajes HTTP ............................................................................................... 10 2.4 Potenciales ataques web ...................................................................................................... 11

2.4.1 Hombre en el medio: ................................................................................................................... 11 2.4.2 Cross-side scripting - XSS: ......................................................................................................... 11 2.4.3 Cross site framing o Clickjacking: .......................................................................................... 11 2.4.4 Inyección SQL ................................................................................................................................. 11

2.5 Objetivos .................................................................................................................................... 12

3 Propuesta de solución ..................................................................................................... 13 3.1 Diseño: ........................................................................................................................................ 13

3.1.1 Requerimientos funcionales de la herramienta ............................................................... 13 3.1.2 Proyecto base (OWASP Secure Headers) ............................................................................ 13 3.1.3 Flujo de datos ................................................................................................................................. 13

3.2 Definición y descripción de los encabezados propuestos. ....................................... 14

4 Implementación ................................................................................................................. 22 4.1 Aspectos proyecto base (Secure Headers)...................................................................... 22 4.2 Aspectos de desarrollo .......................................................................................................... 23

4.2.1 Implementación de funcionalidad de escaneo de direcciones ................................... 23 4.2.2 Organización del nuevo flujo del programa ....................................................................... 23 4.2.3 Estructuración de los mensajes de consola ....................................................................... 23 4.2.4 Consolidación guía de usuario ................................................................................................. 24

5 Evaluación ............................................................................................................................ 25

6 Trabajo relacionado ......................................................................................................... 28

7 Conclusiones y trabajo futuro ....................................................................................... 36

8 Referencias .......................................................................................................................... 37

9 Anexo 1 .................................................................................................................................. 39

4

INDICE DE FIGURAS

Figura 1. Descripción de alto nivel del protocolo HTTP. [1] ............................................................................................... 8 Figura 2. Componentes generales de los navegadores. [6] .................................................................................................. 9 Figura 3. Estructura mensajes de solicitud HTTP. [1] ........................................................................................................ 10 Figura 4. Estructura mensajes de respuesta HTTP. [1] ..................................................................................................... 10 Figura 5. Flujo de datos en la herramienta. ........................................................................................................................... 14

5

RESUMEN

El protocolo HTTP (HyperText transfer protocol) carece de un esquema de seguridad, aunque cuenta con algunos encabezados de respuesta que ayudan a prevenir ataques como hombre en el medio, XSS, click jacking y SQL injection. Estos encabezados no son conocidos ni adaptados por gran parte de los sitios web, por lo que la fundación OWASP ha desarrollado un proyecto que se enfoca en recolectar datos (estadísticas) de la utilización de estos en los 100 sitios web más importantes con el fin de aumentar la concientización y monitorear las variaciones en su uso.

Basándose en el proyecto de OWASP y en su componente de escaneo, este trabajo presenta una herramienta que le permite a los desarrolladores obtener información acerca de la utilización de los encabezados de respuesta de seguridad en su propia aplicación web. Adicionalmente, esta propuesta presenta tres categorías para guiar al desarrollador en la selección de encabezados más apropiados para sus necesidades. La herramienta más las categorías ayudarán a los desarrolladores a implementar los encabezados de forma correcta y así contribuir en la disminución del riesgo de que ataques, como los que se mencionaron, tengan éxito. Los resultados que esta herramienta presenta, deben ser interpretados con ayuda de la guía del desarrollador anexa a este documento, la cual cuenta con algunas recomendaciones de configuración basadas en tres categorías distinguidas por la sensibilidad de la información que se maneja en cada dirección del sitio web.

El producto final fue evaluado en diferentes escenarios para comprobar su funcionamiento y puede ser encontrado en el siguiente repositorio: https://github.com/1anturi1/secureHeaders

6

1 INTRODUCCIÓN

Aunque los usuarios no sean conscientes de su uso, el protocolo HTTP (HyperText transfer protocol) es uno de los protocolos más usados por todos hoy día; es el protocolo que usan los servidores y navegadores web para enviar y recibir información.

El protocolo HTTP funciona con un esquema de solicitud/respuesta y corre en la capa de aplicación en arquitecturas web. Fue desarrollado para facilitar la distribución de información hipertexto sin consideraciones de seguridad en la trasmisión de los datos. Debido a esta carencia de seguridad en el protocolo, a lo largo del tiempo se han descubierto diferentes vulnerabilidades a las cuales se ha tratado de hacer frente por medio de actualizaciones al protocolo, nuevas prácticas de desarrollo seguras y la extensión del protocolo con la inclusión de algoritmos para manejo de confidencialidad e integridad, dando origen a HTTP Secure. [1]

Sin embargo, a pesar de las diferentes soluciones existentes, en la actualidad sigue existiendo una gran variedad de posibles ataques que, para ser evitados, requieren de concientización y esfuerzo en la etapa de desarrollo.

Según las cifras de Akamai [2], en el periodo entre el 15 de octubre y el 22 de octubre del 2020, se registraron 142.967.788 ataques web a nivel mundial. El método de ataque que más se presentó fue SQL injection con 120.222.334 incidencias, el funcionamiento de este ataque se basa en inyectar un query SQL a través de información de entrada con el fin de leer, modificar o recuperar información de la base de datos. En segundo lugar, está el ataque web cross-site scripting con 18.370.720, que consiste en inyectar scripts maliciosos en sitios web confiables con el fin de que otro usuario final los ejecute (víctima), permitiéndole al script la posibilidad de acceder a cualquier cookie, token de sesión u otra información sensible retenida por el navegador y utilizada en ese sitio. Finalmente, con menor cantidad de incidencias están presentes los ataques Remote file inclusion, PHP injection y command injection.

Ilustración 1. Ataques web ocurridos en el periodo descrito. [2]

Los ataques que más se presentaron en este periodo; sql injection y cross-site scripting, junto con otros, como hombre en el medio o clickjacking, pueden ser prevenidos por medio de una buena configuración y desarrollo, disminuyendo la probabilidad de que datos sensibles sean robados o

7

alterados perjudicando al usuario final, ya sea comprometiendo sus credenciales o infectando su máquina con software malicioso.

Además, según el documento OWASP Top 10 [3], a lo largo de los últimos 10 años los riesgos de inyección SQL, los problemas de autenticación y gestión de sesiones han permanecido en los dos primeros puestos. El cross-site scripting permanece dentro del top junto con la configuración de seguridad incorrecta, esta última hace referencia a la conservación de configuraciones por defecto o incompletas, encabezados HTTP desconfigurados y mensajes de error con información sensible. Lo anterior se puede ver reflejado en la siguiente gráfica.

HTTP cuenta con algunos encabezados de respuesta que permiten reducir el riesgo de que los ataques mencionados sean exitosos. Dichos encabezados deben ser configurados en la fase de desarrollo, pero debido a su poco reconocimiento, existe un déficit de implementación en una extensa variedad de sitios web [4]. Si bien en el presente se pueden encontrar herramientas que escanean y visibilizan el uso de los encabezados de seguridad de respuesta [5], estas no están enfocadas en demostrar su importancia en el esquema de seguridad de la información ni en orientar la implementación correcta de los mismos. Es clave contar con una configuración adecuada de estos encabezados ya que declaran mecanismos y políticas estrictas de seguridad en el protocolo HTTP previniendo los ataques mencionados con anterioridad.

Por lo anterior, este trabajo propone el diseño e implementación de una herramienta que permita a los desarrolladores conocer cuáles encabezados HTTP están implementados en su aplicación web, cuáles no, y cuáles deberían integrar basándose en sus necesidades de negocio, con el objeto de mitigar el riesgo de posibles ataques web e incrementar la seguridad en sus proyectos.

1

2

3

4

5

6

7

8

2013 2017 2020

Po

sici

ón

Año

Variación de posiciones en OWASP Top 10 de ataques web

Injección SQL

Cross-site Scripting

Pérdida de autenticacióny gestion de sesiones

Configuración deseguridad incorrecta

8

2 DESCRIPCIÓN DEL PROBLEMA

2.1 Descripción HTTP

En primer lugar, para poder entender bien la raíz del problema es necesario conocer cómo funciona el protocolo HTTP y cómo se desenvuelve en temas de seguridad.

HyperText Transfer Protocolo es considerado el corazón de la web, está definido en [RFC 1945] y [RFC 2616] y es implementado en dos programas ejecutados en diferentes sistemas: un programa cliente y un programa servidor, que se comunican intercambiando mensajes HTTP. La estructura de estos mensajes la define HTTP junto con la forma en la que el cliente y el servidor los intercambian. Cuando el usuario solicita una página web, el navegador envía un mensaje solicitando los objetos al servidor, el servidor recibe la solicitud y envía un mensaje de respuesta HTTP que contiene estos objetos, el navegador los recibe y los interpreta para el usuario final. HTTP utiliza como base el protocolo TCP, por lo que el cliente HTTP primero inicia una conexión TCP con el servidor y una vez es establecida, el cliente y el servidor procesan el acceso TCP a través de sus interfaces de conexión. Funcionar sobre TCP, le permite a HTTP no preocuparse acerca de la pérdida de información en la transmisión, dado que TCP se recupera de la pérdida o reorganiza la información dentro de la red.

Figura 1. Descripción de alto nivel del protocolo HTTP. [1]

Un servidor HTTP no conserva información acerca de los clientes, por lo que HTTP es considerado un protocolo sin estado o “stateless”. Por lo anterior, para poder identificar a los usuarios, restringir su acceso o brindar información personalizada, HTTP implementa el uso de cookies, lo que permite a los sitios web seguir el rastro de los usuarios. Una cookie es un archivo de poco

9

tamaño que almacena datos sobre una sesión de usuario; datos como login e identificador de sesión. Estas cookies son almacenadas en el cliente, mientras el servidor almacena información extendida que permite mantener el estado de la sesión del usuario. Se establecen por medio del encabezado Set-cookie la primera vez que el cliente se conecta al sitio web y son enviadas a través del encabezado Cookie una vez son acordadas.

2.2 Descripción navegadores

Ahora, es necesario conocer un poco cómo funcionan los clientes que participan en este intercambio de mensajes con el servidor, los navegadores. Los componentes básicos de los navegadores son:

• Interfaz de usuario: Son todas las partes visibles en la aplicación del navegador, exceptuando la ventana donde se muestra la página que se solicita.

• Motor de búsqueda: Gestiona la comunicación entre la interfaz de usuario y el motor de renderización

• Motor de renderización: Es el encargado de presentar al usuario el contenido que se solicita.

• Red: Es responsable de realizar las solicitudes HTTP y demás llamadas de red.

• Servidor de la interfaz: Usa métodos de la interfaz de usuario del SO en segundo plano y permite presentar algunos widgets básicos.

• Intérprete de JavaScript: Se encarga de analizar y ejecutar el código JavaScript.

• Almacenamiento de datos: Es una capa de persistencia ligera.

Figura 2. Componentes generales de los navegadores. [6]

En la Figura 2 se representan los componentes de los navegadores y las conexiones entre ellos. Teniendo lo anterior presente, el flujo básico de funcionamiento del navegador inicia con la solicitud que realiza la capa de red, esta le envía el resultado al motor de renderización, el cuál analiza el documento HTML, analiza los datos de estilo, determina los lugares de la pantalla en donde debe aparecer cada elemento y pinta utilizando el servidor de la interfaz de usuario. [6]

10

Los navegadores suelen ser programas complejos ya que gestionan diversos tipos de archivos y mantienen datos privados como cookies o el historial, lo que causa que existan múltiples posibles ataques apalancados por los datos que manejan, ya que estos despiertan el interés de los atacantes.

2.3 Descripción mensajes HTTP

Ahora bien, es necesario conocer la estructura de los mensajes de solicitud y respuesta utilizados en el protocolo, ya que es por medio de estos elementos que se intercambian los datos entre el cliente y el servidor y suelen ser el objetivo de los atacantes. La estructura de los mensajes de solicitud cuenta con tres secciones; una línea de petición o solicitud donde se indica el tipo de comando (GET, POST, HEAD, etc.), las líneas de encabezado y el final de las líneas de encabezados, dependiendo del tipo de comando puede estar presente otra sección la cual contiene el cuerpo de la entidad [1]:

Figura 3. Estructura mensajes de solicitud HTTP. [1]

En cuanto a los mensajes de respuesta, también se cuenta con tres secciones; una línea de estado inicial donde aparecen los códigos de respuesta (indican si se ha completado la solicitud), las líneas de encabezados y el cuerpo de la entidad que contiene los objetos solicitados [1]:

Figura 4. Estructura mensajes de respuesta HTTP. [1]

Los encabezados que viajan en estos mensajes le permiten al cliente y al servidor adicionar información esencial acerca de la transacción en curso, ya sea petición o respuesta. Dependiendo del tipo de encabezado, estos pueden contener información sobre el contenido que se va a obtener o sobre el cliente, información más detallada sobre el contenido (como el origen de este) e información detallada sobre el cuerpo de la identidad (como el tamaño). Entre demás funcionalidades, en los encabezados de respuesta se pueden establecer parámetros que restrinjan

11

a los navegadores y eviten algunas vulnerabilidades. Sin embargo, los desarrolladores no suelen ser conscientes del potencial uso de los encabezados para robustecer la seguridad, dejando la puerta abierta a ataques como los que se definen en la siguiente sección.

2.4 Potenciales ataques web

2.4.1 Hombre en el medio:

Según [7], el ataque de hombre en el medio consiste en interceptar la comunicación entre dos sistemas. Por ejemplo, en HTTP el objetivo es la conexión TCP entre el cliente y servidor. A través de diferentes técnicas, el atacante divide la conexión TCP original en 2 nuevas, una entre el cliente y el atacante y otra entre el atacante y el servidor. Una vez la conexión es interceptada, el atacante actúa como un proxy, siendo capaz de leer, insertar y modificar la información en la conexión.

2.4.2 Cross-side scripting - XSS:

Según [8], el ataque de inyección cruzada (cross-side scripting, XSS) consiste en inyectar scripts maliciosos en sitios web benignos y confiables. Este ataque sucede cuando un atacante usa una aplicación web como medio para enviar código malicioso, generalmente en forma de script, a un usuario final diferente. El navegador del usuario final no tiene forma de saber si el script es de confianza o no, así que lo ejecutará y le permitirá al script la posibilidad de acceder a cualquier cookie, token de sesión u otra información sensible retenida por el navegador y utilizada en ese sitio.

2.4.3 Cross site framing o Clickjacking:

Según [9], el Clickjaking es cuando un atacante utiliza múltiples capas transparentes en un documento HTML para engañar a un usuario y que éste haga clic en un botón o enlace a otra página, cuando él tenía la intención de hacer clic en la página de nivel superior. De esta manera, el atacante está “secuestrando” los clics destinados a su página y destinándolos a otra página, muy probablemente propiedad de otra aplicación dominio o ambos. Utilizando una técnica similar, las pulsaciones de teclas también pueden ser secuestradas. Con una combinación cuidadosamente elaborada de hojas de estilo, iframes y cuadros de texto, se puede inducir a un usuario a creer que está escribiendo la contraseña de su correo electrónico o cuenta bancaria, pero en cambio está escribiendo en un marco invisible controlado por el atacante.

2.4.4 Inyección SQL

Como menciona [10], el ataque de inyección de SQL consiste en la inserción o “inyección” de un query SQL a través de la información de entrada, desde el cliente hacia la aplicación, con el objetivo de que este query sea ejecutado. Un exploit de inyección SQL exitoso puede leer datos sensibles, modificar la información de la base de datos, ejecutar operaciones de administración en la base de datos, recuperar el contenido de un archivo presente en el sistema de archivos del

12

SGBD (sistema de gestión de bases de datos) y en algunos casos emitir comandos al sistema operativo.

Cuando se despliega un servicio web se debe tener en cuenta que el riesgo de ser atacado es muy alto y la probabilidad de que estos ataques sean exitosos depende en gran medida del nivel de prevención que se decida implementar. Si bien existen herramientas de prevención que son costosas o complicadas de implementar, también existen otras que están a la mano de todos los desarrolladores y resultan efectivas, como lo es la configuración apropiada de los encabezados de respuesta HTTP, los cuales contribuyen a la disminución del riesgo de que ataques como los que se definieron con anterioridad ocurran. Aun así, estos encabezados no suelen ser tenidos en cuenta a la hora de fortalecer la seguridad de un sitio web y es porque pocos desarrolladores conocen su verdadero potencial. Es por esto que el presente proyecto tiene los siguientes objetivos.

2.5 Objetivos

General

Guiar a los desarrolladores en la implementación de los encabezados HTTP de respuesta de seguridad, realizando un escaneo y generando un reporte que les ayudará a determinar cuáles encabezados le hacen falta por adicionar y cuáles ya están funcionando correctamente.

Específicos

• Diseñar e implementar una herramienta, basada en el proyecto de OWASP, que escanea los encabezados en las respuestas HTTP de una aplicación web y genera un reporte que enuncia aquellos que están siendo utilizados junto con sus respectivos valores.

• Desarrollar una guía clara y concisa de la instalación y utilización de la herramienta.

• Desarrollar una guía, que señale los mejores escenarios de uso de los encabezados para que los desarrolladores los puedan usar de acuerdo con sus necesidades.

13

3 PROPUESTA DE SOLUCIÓN

Este capítulo presenta entonces la propuesta de solución al problema planteado en el capítulo anterior, la cual consiste en el desarrollo de una herramienta que le permitirá al desarrollador visualizar y analizar la utilización de los encabezados de seguridad en su aplicación web. Esta propuesta, extiende el proyecto “Security Headers” de OWASP. 1

En las siguientes secciones se presenta el diseño de la solución y la descripción de los encabezados que tiene en cuenta la herramienta para el fortalecimiento de la seguridad en su escaneo.

3.1 Diseño:

3.1.1 Requerimientos funcionales de la herramienta

• Establecer el sitio y direcciones a explorar. La herramienta extrae y reúne las diferentes direcciones del sitio web que escaneará. El usuario debe de ingresar la URL del sitio web en cuestión y la herramienta inicia el proceso de inspección de direcciones.

• Análisis del sitio y sus direcciones. Una vez la herramienta recolecta las direcciones, realiza peticiones HTTP a cada una de ellas y analiza los encabezados de los mensajes de respuesta que envía el servidor.

• Generación del reporte de uso de encabezados. Cuando la herramienta finaliza el análisis, genera un reporte en consola sobre la utilización de los encabezados de seguridad en cada una de las direcciones del sitio web.

3.1.2 Proyecto base (OWASP Secure Headers)

Para el desarrollo de la herramienta propuesta se utilizó como base y guía el proyecto “OWASP Secure Headers” [11] el cual describe los encabezados de respuesta HTTP que las aplicaciones pueden utilizar para aumentar la seguridad, con el fin de aumentar la conciencia y el uso de estos encabezados por medio de la publicación de informes sobre las estadísticas de uso, los desarrollos y los cambios. Por lo anterior, este proyecto cuenta con un componente de escaneo, un componente de visualización web, una base de datos donde se va almacenando la información y una lista de los sitios web más famosos a los que se les realiza el estudio.

Sin embargo, el objetivo del presente proyecto está enfocado en orientar a los desarrolladores en el uso de estos encabezados en sus propias aplicaciones, más no en generar estadísticas de uso de otros sitios web. Lo anterior por medio de una herramienta liviana y fácil de usar que le permite al desarrollador conocer cuáles encabezados está utilizando, cuáles no y cuáles debería de usar. Teniendo en cuenta lo anterior, se ha establecido un diseño de funcionamiento presente en la siguiente sección.

3.1.3 Flujo de datos

1 The open web application security Project (OWASP) es una fundación sin ánimo de lucro cuyo objetivo es mejorar la seguridad del software a través de conferencias y proyectos de código abierto dirigidos por una comunidad conformada por miles de miembros alrededor del mundo.

14

En la Figura 5 se encuentran los 3 componentes principales del proceso de escaneo; el actor “A” es la herramienta que escanea los encabezados de seguridad desarrollada en este trabajo, el componente “B” es el sitio el cual está siendo modificado por el tercer componente, el desarrollador. En el paso 1, el desarrollador descargar la herramienta, sigue los pasos de instalación adjuntos, ejecuta la aplicación e ingresa la URL en donde actualmente está corriendo el sitio web al que desea que se le sea realizado el escaneo. En el paso 2, el componente A realiza una solicitud HTTP inicial al componente B y extrae del documento HTML de respuesta las diferentes direcciones a las cuales se hace referencia desde la página de inicio. Una vez el componente A dispone de las direcciones disponibles, en el paso 3 éste realiza peticiones a cada una de ellas utilizando un pool de threads y analiza los encabezados de cada respuesta obtenida. Luego, en el paso 4 el actor A hace entrega de un reporte de utilización de los encabezados propuestos al desarrollador, el cual, en el paso 5, realiza las modificaciones que considere necesarias en el componente B para fortalecer la seguridad con la que se cuenta.

Figura 5. Flujo de datos en la herramienta.

3.2 Definición y descripción de los encabezados propuestos.

En la wiki del proyecto base utilizado [11] se encuentran las siguientes descripciones de los encabezados pertinentes.

• HTTP Strict Transport Security (HSTS):

HSTS es mecanismo de política de seguridad web que ayuda a proteger los sitios web contra los ataques de degradación de protocolo y el secuestro de cookies. Este mecanismo les permite a los servidores web determinar que los navegadores sólo pueden interactuar con él utilizando conexiones HTTPS seguras y no sobre HTTP inseguro. HSTS es un protocolo de seguimiento de estándares del IETF y está especificado en el RFC 6797.

Para implementar una política HSTS, un servidor suministra un encabezado (Strict-Transport-Security) sobre una conexión HTTPS, ya que los encabezados sobre HSTS sobre HTTP son ignorados.

15

Valor Descripción

max-age=SECONDS El tiempo en segundos que el navegador recuerda que este sitio es solamente visitado utilizando HTTPS.

includeSubDomains Si este parámetro opcional es especificado, esta regla se aplica a todos los subdominios.

• Public Key Pinning Extension for HTTP (HPKP):

HPKP es un mecanismo de seguridad que le permite a los sitios web que trabajan sobre HTTPS resistirse a la suplantación de identidad por parte de los atacantes que utilizan certificados fraudulentos o mal emitidos.

El servidor web HTTPS sirve una lista de hashes de claves públicas, y en las conexiones posteriores los clientes esperan que ese servidor utilice una o más de esas claves públicas en su cadena de certificados. El despliegue seguro de HPKP requerirá madurez operacional y organizativa debido al riesgo de que los hosts puedan quedar indisponibles al fijar un conjunto de hashes de clave pública que se vuelva inválido. Con cuidado, los operadores de los hosts pueden reducir en gran medida el riesgo de ataques de tipo "hombre en el medio" (MITM) y otros problemas de autenticación falsa para sus usuarios sin incurrir en un riesgo indebido.

Valor Descripción

pin-sha256="<sha256>" La cadena de caracteres entre comillas es la huella dactilar de la información de clave pública del sujeto (SubjectPublicKeyInfo) codificada en base 64. Es posible especificar múltiples pines para diferentes claves públicas.

max-age=SECONDS El tiempo en segundos que el navegador recuerda que este sitio es solamente visitado utilizando una de las llaves.

includeSubDomains Si este parámetro opcional es especificado, esta regla se aplica a todos los subdominios.

report-uri="<URL>" Si este parámetro opcional es especificado, si la validación del pin falla es reportada a la URL dada.

• X-Frame-Options:

Este encabezado de respuesta mejora la protección de las aplicaciones web en contra del Clickjacking, declarando una política comunicada desde un host al navegador del cliente acerca de si debe mostrar o no el contenido transmitido en marcos de otras páginas web.

Valor Descripción

Deny No hay renderización dentro de un cuadro.

Sameorigin No hay renderización si el origen no coincide.

Allow-from: DOMAIN Permite el renderizado si está enmarcado en un cuadro cargado desde el dominio.

16

• X-XSS-Protection:

Este encabezado habilita el filtro de Cross-site scripting (XSS) en el navegador.

Valor Descripción

0 Filtro deshabilitado.

1 Filtro habilitado. Si se detecta un ataque XSS el navegador desinfectará la página.

1; mode=block Filtro habilitado. Al detectar un ataque XSS, el navegador en vez de desinfectar, bloqueará la reproducción de la página.

1; report=http://[YOURDOMAIN]/your_report_URI

Filtro habilitado. El navegador desinfectará la página e informará acerca de la violación. Esta es una función de Chromium que utiliza los informes de violación de CSP para enviar los detalles a una URI de su elección.

• X-Content-Type-Options:

Configurar este encabezado evitará que el navegador interprete los archivos como algo más que lo declarado por el tipo de contenido en los encabezados HTTP.

Valor Descripción

nosniff No permitirá que el navegador detecte una respuesta alejada del tipo de contenido declarado.

• Content-Security-Policy (CSP):

Este encabezado proporciona una política de seguridad de contenidos, requiere un ajuste cuidadoso y una definición concisa de la política. Si es activado, CSP tiene un significante impacto en la manera en que los navegadores renderizan las páginas, previniendo una gran variedad de ataques como XSS y otros tipos de inyecciones cross-site.

Valores:

Directiva Descripción

base-uri Define la uri base para la uri relativa.

default-src Define la política de carga para todos los tipos de recursos en caso de que no se haya definido una directiva dedicada a cada tipo de recurso (fallback).

script-src Define cuáles scripts puede ejecutar el recurso protegido.

object-src Define desde donde el recurso protegido puede cargar plugins.

style-src Define cuáles estilos (CSS) el usuario aplica al recurso protegido.

img-src Define desde donde el recurso protegido puede cargar imágenes.

17

media-src Define desde donde el recurso protegido puede cargar audio y video.

frame-src Desaprobado y remplazado por child-src. Define de donde el recurso protegido puede incrustar marcos.

child-src Define de donde se el recurso protegido puede incrustar marcos.

frame-ancestors Define desde dónde se puede incrustar el recurso protegido en los marcos.

font-src Define desde dónde el recurso protegido puede cargar fuentes.

connect-src Define cuáles URIs el recurso protegido puede cargar utilizando interfaces de script.

manifest-src Define desde dónde se el recurso protegido puede cargar el manifiesto.

form-action Define cuáles URIs pueden ser utilizadas como la acción de los elementos del formulario HTML.

sandbox Específica una política HTML sandbox que el usuario agente aplica al recurso protegido.

script-nonce Define la ejecución de scripts requiriendo la presencia de los elementos del script del nonce especificado.

plugin-types

Define el conjunto de plugins que pueden ser llamados por el recurso protegido limitando los tipos de recursos que pueden ser incrustados.

reflected-xss

Instruye a un agente usuario para activar o desactivar cualquier heurística utilizada para filtrar o bloquear los ataques XSS, es equivalente a los efectos del encabezado no estándar X-XSS-Protection.

block-all-mixed-content Previene al usuario agente a cargar contenido mixto.

upgrade-insecure-requests Instruye al agente usuario para descargar recursos inseguros utilizando HTTPS.

referrer Define la información que el agente usuario debe enviar en el encabezado Referer.

report-uri Especifica una URI a la cual el agente usuario envía reportes acerca de la violación de políticas.

report-to Especifica un grupo al cual el agente usuario envía reportes acerca de la violación de políticas.

• X-Permitted-Cross-Domain-Policies

Un archivo de política de dominio cruzado es un documento XML que otorga a un cliente web permisos para manejar información a través de los dominios. Cuando los clientes solicitan contenido alojado en un dominio de origen determinado y ese contenido hace solicitudes dirigidas

18

a un dominio distinto del suyo, el dominio remoto necesita alojar un archivo de política de dominio cruzado que otorgue acceso al dominio de origen, permitiendo al cliente continuar con la transacción. Normalmente una meta política es declarada el archivo maestro de políticas, pero para aquellos que no pueden escribir en un directorio root, pueden también declarar una meta política utilizando el encabezado de respuesta HTTP X-Permitted-Cross-Domain-Policies.

Valores Descripción

none No hay archivos de políticas permitidos en el servidor objetivo, incluyendo el archivo maestro de políticas.

master-only Solo el archivo maestro de políticas es permitido.

by-content-type Solo se permiten los archivos de políticas servidos con Content-Type: text/x-cross-domain-policy. [Solamente HTTP/HTTPS]

by-ftp-filename Solamente se permiten los archivos de políticas cuyos nombres de archivo sean crossdomain.xml (es decir, las URL que terminan en /crossdomain.xml).

all Todos los archivos de políticas en el dominio de destino son permitidos.

• Referrer-Policy

Este encabezado rige qué información de remisión debe ser incluida en las peticiones realizadas.


no-referrer El encabezado es omitido completamente, no se envía ninguna información de remisión en las peticiones.

no-referrer-when-downgrade

Este es el comportamiento por defecto del agente de usuario si no se especifica una política. El origen se envía como referencia a un destino a-priori priori hacia el más seguro (HTTPS->HTTPS), pero no se envía a un destino menos seguro (HTTPS->HTTP).

origin Sólo envía el origen del documento como el remitente en todos los casos. El documento https://example.com/page.html enviará el remitente https://example.com/.

origin-when-cross-origin Envía una URL completa cuando realiza una solicitud del mismo origen, pero sólo envía el origen del documento para otros casos.

same-origin Se envía un remitente para los mismos orígenes, pero las solicitudes de origen cruzado no contendrán información sobre el remitente.

strict-origin Sólo envía el origen del documento como referencia a un destino a-priori hacia el más seguro (HTTPS->HTTPS), pero no se envía a un destino menos seguro (HTTPS->HTTP).

19

strict-origin-when-cross-origin

Envía una URL complete cuando se ejecuta una petición al mismo origen. Sólo envía el origen del documento como referencia a un destino a-priori priori hacia el más seguro (HTTPS->HTTPS), pero no se envía a un destino menos seguro (HTTPS->HTTP).

unsafe-url Envía una URL completa (sin parámetros) cuando se realiza una solicitud del mismo origen o de origen cruzado.

• Expect-CT

Este encabezado es utilizado por un servidor para indicar que los navegadores deben evaluar las conexiones con el host que emite el encabezado para el cumplimiento de la transparencia de los certificados (Certificate transparency, CT).


report-uri Es una directiva opcional que indica la URL a la que el navegador debe reportar los fallos del Expect-CT.

enforce Es una directiva de aplicación opcional sin valor que, si está presente, indica al navegador que debe aplicarse el cumplimiento de la política de CT (en lugar de sólo informar) y que el navegador debe rechazar las conexiones futuras que violen su política de CT. Cuando están presentes tanto la directiva de aplicación como la de informar, la configuración se denomina configuración de "aplicación e informe", lo que indica al navegador que se debe aplicar la política de CT y que se deben informar las violaciones.

max-age Esta directiva especifica el número de segundos después de la recepción del campo del encabezado expect-CT durante los cuales el navegador debe considerar al anfitrión de quien se recibió el mensaje como un anfitrión conocido de expect-CT.

• Feature-Policy

Este encabezado permite a los desarrolladores habilitar o deshabilitar selectivamente el uso de varias funciones o APIs del navegador.


accelerometer Controla el acceso a los sensores de acelerómetro del dispositivo.

ambient-light-sensor Controla el acceso a los sensores de luz ambiental del dispositivo.

Autoplay Controla el acceso a la reproducción automática.

Camera Controla el acceso a los dispositivos de entrada de video.

20

encrypted-media Controla si requestMediaKeySystemAccess() está permitida.

Fullscreen Controla si requestFullscreen() está permitida.

Geolocation Controla el acceso a la interfaz de geolocalización.

Gyroscope Controla el acceso a los sensores de giroscopio del dispositivo

magnetometer Controla el acceso a los sensores del magnetómetro del dispositivo

microphone Controla el acceso a los dispositivos de entrada de audio.

Midi Controla el acceso al método requestMIDIAccess().

Payment Controla el acceso a la interfaz de solicitud de pago.

picture-in-picture Controla el acceso a imagen en imagen.

Speaker Controla el acceso a los dispositivos de salida de audio.

Usb Controla el acceso a los dispositivos USB.

Vibrate Controla el acceso al método vibrate().

Vr Controla el acceso a las pantallas de RV.

Ahora bien, teniendo en cuenta el funcionamiento y la utilidad de estos encabezados, es evidente su contribución a la seguridad y cobra sentido su implementación en las aplicaciones web. Por lo tanto, se ha consolidado una guía de usuario (véase Anexo 1) que le permitirá al desarrollador interpretar los resultados arrojados por la herramienta y lo orientará en la incorporación de los encabezados de seguridad en cada dirección de su sitio web, basándose en tres categorías. Estás categorías se distinguen entre sí por la sensibilidad de la información que manejan las direcciones. Las categorías propuestas son las siguientes:

• Categoría 1: la dirección maneja información de usuario sensible, ejemplo: pagos online, formularios.

• Categoría 2: la dirección maneja credenciales de usuario, ejemplo: ingreso y registro.

• Categoría 3: en la dirección se presenta información al usuario, suelen haber redirecciones a otros dominios, ejemplo: blogs, listas de productos, secciones FAQ.

Con base en lo anterior, la guía sugiere ciertas configuraciones que, al ser tenidas en cuenta, contribuirán en el proceso de desarrollo apuntando hacía una plataforma web más segura.

22

4 IMPLEMENTACIÓN

4.1 Aspectos proyecto base (Secure Headers)

El proyecto desarrollado por OWASP se encuentra disponible en el siguiente link: https://github.com/oshp/headers. Para realizar el proceso de identificación y comprensión del proyecto base se llevaron a cabo los siguientes pasos:

• Descarga del proyecto y seguimiento de los pasos de la guía de uso. Se encontraron algunos errores, de los cuales fue documentada su solución y se consolidó una guía de instalación completa que tiene en cuenta estos errores.

• Ejecución del escáner siguiendo las instrucciones de los autores. En este paso no se obtuvo ningún resultado y la salida del programa no era completamente clara, por lo que fue necesario iniciar un proceso de inspección de código a fondo para poder entender su funcionamiento.

• Inspección a fondo del código. En este proceso se encontró que el escáner analiza los sitios web enlistados en un archivo csv ubicado en la carpeta /conf/ llamado “develop.csv”, también cuenta con otro archivo csv con los sitios más visitados a nivel global, pero al correr el análisis con este archivo no se obtuvo ningún resultado, ya que los elementos de esta lista en su mayoría están desactualizados.

• Modificación del archivo “develop.csv”. Se incluyeron sitios web más actuales que respondieran a las solicitudes HTTP y se agregaron impresiones en consola para comprobar que realmente se estaba realizando un escaneo de encabezados.

• Identificación y estudio de los componentes. Luego de verificar el funcionamiento de la aplicación, se continuó inspeccionando el código para poder determinar las dependencias entre los diferentes elementos, con el fin de extraer aquellos que son primordiales para la solución propuesta y descartar los que no son indispensables. Se identificaron 3 componentes principales:

o Persistencia, encargado de almacenar los datos obtenidos del escaneo. o Visualización web de resultados, encargado de mostrar la información y

estadísticas obtenidas en un tablero de visualización web. o Escáner de encabezados, encargado de realizar las solicitudes HTTP a los sitios

web enlistados y de extraer la información del uso de encabezados de seguridad.

• Análisis del escáner de encabezados. En este punto se observó que el escáner funciona realizando peticiones a cada sitio web en el archivo que el usuario envíe por parámetro utilizando un pool de threads para optimizar el rendimiento y va guardando las respuestas HTTP obtenidas.

• Extracción del escáner. Este componente fue separado del resto y utilizado como base para la herramienta propuesta.

Esta aplicación tiene como dependencias MySql para gestionar la base de datos, Redis (https://redis.io/) para almacenar datos en memoria y Python 3.6 que utiliza como lenguaje de programación principal. También, propone la utilización de un ambiente virtual suministrado por python para facilitar su instalación, utiliza Docker para automatizar el despliegue de la aplicación y para el componente web se utiliza Flask (https://flask.palletsprojects.com) como framework y la biblioteca jQuery (https://jquery.com/).

En cuanto al componente escáner, usa las librerías UserDict (https://docs.python.org/2/library/userdict.html) para manejar un diccionario de los sitios web a

https://github.com/oshp/headers

https://flask.palletsprojects.com/

23

visitar, Gevent (http://www.gevent.org/) para poder usar una piscina de hilos en las peticiones que realiza a los sitios y la librería Requests (https://pypi.org/project/requests/) para realizar las peticiones HTTP y mostrar las posibles excepciones de conexión.

4.2 Aspectos de desarrollo

Para aproximarse más a la solución propuesta, una aplicación sencilla y fácil de usar para los desarrolladores, se extrajo solo el componente de escaneo y sus dependencias principales, descartando los elementos relacionados con persistencia y visualización que no eran requeridos para cumplir con el objetivo principal de la herramienta. Se probó que de esta forma siguiera funcionando correctamente y se implementaron las modificaciones enunciadas a continuación.

4.2.1 Implementación de funcionalidad de escaneo de direcciones

Con el fin de escanear las direcciones de las diferentes páginas de un sitio web se implementó un algoritmo que utiliza el paquete Urllib, específicamente el módulo requests para realizar las peticiones HTTP, el método “urlopen” del mismo paquete el cual permite abrir y leer el objeto solicitado y la librería Beautiful soup que facilita la extracción de datos presentes en documentos HTML y XML. Normalmente desde la página de inicio es posible redireccionar al usuario a todas las páginas con las que cuenta el sitio web, por lo que el algoritmo primero realiza una petición a la página de inicio para obtener el documento HTML de la misma, luego, extrae todos los valores de los atributos “href” que encuentre y toma solamente aquellos que inician con una barra inclinada “/” que son aquellas direcciones que pertenecen al sitio web, descartando así direcciones pertenecientes a otros dominios.

4.2.2 Organización del nuevo flujo del programa

Luego, con el fin de simplificar el flujo del programa, se modificó la clase principal, para que, al iniciarse, ésta reciba directamente la url del sitio web a escanear, inicie el rastreo de direcciones y el escaneo de encabezados. Se removieron métodos y opciones que correspondían a la versión anterior del programa y se agregaron comentarios que facilitan la lectura del código. También, fue necesario modificar los parámetros de ciertos métodos indispensables y la estructura de los mismos para cumplir con los requerimientos planteados.

4.2.3 Estructuración de los mensajes de consola

Ahora, para orientar al usuario en el uso de la herramienta y presentar los resultados, se agregaron impresiones en consola que presentan la aplicación, indican el formato en el que se debe de ingresar la URL, anuncian el inicio del escaneo y muestran los resultados obtenidos de manera organizada y fácil de leer. También se agregaron impresiones que indican si algún error ha ocurrido y si alguna dirección es descartada por su alto tiempo de espera.

24

4.2.4 Consolidación guía de usuario

Finalmente, se ha elaborado un documento que enuncia los pasos necesarios para hacer uso de la herramienta final (Véase Anexo 1 ), orienta la interpretación de los resultados que se obtienen y presenta recomendaciones de configuración de los encabezados de seguridad en la aplicación web que ha sido escaneada. Estas recomendaciones están basadas en la sensibilidad de la información que maneja cada dirección del sitio web y su cumplimiento depende del criterio del desarrollador.

25

5 EVALUACIÓN

Para hacer uso de la herramienta desarrollada, el usuario debe de seguir la guía de instalación y ejecución local. Luego la herramienta mostrará el siguiente mensaje:

El usuario debe de ingresar la url del sitio web que desea escanear, en este caso a modo de ejemplo se ingresó la dirección de Facebook. Posterior a esto, la herramienta inicia el rastreo de direcciones presentes en la página de inicio y acto seguido inicia al escaneo de encabezados de seguridad.

El programa cuando detecta que alguna dirección está tardando demasiado en responder la excluye del análisis y continúa su curso. Una vez el escaneo finaliza, se presentan los encabezados junto con sus valores utilizados en cada dirección web escaneada.

Al finalizar, el programa presenta un resumen de las conexiones que realizó, en este caso fueron un total de 27 direcciones diferentes escaneadas, 24 por medio de https y 3 al realizarles una petición respondieron con algún código de error.

26

Con el fin de probar el funcionamiento de la herramienta en una aplicación desplegada localmente, se utilizó un proyecto sencillo que hace uso de Django en su configuración más básica. Éste fue puesto en marcha y, luego de comprobar la conexión, se ingresó la IP local y el puerto correspondiente.

En este caso la herramienta no tuvo ningún problema de conexión y entregó los resultados satisfactoriamente. Finalmente, para terminar de evaluar el programa se ingresó la url github.com, la cual cuenta con una configuración de encabezados de seguridad más avanzada y completa, esto se puede apreciar en los siguientes resultados:

27

Casi todas las direcciones cuentan con la misma configuración, todas las conexiones fueron realizadas sobre HTTPS y no hubo ninguna excluida en el análisis. Github.com es un sitio bastante robusto en temas de seguridad y la herramienta evaluada se comportó tal como se esperaba.

28

6 TRABAJO RELACIONADO

Es bien sabido que los encabezados en el protocolo HTTP cumplen un papel fundamental en la seguridad de las aplicaciones web. Es por eso que se continúan realizando investigaciones para aprovechar al máximo sus propiedades, como en [12] que realizan un estudio para reconocer los encabezados modificados e identificar los ataques de denegación de servicios, al igual que en [13] y [14] que analizan los encabezados incompletos de las peticiones clientes para mitigar ataques de este mismo tipo. También, examinando el uso de ciertos encabezados de respuesta HTTP es posible determinar si un sitio web es malicioso, tal como lo realiza la extensión de Chrome propuesta en [15]. Ahora bien, existen encabezados que permiten prevenir otro tipo de ataques como hombre en el medio y ataques de inyección cruzada, pero no suelen ser implementados a pesar de su potencial debido a que no son muy reconocidos. Por lo anterior, en [5] y [4] han realizado escaneos a diferentes sitios web para visibilizar las estadísticas de utilización de estos encabezados y así promover su uso, apuntando a una mejora en la seguridad de estos sitios. Sin embargo, estos estudios solo tienen en cuenta los datos de la página de inicio de cada sitio web, no tienen presente la diversidad en las funcionalidades de los mismos y no realizan recomendaciones de implementación específicas a los desarrolladores. Sin embargo, agregar todos los encabezados posibles no es lo ideal, ya que existen algunos que podrían utilizarse de forma maliciosa como lo plantean en [16], donde identifican el uso del encabezado referer en sitios web maliciosos. Es por lo anterior que consolidar una guía de configuración basada en las necesidades de funcionamiento es una tarea valiosa y fundamental para avanzar hacia una navegación web más segura. Los párrafos siguientes describen más detalles de los trabajos mencionados:

29

Analysis of HTTP Security Headers in Turkey [5]

La seguridad en las aplicaciones es un requerimiento no funcional indispensable para las empresas y organizaciones en la red, es necesario implementar diferentes controles de seguridad como la autenticación, autorización, validación de entradas, etc. Para poder proteger correctamente las aplicaciones web. Sin embargo, cualquier usuario de internet puede usar herramientas de hacking, que están disponibles gratuitamente en la red, para acceder a información sensible fácilmente. Es por esto que algunos proveedores de navegadores web han decidido integrar controles de seguridad como las cabeceras de respuesta en HTTP. No obstante, es necesario que los desarrolladores implementen las cabeceras relevantes en las respuestas de HTTP, pero, ¿Los desarrolladores web conocen sobre estas cabeceras y cómo utilizarlas?

Para resolver esta última pregunta, se realizó un análisis automatizado del uso de los encabezados de seguridad de HTTP en los portales web más conocidos de Turquía, para posteriormente evaluar estadísticamente los resultados con el fin de incrementar la consciencia de los desarrolladores y expertos en seguridad respecto al tema. Se desarrolló una herramienta en Python que recibe como entrada un grupo de direcciones web, visita los sitios y verifica el uso de las cabeceras de seguridad relevantes. Luego, con los resultados obtenidos de porcentaje de uso de cabeceras en cada portal web y sus subdominios, se realizó una caracterización para identificar la madures en seguridad de diferentes sectores (Financiero, comercio, retail, juegos y apuestas, etc.) y se compararon los resultados entre ellos, concluyendo que, aunque el sector de finanzas tiene un porcentaje más alto en el uso de cabeceras de seguridad que otros sectores, la madurez general de la seguridad web en Turquía sigue siendo bastante inferior a la esperada.

Este articulo no propone un trabajo a futuro, pero permite visibilizar el panorama de seguridad web en Turquía, esperando que con esto se pueda llegar a sensibilizar a los desarrolladores y expertos en seguridad en el uso de cabeceras de respuesta HTTP, las cuales fortalecen el esquema de seguridad en los portales web. Los autores explican la funcionalidad de cada una de las cabeceras propuestas, porqué son útiles y permiten el uso libre de la herramienta desarrollada en su estudio, de tal forma que los desarrolladores y personas interesadas en este tema la puedan utilizar y obtener un reporte del estado actual de seguridad web en sus portales.

30

Analysis of the Adoption of Security Headers in HTTP [4]

Las amenazas para los sistemas basados en la web han aumentado considerablemente y debido a esto, es necesario contar con un enfoque más integral que asegure el fortalecimiento de políticas de seguridad desde el servidor hacia el cliente. Estas políticas apuntan a la prevención de ataques como inyección de código, hombre en el medio, cross-side scripting o clickjacking. El objetivo clave del trabajo planteado es entender las tendencias de uso de estos encabezados moviéndose a través de un millón de sitios web.

Con el fin de lograr el objetivo anteriormente descrito, se realizó un escaneo de un millón de páginas del ‘Alexa top sites’ en dos periodos, agosto de 2015 y mayo de 2017, lo cual permitió obtener las estadísticas de uso de los encabezados de seguridad y determinar los cambios en la utilización de los mismos con el paso del tiempo. Los resultados de este trabajo mostraron hechos como; el número de sitios utilizando la capa de seguridad CSP aumentaron de un 387,2%, el encabezado HPKP (HTTP public key pinning) es uno de los más poco utilizados, la mayoría de páginas obtuvieron entre un 0% y un 13% de utilización de encabezados de seguridad, que la utilización del encabezado XFO es por mucho la que más ha prevalecido, entre otros hechos que, en general, demuestran un aumento en la implementación de políticas de seguridad.

Finalmente, los autores plantean que es muy probable que ahora muchas compañías estén investigando el uso de métodos de seguridad mejorados y que podría haber un crecimiento considerable en los resultados de futuros escaneos. Plantean mejorar el sistema de puntuación de su estudio y acceder a más de una sola página por sitio web, ya que en este caso solamente se accedió a la página de inicio del sitio web, lo que se podría considerar un sesgo importante dado que se descartan el resto de rutas de cada sitio que podrían funcionar diferente.

31

Recent Analysis of Forged Request Headers Constituted by HTTP DDoS [12]

Los ataques de denegación de servicios distribuidos por capas de aplicación (DDoS) son muy complicados de detectar. El déficit en la capa de aplicación admite la configuración de DDoS HTTP, debido a que no es obligatorio adjuntar los encabezados de solicitud en una solicitud HTTP. Sumado a esto, los encabezados son editables, lo cual proporciona una ventaja al atacante de ejecutar DDoS al poder contener encabezados de solicitud que pueden emular una solicitud proveniente de un cliente genuino. Hasta ahora, no existen estudios recientes que proporcionen un patrón de encabezados de petición modificados con los scripts actuales de ataque HTTP DDoS. Además, el conjunto de datos actualizado para HTTP DDoS no están públicamente disponibles, lo que hace que los investigadores se basen en datos antiguos en lugar de en los patrones de ataque más actuales. Por lo anterior, los autores realizaron un análisis para revelar los patrones de encabezados de petición falsos creados por HTTP DDoS. El análisis fue ejecutado utilizando máquinas y ocho scripts de ataque reales capaces de sobrecargar un servidor web en una corta duración, fueron ejecutados en una red interna y una externa con el fin de obtener similitudes y diferencias en los ataques realizados desde diferentes topologías. Los resultados proporcionaron en total siete patrones que evidencian la diferencia entre una petición modificada y una que no. Lo anterior permitió que se diseñara satisfactoriamente una arquitectura de HTTP DDoS y la taxonomía de los encabezados de solicitud falsos o alterados. Para concluir, los autores plantean como trabajo futuro ejecutar ataques DDoS en la versión 2 de HTTP para observar la estrategia de ataque en la manipulación de encabezados de petición. debido a que la versión 2 tiene una estructura de encabezados diferente a la versión 1.1 utilizada en este estudio. Al final sugieren algunas medidas de precaución a tener en cuenta para los futuros investigadores de soluciones a la detección de ataques DDoS y proponen algunas áreas de investigación para mitigar el problema, entre las cuales son; el desarrollo de un navegador que prevenga la manipulación de encabezados encriptándolos, el análisis de otros dispositivos que funcionen como botnets, la ejecución del ataque DDoS otras versiones del protocolo y el desarrollo de nuevos estándares para rechazar solicitudes que no provengan de navegadores.

32

The Slow HTTP DDOS Attacks: Detection, Mitigation and Prevention in the Cloud Environment

[13] La computación en la nube ofrece grandes beneficios, como su relación costo – beneficio, su facilidad de operación, sus servicios a demanda y su disponibilidad, lo cual ha incrementado su popularidad. Gracias a esto, algunas aplicaciones basadas en internet han empezado a utilizar sus servicios para reducir costos, pero esto ha causado que sean vulnerables al ataque de denegación de servicios distribuido (DDoS) en la nube, el cual, debido a su naturaleza de imitar un comportamiento real en la red es muy complicado de detectar. Es necesario entonces proteger a estas aplicaciones de ataques que perjudiquen su funcionamiento. Los autores presentan tres tipos de ataques de denegación de servicios HTTP lentos; (1)ataques con encabezados incompletos que aprovechan el diseño del protocolo para dejar en espera el servidor, (2) ataques R-U-Dead-Yet que envían los encabezados completos pero con el campo del tamaño con un valor demasiado alto, lo que causa que el servidor permanezca en espera del mensaje completo y (3) ataques que envían los encabezados y cuerpo de las peticiones completos pero se demoran procesando la respuesta. Para plantear la solución tuvieron en cuenta ataques provenientes de fuentes internas y externas del ambiente en la nube, luego crearon un modelo de zona multietapa en OpenStack que reconoce comportamientos de las solicitudes y las clasifica en cuatro zonas; la verde para comportamientos normales, roja para anormales (que no procesa), naranja para sospechosos y una zona de monitoreo a donde van las solicitudes inactivas. Finalmente, los autores resaltan que su solución detecta y previene los ataques eficazmente ya que los resultados de su configuración son mejores que los obtenidos con la configuración por defecto de OpenStack. Como futuro trabajo proponen generar nuevos ataques con diferentes herramientas disponibles en la nube para estudiar el resultado de las soluciones ofrecidas y mejorar la taza de éxito.

33

Malicious Websites Detection and Search Engine Protection [15]

Gracias al Desarrollo del internet, la cantidad de datos se expande muy rápido y los motores de búsqueda se han convertido en la columna vertebral en el manejo de la información, manejando el 70% del tráfico web. Sin embargo, un alto número de sitios web maliciosos inundan los motores de búsqueda y se han convertido en una enorme amenaza para los usuarios ya que, si se accede a uno de estos sitios, scripts maliciosos usualmente lanzan ataques para instalar programas sospechosos, robar credenciales o incluso controlar la máquina de la víctima como un botnet. Por lo anterior, es más valioso y preferible prevenir con antelación que manejar una infección del sistema, por lo que algunas agencias de seguridad han desarrollado plugins de navegadores basados en listas negras de sitios web para proteger a los usuarios, pero se quedan cortos con incontables sitios maliciosos. La solución presentada por los autores es un plugin de navegador que corre sobre Google Chrome (el navegador más utilizado) para el cual seleccionaron las siguientes características estáticas para lograr identificar los sitios maliciosos: (1) Peculiaridades en la URL, como tres o más letras consecutivas idénticas, símbolos (como ‘&’, ‘%’, ‘_’) o caracteres numéricos en gran proporción. (2) Utilización de encabezados de respuesta HTTP tales como el ‘Content_location’ para redireccionar y el ‘Keep_Alive’ para conservar activa la conexión, o características del contenido como la etiqueta HTML de refresco en el Meta y la redirección entre dominios, el número de elementos invisibles, scripts y el número de elementos sospechosos y de pequeñas dimensiones. (3) Características de JavaScript (JS) como el número de elementos JS, la entropía de JS en la página, la entropía de scripts JS externos en todos los scripts, la cadena de caracteres más larga del atributo src de un JS, el tamaño máximo de todos los scripts, cantidad de URLs en los scripts, redireccionamiento de JS, número de funciones dinámicas, número de funciones de ofuscación, número de funciones de temporizador, número de funciones evento y el número de funciones sospechosas o cadenas de caracteres. (4) El número de veces indexado por Google utilizando Google query. (5) Información acerca del dominio obtenida a través de www.domaintools.com. (6) Recuento de enlaces relevantes, velocidad de acceso, promedio de visitas a la página, número de enlaces traseros y presencia de ranking obtenidos de la corporación Alexa. (7) Datos obtenidos de la comunidad de WOT (web of trust) quienes reportan los sitios maliciosos o seguros que han visitado. El plugin luego de que el documento HTML ha sido cargado ejecuta un script que extrae todas las características del sitio web mencionadas anteriormente, se determina si el sitio es malicioso o no y se comunica con otro script el cual agrega un icono verde o rojo al lado del link del sitio.

Finalmente, los autores resaltan que su selección de características mejora enormemente el rendimiento de la clasificación de sitios maliciosos y que el plugin desarrollado es una buena protección contra el envenenamiento de motores de búsqueda, ya que no usan una sola base de datos como algunas soluciones ya existentes. Los autores no dejan planteado ningún trabajo a futuro, no proponen ningún otro reto y no se realizan

34

Empirical Analysis of Impact of HTTP referer on malicious website behavior and delivery [16]

El encabezado Referer de HTTP le permite al servidor web identificar el origen de la petición y el camino tomado por el usuario visitante para llegar recurso final y, aunque su uso es opcional, muchos servidores utilizan esta información para guardar registros, para propósitos analíticos y de marketing. Sin embargo, este encabezado ha sido utilizado para camuflar páginas web de spam por medio del posicionamiento web y ha permitido personalizar el tipo de malware o exploit a ejecutar basado en el origen de la petición. El objetivo de este estudio es poder determinar los efectos del encabezado Referer en la entrega de contenido malicioso al adoptar diferentes valores. Para cumplir con el objetivo planteado, se utilizó un sistema de detección que emulaba un navegador cliente e interactuaba con un servidor web remoto (honeypot) y examinaba las respuestas para determinar si había presencia de código malicioso en el contenido recibido. Los tipos de valores que utiliza el encabezado Referer son: (1) Null Referer, el cual indica que el visitante del sitio web ha escrito la dirección URL del sitio directamente en la barra de dirección del navegador o ha ingresado desde un marcador. (2) Domain name, éste indica que el visitante ha llegado al recurso por medio de un subdominio o desde la página principal del sitio web. (3) Google search result, indica que el visitante ha llegado al recurso desde el resultado de una búsqueda por Google. (4) Bing search result, indica que el visitante ha llegado al recurso desde el resultado de una búsqueda por Bing. El conjunto de datos utilizado para el experimento estaba conformado por 500.000 sitios web, 300.000 dominios fueron recolectados de listas públicas de sitios sospechosos y los otros 200.000 fueron recopilados de dos dominios de nivel superior relacionados con actividades maliciosas. Los resultados de su estudio confirmaron que los servidores web maliciosos escanean activamente, registran y utilizan la información en la entrega de contenido malicioso a los usuarios finales. Remover el encabezado en cuestión podría restringir el acceso a algunos sitios web, pero reduciría el riesgo de ser infectado con un malware en los usuarios promedio. También se encontraron algunos patrones de comportamiento de los servidores web que pueden ser utilizados como un indicador de sitios maliciosos. Finalmente, los autores plantean como trabajo a futuro extender su investigación a la utilización de conjuntos de datos más grandes con el fin de comparar el comportamiento entre sitios web maliciosos, sospechosos y benignos. Proponen también registrar y analizar las redirecciones del cliente, la identificación de la proporción de malware y spam de la web en los contenidos recibidos y un estudio que investigue el comportamiento de los sitios maliciosos con diferentes valores a los ya utilizados del encabezado Referer.

35

A Review of Defense Against Slow HTTP Attack [14]

El ataque HTTP lento explota los métodos de trabajo del protocolo, enviando peticiones incompletas o con una tasa de transferencia muy baja para que el servidor permanezca ocupado esperando el resto de los datos y se genere una denegación de servicios. Cualquier usuario de internet puede explotar estas vulnerabilidades, por lo que detectar y defenderse de este ataque es una cuestión importante. Por lo anterior, el objetivo de este artículo es realizar una revisión de los mecanismos ya existentes en contra de este ataque.

Los autores repasan los tres métodos que se utilizan para realizar este tipo de ataque, el primero es enviar los encabezados de petición incompletos, el segundo es enviar el cuerpo de la petición incompleto y el tercero es abrir una conexión con el servidor y procesar la información en el host lentamente, de tal forma que el servidor se quede esperando. Luego, explican una forma de identificar el ataque HTTP lento, utilizando comandos de netstat y analizando la cantidad de conexiones que tiene abiertas cada dirección IP. En cuanto a la defensa, resaltan y explican diferentes soluciones como los son; la implementación y configuración del demonio xinetd, la configuración de algunos parámetros de configuración del servidor Nginx, cuatro módulos para el servidor Apache (mod_reqtimeout, mod_qos, mod_security y mod_antiloris) y dos elementos para el servidor IIS (WebLimits y RequestLimits).

Para finalizar, los autores resaltan el impacto que puede llegar a tener el ataque en cuestión si éste no es manejado de manera adecuada, señalan que no es necesario utilizar todas las opciones que presentaron para defenderse, sino realizar las configuraciones correctamente y seleccionarlas según sea necesario y afirman que este ataque puede ser prevenido e incluso eliminado si se tienen las medidas de precaución apropiadas.

36

7 CONCLUSIONES Y TRABAJO FUTURO

Para que el producto final presentado contribuya al esquema de seguridad de las aplicaciones web, es necesario que los desarrolladores que decidan utilizar la herramienta interpreten el reporte que esta entrega utilizando la guía anexa a este documento e implementen los encabezados que en esta se sugieren, con base a las categorías de direcciones que allí se mencionan. Teniendo en cuenta la estructura y el funcionamiento de la herramienta, es posible extender sus funcionalidades en un futuro y crear a partir de ella una aplicación robusta de escaneo de vulnerabilidades web o de detección de ataques de denegación de servicios, teniendo en cuenta las investigaciones realizadas en los artículos mencionados en la sección de trabajo relacionado, las cuáles proponen diferentes métodos para analizar los encabezados y detectar estos ataques. En la fase de evaluación del proyecto se encontró que la herramienta tiene un limitante en cuanto a los tiempos de espera y en aquellos sitios web que tardan mucho en responder son excluidas todas sus direcciones, por lo que no es posible realizar el escaneo en su totalidad. Finalmente, la aparición de la versión 3.0 de HTTP cambia la estructura de los encabezados del protocolo con el fin de reducir la latencia y suspende el uso de TCP, este proyecto está basado en la versión 2.0, por lo que se deberán contemplar nuevos métodos para evaluar la seguridad en arquitecturas web e investigar nuevas vulnerabilidades que esta actualización pueda traer. Dependiendo de la versión final que sea publicada y adaptada por los sitios web, se podrían realizar pequeñas modificaciones para ajustar la herramienta presentada en este proyecto con el fin de que continúe vigente.

37

8 REFERENCIAS

[1] J. F. Kurose y K. W. Ross, Computer networking, a top-down approach featuring the Internet, Séptima ed., Pearson, 2017.

[2] «Akamai,» [En línea]. Available: https://www.akamai.com/es/es/resources/our-thinking/state-of-the-internet-report/web-attack-visualization.jsp. [Último acceso: 26 10 2020].

[3] «OWASP Top Ten,» [En línea]. Available: https://owasp.org/www-project-top-ten/. [Último acceso: 18 12 2020].

[4] W. J. Buchanan, S. Helme y A. Woodward, «Analysis of the Adoption of Security Headers in HTTP,» IET Information Security, vol. 12, Octubre 2017.

[5] K. E. Kisa y E. İ. Tatli, «Analysis of HTTP Security Headers in Turkey,» International journal of information security science, vol. 5, nº 4, pp. 96-105, Octubre 2016.

[6] T. Garsiel y P. Irish, «Cómo funcionan los navegadores: lo que hay detrás de los navegadores web actuales,» 5 Agosto 2011. [En línea]. Available: https://www.html5rocks.com/es/tutorials/internals/howbrowserswork/. [Último acceso: 28 Octubre 2020].

[7] «Man-in-the-middle Software Attack | OWASP Foundation,» [En línea]. Available: https://owasp.org/www-community/attacks/Man-in-the-middle_attack. [Último acceso: 8 Octubre 2020].

[8] «Cross Site Scripting (XSS) Software Attack | OWASP Foundation,» [En línea]. Available: https://owasp.org/www-community/attacks/xss/. [Último acceso: 8 Octubre 2020].

[9] «Clickjacking | OWASP,» [En línea]. Available: https://owasp.org/www-community/attacks/Clickjacking. [Último acceso: 8 Octubre 2020].

[10] «SQL Injection | OWASP,» [En línea]. Available: https://owasp.org/www-community/attacks/SQL_Injection. [Último acceso: 8 Octubre 2020].

[11] «OWASP Secure Headers Project,» 6 Noviembre 2019. [En línea]. Available: https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project. [Último acceso: 23 Septiembre 2020].

[12] A. G. Jaafar, S. A. Ismail, M. S. Abdullah, N. Kama, A. Azmi y O. M. Yusop, «Recent Analysis of Forged Request Headers Constituted by HTTP DDoS,» Sensors, vol. 20, nº 14, p. 3820, Julio 2020.

[13] A. Dhanapal y P. Nithyanandam, «The Slow HTTP DDOS Attacks: Detection, Mitigation and Prevention in the Cloud Environment,» Scalable Computing: Practice and Experience, vol. 20, nº 4, pp. 669-685, Diciembre 2019.

[14] S. Suroto, «A Review of Defense Against Slow HTTP Attack,» JOIV: International Journal on Informatics Visualization, vol. 1, nº 4, pp. 127-134, Noviembre 2017.

38

[15] H. Zhou, J. Sun y H. Chen, «Malicious websites detection and search engine protection,» Journal of Advances in Computer Network, vol. 1, nº 3, pp. 260-264, Septiembre 2013.

[16] M. Mansoori, Y. Hirose y I. Welch, «Empirical analysis of impact of HTTP referer on malicious website behaviour and delivery,» de IEEE 30th International Conference on Advanced Information Networking and Applications, Crans-Montana, 2016.

[17] IETF, «RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2),» [En línea]. Available: https://tools.ietf.org/html/rfc7540. [Último acceso: 25 08 2020].

39

9 ANEXO 1


GUÍA DEL DESARROLLADOR

ESCANER DE ENCABEZADOS DE SEGURIDAD DE RESPUESTA

Tabla de contenido

1. Instalación y ejecución del escáner ............................................................................ 40

2. Interpretación de los resultados .................................................................................. 41

3. Recomendaciones de configuración ........................................................................... 42

40

1. INSTALACIÓN Y EJECUCIÓN DEL ESCÁNER

Dependencias:

• Python 3.6+

• Microsoft C++ Build Tools 14.0

Pasos para la instalación:

1. Descargar el proyecto disponible en: https://github.com/1anturi1/secureHeaders

2. Ubicarse desde la consola de comandos en el proyecto.

3. (Opcional2) Instalar entorno virtual: pip install virtualenv

4. (Opcional) Crear entorno virtual localmente: virtualenv [nombre_entorno]3

5. (Opcional) Activar entorno virtual:

Mac OS/Linux: source [nombre_entorno]/bin/actívate Windows: [nombre_entorno]\Scripts\activate

6. Instalar las dependencias con:

a. pip install -r requirements.txt

b. pip3 install python-dotenv

c. python -m pip install gevent

d. pip install beautifulsoup4

e. pip install requests

f. pip install lxml

7. Ejecutar la aplicación desde la consola utilizando alguno de los siguientes comandos:

a. cli.py

b. py cli.py

c. python cli.py

8. Ingresar la dirección del sitio web que desea escanear con el formato indicado. Omita el

protocolo y el www si es el caso, como en el siguiente ejemplo: https://www.amazon.com

solo se debe ingresar el “amazon.com”. Si el sitio que desea escanear se encuentra

desplegado localmente o en una IP distinta, ingrese la dirección con el siguiente formato:

127.0.0.1:8080

9. Interpretar los resultados apoyándose en la sección 2 de este documento.

Se sugiere seguir las recomendaciones de configuración de encabezados presentes en la sección 3

de este documento, con el fin de mejorar el esquema de seguridad de su aplicación.

2 Es posible crear un entorno virtual para que al instalar las dependencias estas no queden en su máquina y posteriormente puedan ser eliminadas con facilidad. No es necesario realizarlo ya que puede instalar las dependencias directamente en su máquina. 3 Asigna un nombre al entorno sin los corchetes, ej: virtualenv entornoEjemplo

https://github.com/1anturi1/secureHeaders

41

2. INTERPRETACIÓN DE LOS RESULTADOS

Una vez la herramienta ha terminado el escaneado, los resultados se imprimirán en la consola, mostrando en primer lugar (si es el caso) las direcciones que fueron excluidas del escaneo debido a un alto tiempo de respuesta como se muestra en la siguiente imagen:

Luego se mostrarán los resultados del escaneo como tal, los cuáles indican los encabezados y valores que estos toman en cada dirección. Los encabezados están separados por una línea para mejorar la comprensión, el resultado para cada dirección se verá de manera similar a la siguiente imagen:

Finalmente se mostrará un resumen de los tipos de conexiones que se realizaron, lo ideal es que todas las conexiones exitosas sean realizadas por HTTPS debido a la mejora en seguridad que este protocolo ofrece respecto a HTTP. El resumen se mostrará como en la siguiente imagen:

42

3. RECOMENDACIONES DE CONFIGURACIÓN

Para simplificar la identificación de las necesidades de cada dirección en el sitio web, se han determinado tres categorías con base a la sensibilidad de la información que sea manejada. Es recomendable que según la categoría que considere se ajusta a las características de cada una de las direcciones de su sitio web implemente los encabezados de seguridad de respuesta enunciados a continuación:

Categoría 1. La dirección maneja información de usuario sensible, ejemplo: pagos online, formularios. Encabezados sugeridos:

• strict-transport-security

• x-xss-protection

• x-frame-options

• x-content-type-options

• content-security-policy

• x-permitted-cross-domain-policies

• referrer-policy

• Expect-CT

Categoría 2. la dirección maneja credenciales de usuario, ejemplo: ingreso y registro. Encabezados sugeridos:



• x-frame-options

• x-content-type-options


• Expect-CT

Categoría 3. en la dirección se presenta información al usuario, suelen haber redirecciones a otros dominios, ejemplo: blogs, listas de productos, secciones FAQ. Encabezados sugeridos:



• x-frame-options


• x-permitted-cross-domain-policies

• referrer-policy

Finalmente, dependiendo de las funcionalidades del sitio web podría considerar implementar el encabezado Feature-Policy, el cual permite a los desarrolladores habilitar o deshabilitar selectivamente el uso de varias funciones o APIs del navegador. También, si considera que requiere de una política de seguridad bastante estricta, aunque arriesgada y difícil de manejar podría implementar el encabezado public-key-pins después de investigar acerca de su funcionamiento.

trabajo de grado uso prÁctico de encabezados http para

Documents