Update tema 6

Introduccion-hacking-hack4u/tema_6_owasp/README7.md

@@ -44,11 +44,36 @@ A continuación, se proporciona el enlace directo de descarga a la máquina XVWA
 
 ## 6.27 Insecure Direct Object Reference (IDORs)
 
+Las Insecure Direct Object References (IDOR) son un tipo de vulnerabilidad de seguridad que se produce cuando una aplicación web utiliza identificadores internos (como números o nombres) para identificar y acceder a recursos (como archivos o datos) y no se valida adecuadamente la autorización del usuario para acceder a ellos.
+
+Por ejemplo, si una aplicación web utiliza un identificador numérico para identificar un registro en una base de datos, un atacante puede intentar adivinar este identificador y acceder a los registros sin la debida autorización. Esto puede permitir a los atacantes acceder a información confidencial, modificar datos, crear cuentas de usuario no autorizadas y realizar otras acciones maliciosas.
+
+La vulnerabilidad IDOR se puede producir cuando una aplicación web no implementa controles de acceso adecuados para los recursos que maneja. Por ejemplo, una aplicación puede validar el acceso a través de autenticación y autorización para los recursos que se muestran en la interfaz de usuario, pero no aplicar la misma validación para los recursos que se acceden directamente a través de una URL.
+
+Para explotar una vulnerabilidad IDOR, un atacante puede intentar modificar manualmente el identificador de un objeto en la URL o utilizar una herramienta automatizada para probar diferentes valores. Si el atacante encuentra un identificador que le permite acceder a un recurso que no debería estar disponible, entonces la vulnerabilidad IDOR se ha explotado con éxito.
+
+Por ejemplo, supongamos que un usuario ‘A‘ tiene un pedido con el identificador numérico 123 y el usuario ‘B‘ tiene un pedido con el identificador numérico 124. Si el atacante intenta acceder a través de la URL “https://example.com/orders/124“, la aplicación web podría permitir el acceso a ese pedido sin validar si el usuario tiene permiso para acceder a él. De esta manera, el atacante podría acceder al pedido del usuario ‘B‘ sin la debida autorización.
+
+Para prevenir la vulnerabilidad IDOR, es importante validar adecuadamente la autorización del usuario para acceder a los recursos, tanto en la interfaz de usuario como en las solicitudes directas a través de URL. Además, se recomienda restringir los permisos de acceso a los recursos y mantener actualizado el software y los sistemas operativos.
+
+A continuación, se comparten los enlaces correspondientes a los laboratorios que nos estaremos desplegando en esta clase para practicar esta vulnerabilidad:
+
+- XVWA 1: https://www.vulnhub.com/entry/xtreme-vulnerable-web-application-xvwa-1,209/
+- SKF-LABS IDOR: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/IDOR
+
 
 
 ## 6.28 Intercambio de recursos de origen cruzado (CORS)
 
+El Intercambio de recursos de origen cruzado (CORS) es un mecanismo que permite que un servidor web restrinja el acceso a recursos de diferentes orígenes, es decir, de diferentes dominios o protocolos. CORS se utiliza para proteger la privacidad y seguridad de los usuarios al evitar que otros sitios web accedan a información confidencial sin permiso.
 
+Supongamos que tenemos una aplicación web en el dominio “example.com” que utiliza una API web en el dominio “api.example.com” para recuperar datos. Si la aplicación web está correctamente configurada para CORS, solo permitirá solicitudes de origen cruzado desde el dominio “example.com” a la API en el dominio “api.example.com“. Si se realiza una solicitud desde un dominio diferente, como “attacker.com“, la solicitud será bloqueada por el navegador web.
+
+Sin embargo, si la aplicación web no está correctamente configurada para CORS, un atacante podría aprovecharse de esta debilidad para acceder a recursos y datos confidenciales. Por ejemplo, si la aplicación web no valida la autorización del usuario para acceder a los recursos, un atacante podría inyectar código malicioso en una página web para realizar solicitudes a la API de la aplicación en el dominio “api.example.com“.
+
+El atacante podría utilizar herramientas automatizadas para probar diferentes valores de encabezados CORS y encontrar una configuración incorrecta que permita la solicitud desde otro dominio. Si el atacante tiene éxito, podría acceder a recursos y datos confidenciales que no deberían estar disponibles desde su sitio web. Por ejemplo, podría recuperar la información de inicio de sesión de los usuarios, modificar los datos de la aplicación, etc.
+
+Para prevenir este tipo de ataque, es importante configurar adecuadamente CORS en la aplicación web y asegurarse de que solo se permitan solicitudes de origen cruzado desde dominios confiables.
 
 
 ---

Introduccion-hacking-hack4u/tema_6_owasp/README8.md

@@ -11,19 +11,73 @@
 
 ## 6.29 Ataque de Truncado SQL (SQL Truncation Attack)
 
+El ataque de truncado SQL, también conocido como SQL Truncation, es una técnica de ataque en la que un atacante intenta truncar o cortar una consulta SQL para realizar acciones maliciosas en una base de datos.
+
+Un ejemplo común de este tipo de ataque es cuando una aplicación web tiene un campo de entrada que limita la longitud de los datos, como el correo electrónico, y no valida adecuadamente los datos de entrada.
+
+Supongamos por ejemplo una página la cual dispone de un campo de registro para crear un nuevo usuario. En este campo de registro, el usuario debe proporcionar una dirección de correo y la contraseña del usuario en cuestión que desea crear. Ahora bien, de cara a la inserción de estos datos en la base de datos, supongamos que el campo correspondiente a la dirección email que introduce el usuario, está limitado a 17 caracteres en la base de datos.
+
+Suponiendo que por ejemplo el usuario ‘admin@admin.com‘ ya existe en la base de datos, de primeras no sería posible registrar este mismo usuario, debido a que la query SQL que se aplicaría por detrás lo consideraría como una entrada duplicada. Sin embargo, dado que el correo ‘admin@admin.com‘ tiene un total de 15 caracteres y todavía no hemos llegado al límite, un atacante lo que podría intentar hacer es registrar al usuario ‘admin@admin.com  a‘, o de otra forma para que lo veáis mejor: ‘admin@admin.com[espacio][espacio]a‘.
+
+Esta nueva cadena que hemos representado para el correo electrónico, en este caso tiene un total de 18 caracteres. De primeras el correo es distinto al correo ya existente en la base de datos (admin@admin.com), sin embargo, debido a su limitación en 17 caracteres, tras pasar el primer filtro y proceder a su inserción en la base de datos, la longitud total de la cadena se acota a los 17 caracteres, resultando en la cadena ‘admin@admin.com  ‘, o dicho de otra forma: ‘admin@admin.com[espacio][espacio]‘.
+
+Ahora bien, ¿qué pasa con los espacios?, pues dado que no representan “información de valor”, por decirlo de alguna forma, lo que sucederá es que se truncarán. A lo que nos referimos con esto del truncado de los espacios al final de la cadena, es a la eliminación automática de los mismos. De esta forma, la cadena resultante final se quedaría en ‘admin@admin.com‘, consiguiendo tras su inserción en la base de datos cambiar su contraseña a la especificada durante la fase de registro para nuestro supuesto “nuevo usuario“.
+
+Este ataque funcionará para casos donde la aplicación web no valide adecuadamente los datos de entrada y corte o trunque la consulta SQL en lugar de mostrar un mensaje de error. En consecuencia, el atacante puede aprovechar esta debilidad para realizar acciones maliciosas en la base de datos, como modificar o eliminar datos, acceder a información confidencial o tomar el control de una cuenta de usuario.
+
+Para prevenir el ataque de truncado SQL, es importante validar adecuadamente todos los datos de entrada de usuario que se utilizan en las consultas SQL. La validación debe incluir tanto la longitud como el formato de los datos de entrada.
+
+A continuación, se os proporciona el enlace directo de descarga a la máquina Tornado de Vulnhub, la cual desplegamos en esta clase para explotar el ataque de truncado SQL:
+
+- Máquina Tornado de Vulnhub: https://www.vulnhub.com/entry/ia-tornado,639/
 
 
 ## 6.30 Session Puzzling / Session Fixation / Session Variable Overloading
 
+Session Puzzling, Session Fixation y Session Variable Overloading son diferentes nombres correspondientes a vulnerabilidades de seguridad que afectan la gestión de sesiones en una aplicación web.
+
+La vulnerabilidad de Session Fixation se produce cuando un atacante establece un identificador de sesión válido para un usuario y luego espera a que el usuario inicie sesión. Si el usuario inicia sesión con ese identificador de sesión, el atacante podría acceder a la sesión del usuario y realizar acciones maliciosas en su nombre. Para lograr esto, el atacante puede engañar al usuario para que haga clic en un enlace que incluye un identificador de sesión válido o explotar una debilidad en la aplicación web para establecer el identificador de sesión.
+
+El término “Session Puzzling” se utiliza a veces para referirse a la misma vulnerabilidad, pero desde el punto de vista del atacante que intenta adivinar o generar identificadores de sesión válidos.
+
+Por último, el término “Session Variable Overloading” se refiere a un tipo específico de ataque de Session Fixation en el que el atacante envía una gran cantidad de datos a la aplicación web con el objetivo de sobrecargar las variables de sesión. Si la aplicación web no valida adecuadamente la cantidad de datos que se pueden almacenar en las variables de sesión, el atacante podría sobrecargarlas con datos maliciosos y causar problemas en el rendimiento de la aplicación.
+
+Para prevenir estas vulnerabilidades, es importante utilizar identificadores de sesión aleatorios y seguros, validar la autenticación y autorización del usuario antes de establecer una sesión y limitar la cantidad de datos que se pueden almacenar en las variables de sesión.
 
 
 ## 6.31 Enumeración y explotación de Json Web Tokens (JWT)
 
+Los Json Web Tokens (JWT) son un tipo de token utilizado en la autenticación y autorización de usuarios en aplicaciones web. JWT es un estándar abierto (RFC 7519) que define un formato compacto y seguro para transmitir información entre diferentes partes de forma confiable.
+
+En lo que respecta a la fase de enumeración y explotación de un JWT, esto se produce cuando un atacante es capaz de obtener información sobre los JWT que se utilizan en la aplicación, lo que podría permitir al atacante explotar las debilidades en la autenticación y autorización de la aplicación.
+
+La enumeración de los JWT se produce cuando un atacante utiliza técnicas de fuerza bruta o cierta ingeniería inversa para obtener información sobre los JWT utilizados por la aplicación web. Por ejemplo, el atacante podría intentar adivinar los valores de los JWT mediante la construcción de tokens falsos, tratando de validar en todo momento si la aplicación web los acepta o no. Si el atacante tiene éxito en la enumeración de un JWT válido, podría obtener información confidencial, como nombres de usuario, contraseñas, roles de usuario y otros datos de autenticación y autorización.
+
+La explotación de los JWT se produce cuando un atacante utiliza la información obtenida de la enumeración del JWT para explotar debilidades en la aplicación. Por ejemplo, si la aplicación web utiliza JWT para la autenticación, pero no valida adecuadamente la firma del JWT, un atacante podría falsificar el token y acceder a la aplicación web como si fuera un usuario legítimo.
+
+Para prevenir la enumeración y explotación de los JWT, es importante utilizar prácticas seguras de desarrollo web, como la validación adecuada de las solicitudes de entrada, la gestión segura de las claves de firma JWT y la limitación del tiempo de expiración de los JWT.
+
+A continuación, se os proporciona el enlace directo al proyecto de Github SKF-LABS, el cual estaremos usando para practicar la enumeración y explotación de los JWT:
+
+- SKF-LABS: https://github.com/blabla1337/skf-labs
 
 
 ## 6.32 Condiciones de carrera (Race conditions)
 
+Las condiciones de carrera (también conocidas como Race Condition) son un tipo de vulnerabilidad que puede ocurrir en sistemas informáticos donde dos o más procesos o hilos de ejecución compiten por los mismos recursos sin que haya un mecanismo adecuado de sincronización para controlar el acceso a los mismos.
 
+Esto significa que si dos procesos intentan acceder a un mismo recurso compartido al mismo tiempo, puede ocurrir que la salida de uno o ambos procesos sea impredecible, o incluso que se produzca un comportamiento no deseado en el sistema.
+
+Los atacantes pueden aprovecharse de las condiciones de carrera para llevar a cabo ataques de denegación de servicio (DoS), sobreescribir datos críticos, obtener acceso no autorizado a recursos, o incluso ejecutar código malicioso en el sistema.
+
+Por ejemplo, supongamos que dos procesos intentan acceder a un archivo al mismo tiempo: uno para leer y el otro para escribir. Si no hay un mecanismo adecuado para sincronizar el acceso al archivo, puede ocurrir que el proceso de lectura lea datos incorrectos del archivo, o que el proceso de escritura sobrescriba datos importantes que necesitan ser preservados.
+
+El impacto de las condiciones de carrera en la seguridad depende de la naturaleza del recurso compartido y del tipo de ataque que se pueda llevar a cabo. En general, las condiciones de carrera pueden permitir a los atacantes acceder a recursos críticos, modificar datos importantes, o incluso tomar el control completo del sistema. Por lo tanto, es importante que los desarrolladores y administradores de sistemas tomen medidas para evitar y mitigar las condiciones de carrera en sus sistemas.
+
+A continuación, se os comparte el enlace directo a los proyectos de Github los cuales estaremos empleando en esta clase para practicar las Race Condition:
+
+- SKF-LABS Race Condition: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/RaceCondition
+- SKF-LABS Race Condition 2: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/RaceCondition-file-write