Fundamentals Bug Bounty

Aprenderemos conceptos y terminologías básicas, como vulnerabilidades, recompensa por errores (Bug Bounty), clientes, servidores, direcciones IP, HTTP y HTTP sin estado.

Vulnerabilidad

Una vulnerabilidad en una aplicación es una debilidad que puede ser aprovechada por una persona malintencionada para realizar acciones no autorizadas o acceder a información restringida.

Las vulnerabilidades pueden ser explotadas tanto mediante acciones intencionadas como no intencionadas. Por ejemplo, modificar manualmente el ID de un registro para visualizar datos a los que no se debería tener acceso es una forma de explotación, incluso si no se hace con mala intención.

Supongamos que un sitio web le permite crear un perfil con su nombre, correo electrónico, fecha de nacimiento y dirección. Este sitio mantendría su información privada y solo la compartiría con sus amigos. Sin embargo, si el sitio web permitiera que cualquier persona lo agregue como amigo sin su autorización, esto representaría una vulnerabilidad. Aunque el sitio mantenga su información privada frente a personas que no son sus amigos, al permitir que cualquiera lo agregue como tal, cualquier usuario podría acceder a su información. Al probar un sitio, siempre debe considerarse cómo alguien podría abusar de la funcionalidad existente.

Bug Bounty

Una recompensa por errores (bug bounty) es un incentivo que un sitio web o empresa otorga a quienes identifican y reportan de manera ética una vulnerabilidad en sus sistemas. Estas recompensas suelen ser monetarias y pueden variar desde decenas hasta miles de dólares. En algunos casos, también se ofrecen otras formas de compensación, como criptomonedas, millas aéreas (unidades de fidelización otorgadas por aerolíneas), puntos de recompensa, créditos de servicio, entre otros.

Los programas de Bug Bounty ofrecen una compensación económica por cada vulnerabilidad válida reportada. En cambio, un Programa de Divulgación de Vulnerabilidades (Vulnerability Disclosure Program, VDP) no ofrece pagos, sino que proporciona un canal formal para que los hackers éticos comuniquen vulnerabilidades, permitiendo a la organización corregirlas oportunamente.

Cliente y servidor

Su navegador se comunica a través de Internet, una vasta red de computadoras interconectadas que intercambian información mediante 'paquetes'. Estos paquetes contienen tanto los datos que usted envía como metadatos sobre su origen y destino. Cada computadora en Internet posee una dirección única para el envío de estos paquetes. Sin embargo, algunas computadoras están configuradas para aceptar únicamente tipos específicos de paquetes, mientras que otras restringen la comunicación a una lista predefinida de remitentes autorizados. Por lo tanto, la computadora receptora es la encargada de determinar cómo procesar los paquetes y cómo responder a ellos.

La computadora que inicia las solicitudes se denomina comúnmente cliente, independientemente de si la solicitud se realiza a través de un navegador web, una línea de comandos u otra herramienta. Los servidores se refieren a los sitios web y aplicaciones web que reciben las solicitudes.

Para que estas computadoras puedan comunicarse correctamente entre sí, es necesario contar con pautas y estándares comunes. Estos estándares se definen a través de los llamados Request for Comments (RFC), que especifican cómo deben comportarse los sistemas informáticos. Por ejemplo, el Protocolo de Transferencia de Hipertexto (HTTP) establece cómo un navegador (cliente) se comunica con un servidor remoto utilizando el Protocolo de Internet (IP). En este contexto, tanto el cliente como el servidor deben implementar los mismos estándares para poder interpretar correctamente los paquetes de datos que intercambian.

¿Qué sucede cuando visitas un sitio web?

Paso 1: Extracción del nombre de dominio

Cuando usted introduce http://www.google.com/ en su navegador, este interpreta la URL y extrae el nombre de dominio. El nombre de dominio identifica el sitio web al que se desea acceder y debe cumplir con reglas específicas definidas en los documentos RFC (Request for Comments), que establecen estándares para su formato y funcionamiento. El dominio actúa como un identificador legible para los humanos que permite localizar la dirección IP del servidor correspondiente, facilitando así la comunicación entre el navegador y el sitio web.

Paso 2: Resolución de una dirección IP

Una vez determinado el nombre de dominio, el navegador procede a obtener la dirección IP asociada a dicho dominio. Este proceso se conoce como resolución de nombres de dominio o resolución de dirección IP, y es fundamental para que la comunicación en internet funcione correctamente. Cada dominio debe resolverse en una dirección IP específica, ya que esta es la forma en que los dispositivos en la red identifican y localizan al servidor correspondiente.

Existen dos tipos principales de direcciones IP: Protocolo de Internet versión 4 (IPv4) y Protocolo de Internet versión 6 (IPv6). Las direcciones IPv4 están formadas por cuatro números separados por puntos, donde cada número puede oscilar entre 0 y 255 (por ejemplo, 8.8.8.8). Este formato ha sido ampliamente utilizado desde los inicios de internet.

Sin embargo, debido al crecimiento exponencial de dispositivos conectados, surgió la necesidad de una mayor cantidad de direcciones. Para solucionar este problema, se desarrolló el IPv6, la versión más reciente del protocolo. Las direcciones IPv6 constan de ocho grupos de cuatro dígitos hexadecimales separados por dos puntos (por ejemplo, 2001:4860:4860::8888). Además, existen reglas que permiten abreviar estas direcciones, eliminando ceros innecesarios o grupos repetidos de ceros para facilitar su lectura y escritura.

Para encontrar la dirección IP asociada a un nombre de dominio, tu computadora envía una solicitud al Sistema de Nombres de Dominio (DNS). Los servidores DNS son sistemas especializados en internet que almacenan registros de dominios y sus direcciones IP correspondientes, actuando como una especie de "agenda telefónica" de la red. Gracias a este proceso, tu navegador puede localizar el servidor correcto utilizando únicamente el nombre de dominio.

Las direcciones mencionadas anteriormente, 8.8.8.8 (IPv4) y 2001:4860:4860::8888 (IPv6), son ejemplos de servidores DNS públicos de Google, ampliamente utilizados por su velocidad y fiabilidad.

Para obtener más información sobre la dirección IP de un sitio, puedes usar el comando:

dig A www.google.com

Paso 3: Establecer una conexión TCP

A continuación, el ordenador intenta establecer una conexión mediante el Protocolo de Control de Transmisión (TCP) con la dirección IP obtenida, utilizando el puerto 80, ya que se está accediendo a un sitio a través del protocolo http://. Aunque los detalles técnicos de TCP no son esenciales en este contexto, es importante saber que se trata de un protocolo fundamental que define cómo se comunican los ordenadores entre sí. TCP permite una comunicación bidireccional confiable, lo que significa que el receptor puede confirmar la recepción de los datos y solicitar su retransmisión en caso de pérdida, asegurando que la información llegue de manera íntegra y ordenada.

Paso 4: Envío de una solicitud HTTP

Continuando con http://www.google.com/ como ejemplo, si la conexión en el paso 3 es exitosa, su navegador debería preparar y enviar una solicitud HTTP, como se muestra en la siguiente imagen:

El navegador realiza una solicitud GET a la ruta /, que es la raíz del sitio web. El contenido de un sitio web se organiza en rutas, al igual que las carpetas y los archivos de su computadora. A medida que profundiza en cada carpeta, la ruta que toma se indica registrando el nombre de cada carpeta seguido de una /. Cuando visita la primera página de un sitio web, accede a la ruta raíz, que es simplemente una /.

Paso 5: Respuesta del servidor

Aquí, hemos recibido una respuesta HTTP con el código de estado 200 que cumple con HTTP/2. El código de estado es importante porque indica cómo está respondiendo el servidor. También definidos por RFC, estos códigos suelen tener números de tres dígitos que comienzan con 2, 3, 4 o 5. Los códigos 2xx suelen indicar que una solicitud se realizó correctamente.

Otros códigos de respuesta que comienzan con 3 indican una redirección, que indica a su navegador que realice una solicitud adicional. Por ejemplo, si Google, en teoría, necesitara redirigirle permanentemente de una URL a otra, podría usar una respuesta 301. Por el contrario, una 302 es una redirección temporal.

Las respuestas que comienzan con un 4 generalmente indican un error de usuario, como la respuesta 403, cuando una solicitud no incluye la identificación adecuada para autorizar el acceso al contenido a pesar de proporcionar una solicitud HTTP válida. Las respuestas que comienzan con un 5 identifican algún tipo de error de servidor, como el 503, que indica que un servidor no está disponible para gestionar la solicitud enviada.

Paso 6: Representación de la respuesta

Debido a que el servidor envió una respuesta 200 con el tipo de contenido text/html, nuestro navegador comenzará a representar el contenido que recibió. El cuerpo de la respuesta le indica al navegador qué se debe presentar al usuario.

Esto incluiría HTML para la estructura de la página; hojas de estilo en cascada (CSS) para los estilos y el diseño; y JavaScript para agregar funcionalidad dinámica adicional y contenido multimedia, como imágenes o videos. Es posible que el servidor devuelva otro contenido, como XML.

Debido a que las páginas web pueden hacer referencia a archivos externos como CSS, JavaScript y contenido multimedia, el navegador podría realizar solicitudes HTTP adicionales para todos los archivos requeridos de una página web.

También tiene acceso a varias interfaces de programación de aplicaciones (API) del navegador. Estas API permiten que JavaScript interactúe con otros sistemas, el más importante de los cuales puede ser el modelo de objetos de documento (DOM). El DOM permite a JavaScript acceder y manipular el HTML y el CSS de una página web. Esto es importante porque si un atacante puede ejecutar su propio JavaScript en un sitio, tendrá acceso al DOM y podrá realizar acciones en el sitio en nombre del usuario objetivo.

HTTP Request

El acuerdo entre el cliente y el servidor sobre cómo manejar los mensajes HTTP incluye la definición de métodos de solicitud. Un método de solicitud indica el propósito de la solicitud del cliente y lo que el cliente espera como resultado exitoso.

El estándar HTTP define los siguientes métodos de solicitud: GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT y OPTIONS (PATCH también se propuso, pero no se implementó comúnmente en la RFC HTTP). Los navegadores solo enviarán solicitudes GET y POST usando HTML. Cualquier solicitud PUT, PATCH o DELETE es el resultado de la invocación de la solicitud HTTP por parte de JavaScript.

Métodos de solicitud

Las solicitudes GET no deberían alterar los datos; solo deberían recuperarlos de un servidor y devolverlos en el cuerpo del mensaje HTTP. Por ejemplo, en un sitio de redes sociales, una solicitud GET debería devolver el nombre de tu perfil, pero no actualizarlo. Visitar cualquier URL o enlace de sitio web (a menos que lo invoque JavaScript) hace que tu navegador envíe una solicitud GET al servidor de destino.

El método HEAD es idéntico al método GET, excepto que el servidor no debe devolver un cuerpo de mensaje en la respuesta.

El método POST invoca alguna función en el servidor receptor, según lo determine el servidor. En otras palabras, normalmente se realizará algún tipo de acción de backend, como crear un comentario, registrar un usuario, eliminar una cuenta, etc. La acción realizada por el servidor en respuesta a un POST puede variar. A veces, es posible que el servidor no realice ninguna acción. Por ejemplo, una solicitud POST podría provocar un error mientras se procesa una solicitud y que un registro no se guarde en el servidor.

El método PUT invoca alguna función que hace referencia a un registro ya existente en el sitio web o la aplicación remota. Por ejemplo, podría usarse al actualizar una cuenta, una publicación de blog, etc., que ya existe. Nuevamente, la acción realizada puede variar y podría provocar que el servidor no realice ninguna acción.

El método DELETE solicita que el servidor remoto elimine un recurso remoto identificado con un URI.

El método CONNECT está reservado para su uso con un proxy, un servidor que reenvía solicitudes a otros servidores. Este método inicia comunicaciones bidireccionales con un recurso solicitado. Por ejemplo, el método CONNECT puede acceder a sitios web que utilizan HTTPS a través de un proxy.

El método OPTIONS solicita información a un servidor sobre las opciones de comunicación disponibles. Por ejemplo, al llamar a OPTIONS, puede averiguar si el servidor acepta llamadas GET, POST, PUT, DELETE y OPTIONS. Este método no indicará si un servidor acepta llamadas HEAD o TRACE. Los navegadores envían automáticamente este tipo de solicitud para tipos de contenido específicos, como application/json.

HTTP is stateless (Sin estado)

Significa que cada solicitud enviada a un servidor se trata como una solicitud completamente nueva. El servidor no sabe nada sobre su comunicación previa con su navegador al recibir una solicitud. Esto es problemático para la mayoría de los sitios porque quieren recordar quién es usted. De lo contrario, tendría que volver a ingresar su nombre de usuario y contraseña para cada solicitud HTTP enviada. Esto también significa que todos los datos necesarios para procesar una solicitud HTTP deben recargarse con cada solicitud que un cliente envía a un servidor.

Para aclarar este concepto confuso, considere este ejemplo: si usted y yo tuviéramos una conversación sin estado, antes de cada frase pronunciada, tendría que comenzar con "Soy Peter Yaworski; estábamos hablando de piratería informática". Entonces tendría que recargar toda la información sobre lo que estábamos discutiendo sobre piratería informática. Piense en lo que Adam Sandler hace por Drew Barrymore cada mañana en “50 primeras citas”.

Resumen

Ahora deberías tener una comprensión básica de cómo funciona Internet. Específicamente, aprendiste lo que sucede cuando ingresas un sitio web en la barra de direcciones de tu navegador: cómo el navegador traduce eso a un dominio, cómo se asigna el dominio a una dirección IP y cómo se envía una solicitud HTTP a un servidor.

También aprendiste cómo tu navegador estructura las solicitudes y procesa las respuestas, y cómo los métodos de solicitud HTTP permiten a los clientes comunicarse con los servidores. Además, aprendiste que las vulnerabilidades son el resultado de que alguien realice una acción no intencionada o acceda a información que de otro modo no estaría disponible, y que las recompensas por errores son recompensas por descubrir e informar éticamente sobre las vulnerabilidades a los propietarios de los sitios web.

Fuente: Real World Bug Hunting