89 lines
9.9 KiB
Markdown
89 lines
9.9 KiB
Markdown
# README8.md
|
||
|
||
|
||
Índice de subtermas:
|
||
- [README8.md](#README8.md)
|
||
- [6.29 Ataque de Truncado SQL (SQL Truncation Attack)](#629-ataque-de-truncado-sql-sql-truncation-attack)
|
||
- [6.30 Session Puzzling / Session Fixation / Session Variable Overloading](#630-session-puzzling--session-fixation--session-variable-overloading)
|
||
- [6.31 Enumeración y explotación de Json Web Tokens (JWT)](#631-enumeración-y-explotación-de-json-web-tokens-jwt)
|
||
- [6.32 Condiciones de carrera (Race conditions)](#632-condiciones-de-carrera-race-conditions)
|
||
|
||
|
||
## 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
|
||
|
||
|
||
|
||
---
|
||
|
||
[README.md principal](README.md)
|
||
|
||
[README7.md](README7.md) <--> [README9.md](README9.md)
|