BUG BOUNTY BASICO

Si es nuevo en el hacking, le resultará útil tener una comprensión de cómo funciona Internet y qué sucede bajo el capó cuando ingresa una URL en la barra de direccion de un navegador. Aunque navegar a un sitio web puede parecer simple, implica muchos procesos ocultos, como preparar una solicitud HTTP, que identifica el dominio para enviar la solicitud traduciendo el dominio a una dirección IP, enviando la solicitud, dar una respuesta, etc.
En este post, aprenderá conceptos básicos y terminología, como vulnerabilidades, recompensas por errores, clientes, servidores, direcciones IP y HTTP. Obtendrás una comprensión general de cómo realizar acciones no deseadas y proporcionaras información de entrada para acceder a información privada que puede resultar en vulnerabilidades. Luego, veremos qué pasa cuando ingresas una URL en la barra de direcciones de su navegador, incluyendo el aspecto de las solicitudes y respuestas HTTP y los verbos de acción HTTP. Terminaremos el post con una comprensión de lo que significa decir que HTTP no tiene estado.

VULNERABILIDADES Y BUG BOUNTY

Una vulnerabilidad es una debilidad en una aplicación que permite a una persona malintencionada realizar alguna acción no permitida o ganar acceso a información que de otro modo no se les debería permitir el acceso.
A medida que aprenda y pruebe aplicaciones, tendras que tener en cuenta que las vulnerabilidades pueden materializarse a través de acciones intencionadas o no intencionadas. Por ejemplo, cambiar el ID de un identificador de registro para acceder a información que no debería tener el acceso es un ejemplo de una acción no intencionada.
Suponga que un sitio web le permite crear un perfil con su nombre, correo electrónico, fecha de nacimiento y dirección. Mantendría tu información privada y solo la compartiría con tus amigos. Pero si el sitio web permite que cualquiera te agregue como amigo sin
su permiso, esto sería una vulnerabilidad. Aunque el sitio mantuvo su información privada fuera de los amigos, permite que cualquiera te agregue como amigo y cualquiera puede acceder tu información. Al probar un sitio, siempre considere cómo alguien podría abusar de la funcionalidad existente.
Una recompensa por errores es una recompensa que otorga un sitio web o una empresa
cualquiera que descubra éticamente una vulnerabilidad y la informe en ese sitio web o directamente a la empresa. Las recompensas suelen ser monetarias y van desde decenas de dólares a decenas de miles de dólares.
Otros ejemplos de recompensas incluyen criptomonedas, puntos de viaje, puntos de recompensa, créditos de servicio, etc.
Cuando una empresa ofrece recompensas por errores, crea un programa, término que usaremos en estos post para denotar las reglas y el marco establecido por las empresas para las personas que quieren probar la empresa en busca de vulnerabilidades. Las recompensas por errores ofrecen una recompensa monetaria, mientras que un VDP no ofrece pago (aunque una empresa puede otorgar botín). Un VDP es solo una forma para que los hackers informáticos éticos informan de las vulnerabilidades a una empresa para que esa empresa las corrija.
Aunque no todos los informes incluidos en estos posts fueron recompensados, todos son ejemplos de hackers informáticos que participan en recompensas por errores de los programas.

CLIENTE Y SERVIDOR

Su navegador se basa en Internet, que es una red de computadoras que se envían mensajes entre sí. A estos los llamamos paquetes de mensajes. Los paquetes incluyen los datos que está enviando e información acerca de dónde provienen esos datos y de dónde está yendo. Cada computadora en Internet tiene una dirección para enviárle paquetes. Pero algunas computadoras solo aceptan ciertos tipos de paquetes, y otros solo permiten paquetes de un lista restringida de otras computadoras. Entonces depende de la computadora receptora para determinar qué hacer con los paquetes y cómo responder. A los efectos de estos posts, nos centraremos solo en datos incluidos en los paquetes (los mensajes HTTP), no los los propios paquetes.
Nos referiremos a estas computadoras como clientes o servidores. La computadora que inicia la peticion generalmente se denomina cliente independientemente de si la solicitud es iniciada por un navegador, línea de comandos, etc. Los servidores se refieren a los sitios web y aplicaciones web que reciben las solicitudes. Si el concepto es aplicable a clientes o servidores, nos referimos a computadoras en general. Ya que Internet puede incluir cualquier cantidad de computadoras, necesitamos pautas sobre cómo las computadoras debe comunicarse a través de Internet. Esto se formaliza con los Documentos de solicitud de comentarios (RFC), que definen estándares sobre cómo deben comportarse las computadoras. Por ejemplo, el Protocolo de transferencia de hipertexto (HTTP) define cómo su navegador de Internet se comunica con un servidor remoto a través del Internet Protocolo (IP). En este escenario, tanto el cliente como el servidor deben acordar implementar los mismos estándares para que puedan entender
los paquetes que cada uno envía y recibe.

¿QUE OCURRE CUANDO VISITAS UN WEBSITE?

Dado que en estos posts nos centraremos en los mensajes HTTP, esta sección le proporciona una descripción general de alto nivel del proceso que ocurre cuando ingresa una URL en la barra de su navegador.

PASO 1: EXTRACCION DEL NOMBRE DE DOMINIO

Una vez que ingresa a http://www.google.com/, su navegador determina el nombre de dominio a partir de la URL. Un nombre de dominio identifica qué sitio web está intentando visitar y debe cumplir unas reglas específicas definidas por las RFC. Por ejemplo, un nombre de dominio solo puede contener caracteres alfanuméricos y
guiones bajos. Una excepción son los nombres de dominio internacionalizados, que están más allá del alcance de estos posts. Para obtener más información, consulte el RFC 3490, que define su uso. En este caso, el el dominio es http://www.google.com. El dominio sirve como una forma de busqueda de la dirección del servidor.

PASO 2: RESOLVIENDO UNA DIRECCION IP

Después de determinar el nombre de dominio, su navegador utiliza IP para buscar la dirección IP asociada con el dominio. Este proceso se conoce como resolución de la dirección IP, y cada dominio en Internet debe resolverse en una dirección IP para funcionar.
Existen dos tipos de direcciones IP: Protocolo de Internet versión 4 (IPv4) y Protocolo de Internet versión 6 (IPv6). Las direcciones IPv4 están estructurados como cuatro números conectados por puntos, y cada número cae en un rango de 0 a 255. IPv6 es la version más nueva del Protocolo de Internet. Fue diseñado para abordar el problema de que se agoten las direcciones IPv4 disponibles. Las direcciones IPv6 se componen de ocho grupos de cuatro digitos hexadecimales separados por dos puntos, pero existen métodos para acortar las direcciones IPv6. Por ejemplo, 8.8.8.8 es una dirección IPv4 y
2001: 4860: 4860 :: 8888 es una dirección IPv6 abreviada. Para buscar una dirección IP usando solo el nombre de dominio, su computadora envía una solicitud al sistema de nombres de dominio (DNS), que consisten en servidores especializados en Internet
que tienen un registro de todos los dominios y su IP correspondiente. Las direcciones IPv4 e IPv6 anteriores son de los servidores DNS de Google. Para obtener más información sobre la dirección IP de un sitio, puede utilizar el comando dig a site.com desde su terminal y reemplace site.com por el sitio que está buscando arriba.

> dig site.com

PASO 3: ESTABLECIENDO UNA CONEXION TCP

A continuación, la computadora intenta establecer una transmisión de protocolo (TCP) con la dirección IP en el puerto 80 porque visitó un sitio usando http: //. Los detalles de TCP no son más importantes que señalar que es otro protocolo que define cómo las computadoras se comunican entre sí. TCP proporciona comunicación bidireccional para que el mensaje de los destinatarios pueden verificar la información que reciben y que nada se pierda en la transmisión.
Es posible que el servidor al que envías una solicitud esté ejecutando múltiples servicios (piense en un servicio como un programa de computadora), por lo que utiliza puertos para identificar procesos específicos para recibir peticiones. Puede pensar en los puertos como las puertas de un servidor a Internet. Sin puertos, los servicios tendrían que competir por la información que se envía al mismo lugar. Esto significa que nosotros necesitariamos otro estándar para definir cómo los servicios cooperan entre sí y asegurarse de que no se roben los datos de un servicio por otro. Por ejemplo, el puerto 80 es el puerto estándar para enviar y recibir solicitudes HTTP sin cifrar. Otro
el puerto común es 443, que se utiliza para HTTPS cifrado. Aunque el puerto 80 es estándar para HTTP y 443 es estándar para HTTPS, la comunicación TCP puede ocurrir en cualquier puerto, dependiendo de cómo un administrador configure un
solicitud.
Puede establecer su propia conexión TCP a un sitio web en el puerto 80 abriendo su terminal y ejecutando nc 80. Esta línea utiliza el comando netcat para crear una conexión de red para leer y escribir mensajes:

nc <ip address> 80

PASO 4: ENVIANDO UNA PETICION HTTP

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

Enviando una peticion HTTP

El navegador realiza una solicitud GET a / path ➊, 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. Cuanto mas profundoen cada carpeta, la ruta es mas larga. Cuando tu visitas la primera página de un sitio web, accede a la ruta raíz, que es solo un /. El navegador también indica que está usando la versión HTTP 1.1 del protocolo. Una solicitud GET solo recupera información. Aprenderemos más sobre esto más tarde. eL header del host ➋ contiene una pieza adicional de información que se envía como parte de la solicitud. HTTP 1.1 necesita identificar dónde esta un servidor en la dirección IP dada para enviar la solicitud porque las direcciones IP pueden albergar varios dominios y en cada uno un servidor. Un header de conexión ➌ indica la solicitud para mantener
la conexión con el servidor abierta para evitar la sobrecarga de conexiones en constante apertura y cierre.
Puede ver el formato de respuesta esperado en ➍. En este caso, esperamos application / html pero aceptaremos cualquier formato, como lo indica el comodín (* / *). Hay cientos de posibles tipos de contenido, pero para nuestros propósitos, veremos application/html, application/json, application/octet-stream y text/plain a menudo. Finalmente, el User-Agent ➎ denota el software responsable de enviar la solicitud.

PASO 5: RESPUESTA DEL SERVIDOR

En respuesta a nuestra solicitud, el servidor debe responder con algo como esto:

Respuesta del servidor

Aquí, hemos recibido una respuesta HTTP con el codigo de estado 200 ➊ que se adhiere a HTTP / 1.1. El código de estado es importante porque indica cómo está respondiendo el servidor. También definido por RFC, estos códigos suelen tener tres dígitos
números que comienzan con 2, 3, 4 o 5. Aunque no existe un requisito estricto para que los servidores utilicen códigos específicos, los códigos 2xx normalmente indican que una solicitud se realizó correctamente. Porque no existe una aplicación estricta de cómo un servidor implementa su uso de códigos HTTP, es posible que vea algunos
las aplicaciones responden con un 200 aunque el cuerpo del mensaje explique que hubo un error en la aplicación. Un cuerpo del mensaje HTTP es el texto asociado con una solicitud o respuesta ➌. En este caso, eliminamos el contenido y lo reemplazamos con –snip– debido al tamaño del cuerpo de respuesta de Google es. Este texto en una respuesta suele ser el HTML para una página web, pero podría ser JSON para una API.
El encabezado Content-Type ➋ informa a los navegadores del el tipo de medio del cuerpo. El tipo de medio determina cómo un navegador renderizará el contenido del cuerpo. Pero los navegadores no siempre usan el valor devuelto por una aplicación; en cambio, los navegadores funcionan con los tipos MIME , leyendo el primer bit del contenido del cuerpo paradeterminar el tipo de medio por sí mismos. Las aplicaciones pueden deshabilitar este comportamiento del navegador incluyendo el encabezado X-
Content-Type-Options. Nosniff, que no se incluye en el ejemplo anterior.
Otros códigos de respuesta que comienzan con 3 indican una redirección, que le indica a su navegador que realice una solicitud adicional. Por ejemplo, si Google teóricamente necesitara permanentemente redirigirle de una URL a otra, podría utilizar una respuesta 301. Por el contrario, un 302 es una redirección temporal. Cuando se recibe una respuesta 3xx, su navegador debe realizar una nueva solicitud HTTP a la URL definida en un encabezado de ubicación, de la siguiente manera:

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

PASO 6: RENDERIZANDO LA RESPUESTA

Ya que el servidor envió una respuesta 200 con el tipo de contenido text/html, nuestro navegador comenzará a mostrar el contenido recibido. El cuerpo de la respuesta le dice al navegador lo que debe ser presentado al usuario.
Para nuestro ejemplo, esto incluiría HTML para la estructura de la página; hojas de estilo en cascada (CSS) para los estilos y diseño; y JavaScript para agregar funcionalidad dinámica adicional y medios, como imágenes o videos. Es posible que el servidor devuelva otro contenido, como XML, pero nos ceñiremos a los conceptos básicos para este ejemplo. El cotro post analizamos XML en mas detalle. Ya que es posible que las páginas web hagan referencia a archivos como CSS, JavaScript y medios, el navegador puede realizar solicitudes HTTP adicionales para todas las páginas web requeridas. Mientras el navegador solicita esos archivos adicionales, continúa analizando la respuesta y presentándote el cuerpo como una página web. En este caso, mostrará la página de inicio de Google, http://www.google.com. Tenga en cuenta que JavaScript es un lenguaje de secuencias de comandos compatible con todos los navegadores principales. JavaScript permite que las páginas web tengan funcionalidad dinámica, incluida la capacidad de actualizar contenido en una página web sin volver a cargar la página, comprueba si su contraseña es lo suficientemente segura (en algunos sitios web), y así sucesivamente. Al igual que otros lenguajes de programación, JavaScript tiene incorporado funciones y puede almacenar valores en variables y ejecutar código en
respuesta a eventos en una página web. También tiene acceso a varios interfaces de programación de aplicaciones (API) del navegador. Estas API permiten que JavaScript interactúe con otros sistemas, la mayoría de los cuales puede ser el modelo de objeto de documento (DOM). El DOM permite que JavaScript acceda y manipule un HTML y CSS de la página web. Esto es significativo porque si un el atacante puede ejecutar su propio JavaScript en un sitio, puede tener acceso al DOM y realizar acciones en el sitio en nombre del usuario objetivo. En posts superiores exploramos este concepto más lejos.

PETICIONES HTTP

El acuerdo entre cliente y servidor sobre cómo manejar los mensajes HTTP incluyen la definición de métodos de solicitud. Una solicitud de método indica el propósito de la solicitud del cliente y qué el cliente espera un resultado exitoso. Por ejemplo de arriba, enviamos una solicitud GET a http://www.google.com/ lo que implica que solo esperamos el contenido de http://www.google.com/ y se devolverá y no se realizarán otras acciones. Ya que Internet está diseñado como una interfaz entre computadoras remotas, se desarrollaron métodos de solicitud para distinguir entre las acciones que se invocan. 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 el HTTP RFC). En el momento de escribir este post, los navegadores solo envían solicitudes GET y POST utilizando HTML. Cualquier solicitud PUT, PATCH o DELETE es el resultado de la invocación de solicitudes HTTP a través de Javascript. Esto tendrá implicaciones más adelante en los
posts cuando consideramos ejemplos de vulnerabilidad en aplicaciones esperando estos tipos de métodos. La siguiente sección proporciona una breve descripción general de los metodos de solicitud que encontrarás en estos posts.

METODOS DE PETICION

El método GET recupera cualquier información identificada mediante la solicitud Identificador uniforme de recursos (URI). El termino URI se usa comúnmente como sinónimo de Uniform Resource Localizador (URL). Técnicamente, una URL es un tipo de URI que define un recurso e incluye una forma de ubicar ese recurso a través de su ubicación en la red. Por ejemplo, http://www.google.com//file.txt y //file.txt son URI válidos. Pero sólo http://www.google.com//file.txt es una URL válida porque identifica cómo ubicar el recurso a través del dominio http://www.google.com. A pesar de los matices, usaremos URL en todos los posts al hacer referencia a los identificadores de recursos. Si bien no hay forma de hacer cumplir este requisito, las solicitudes GET no deben alterar los datos; solo deberían recuperar datos desde un servidor y devolverlo en el cuerpo del mensaje HTTP. Por ejemplo, en un sitio de redes sociales, una solicitud GET debe devolver su nombre de perfil pero no actualice su perfil. Este comportamiento es crítico para la falsificación de solicitudes entre sitios (CSRF) discutidas en un post futuro. Visitar cualquier URL o enlace al sitio web (a menos que lo invoque JavaScript) hace que su navegador envie una solicitud GET al servidor previsto. Este comportamiento es crucial para las vulnerabilidades de redireccionamiento abierto discutido mas adelante.
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, según lo determinado por el servidor. En otras palabras, típicamente se realizará algún tipo de acción de backend, como crear un comentario, registrar un usuario, eliminar una cuenta, y así. La acción realizada por el servidor en respuesta a una solicitud 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 un registro no sería guardado en el servidor. El método PUT invoca alguna función que se refiere a un registro ya existente en el sitio web o la aplicación remota. Por ejemplo, puede usarse al actualizar una cuenta, un entrada de blog, o así sucesivamente que ya existe. De nuevo, la accion puede variar y puede resultar en que el servidor no tome acción en absoluto. El método DELETE solicita que el servidor remoto elimine un recurso remoto identificado con un URI. El método TRACE es otro método poco común; esta usado para reflejar el mensaje de solicitud de vuelta al solicitante. Eso permite al solicitante para ver lo que está recibiendo el servidor y para
utilizar esa información para realizar pruebas y recopilar informacion de diagnóstico.
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 de un servidor sobre las opciones de comunicación disponibles. Por ejemplo, por
llamando para 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, como application/json.

HTTP ES UN PROTOCOLO SIN ESTADO

Las solicitudes HTTP no tienen estado, lo que significa que cada solicitud es enviada a un servidor que la trata como una solicitud nueva. El servidor no sabe nada de su comunicación previa con su navegador al recibir una solicitud. Esto es problemático para la mayoría de los sitios porque los sitios quieren recordar quién es usted. De lo contrario, tendrá que volver a ingresar su nombre de usuario y contraseña por cada solicitud HTTP enviada. Esto también significa que todos los datos requeridos para procesar una solicitud HTTP debe recargarse con cada solicitud que un cliente envía a un servidor.
Para aclarar este concepto confuso, considere este ejemplo: si tú y yo tuvimos una conversación sin estado, antes de cada frase, tendrímos que empezar con «Soy Ildefonso; estamos solo discutiendo sobre hacking «. Luego tendrías que recargar toda la información sobre lo que estábamos hablando sobre hacking.

Para evitar tener que reenviar su nombre de usuario y contraseña para
cada solicitud HTTP, los sitios web utilizan cookies o autenticación, que analizaremos en detalle más adelante.

RESUMEN

Ahora debería tener una comprensión básica de cómo funciona Internet. Específicamente, aprendiste lo que sucede cuando ingresamos un a direccion a un sitio web en la barra de direcciones de su 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 aprendió cómo su navegador estructura las solicitudes y
presenta respuestas y cómo los métodos de solicitud HTTP permiten a los clientes para comunicarse con los servidores. Además, aprendiste que las vulnerabilidades resultan de alguien que realiza una acción no intencionada o acceso a información de otra manera no disponible y que las recompensas por errores son recompensas por
descubrir y reportar vulnerabilidades a los propietarios de sitios web.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s