84 lines
9.3 KiB
Markdown
84 lines
9.3 KiB
Markdown
# README7.md
|
||
|
||
Índice de subtermas:
|
||
- [README7.md](#README7.md)
|
||
- [6.25 Ataque ShellShock](#625-ataque-shellshock)
|
||
- [6.26 Inyecciones XPath](#626-inyecciones-xpath)
|
||
- [6.27 Insecure Direct Object Reference (IDORs)](#627-insecure-direct-object-reference-idors)
|
||
- [6.28 Intercambio de recursos de origen cruzado (CORS)](.#628-intercambio-de-recursos-de-origen-cruzado-cors)
|
||
|
||
|
||
## 6.25 Ataque ShellShock
|
||
|
||
Un ataque Shellshock es un tipo de ataque informático que aprovecha una vulnerabilidad en el intérprete de comandos Bash en sistemas operativos basados en Unix y Linux. Esta vulnerabilidad se descubrió en 2014 y se considera uno de los ataques más grandes y generalizados en la historia de la informática.
|
||
|
||
Esta vulnerabilidad en Bash permite a los atacantes ejecutar comandos maliciosos en el sistema afectado, lo que les permite tomar el control del sistema y acceder a información confidencial, modificar archivos, instalar programas maliciosos, etc.
|
||
|
||
La vulnerabilidad Shellshock se produce en el intérprete de comandos Bash, que es utilizado por muchos sistemas operativos Unix y Linux para ejecutar scripts de shell. El problema radica en la forma en que Bash maneja las variables de entorno. Los atacantes pueden inyectar código malicioso en estas variables de entorno, las cuales Bash ejecuta sin cuestionar su origen o contenido.
|
||
|
||
Los atacantes pueden explotar esta vulnerabilidad a través de diferentes vectores de ataque. Uno de ellos es a través del User-Agent, que es la información que el navegador web envía al servidor web para identificar el tipo de navegador y sistema operativo que se está utilizando. Los atacantes pueden manipular el User-Agent para incluir comandos maliciosos, que el servidor web ejecutará al recibir la solicitud.
|
||
|
||
A continuación se proporciona el enlace directo para la descarga de la máquina ‘SickOs 1.1‘. Esta máquina corresponde a la misma que estuvimos enumerando en la clase anterior, solo que en este caso procederemos con la fase de explotación haciendo uso de esta técnica:
|
||
|
||
- SickOs 1.1: https://www.vulnhub.com/entry/sickos-11,132/
|
||
|
||
|
||
## 6.26 Inyecciones XPath
|
||
|
||
XPath es un lenguaje de consultas utilizado en XML que permite buscar y recuperar información específica de documentos XML. Sin embargo, al igual que otros lenguajes de programación y consultas, XPath también puede tener vulnerabilidades que los atacantes pueden aprovechar para comprometer la seguridad de una aplicación web.
|
||
|
||
Las vulnerabilidades XPath son aquellas que se aprovechan de las debilidades en la implementación de consultas XPath en una aplicación web. A continuación, se describen algunos tipos de vulnerabilidades comunes en XPath:
|
||
|
||
- Inyección XPath: los atacantes pueden utilizar inyección de código malicioso en las consultas XPath para alterar el comportamiento esperado de la aplicación. Por ejemplo, pueden agregar una consulta maliciosa que recupere toda la información del usuario, incluso información confidencial como contraseñas.
|
||
- Fuerza bruta de XPath: los atacantes pueden utilizar técnicas de fuerza bruta para adivinar las rutas de XPath y recuperar información confidencial. Esta técnica se basa en intentar diferentes rutas XPath hasta encontrar una que devuelva información confidencial.
|
||
- Recuperación de información del servidor: los atacantes pueden utilizar consultas XPath maliciosas para obtener información sobre el servidor, como el tipo de base de datos, la versión de la aplicación, etc. Esta información puede ayudar a los atacantes a planear ataques más sofisticados.
|
||
- Manipulación de respuestas XPath: los atacantes pueden manipular las respuestas XPath de la aplicación web para obtener información adicional o alterar el comportamiento de la aplicación. Por ejemplo, pueden modificar una respuesta XPath para crear una cuenta de usuario sin permiso.
|
||
|
||
Para protegerse contra las vulnerabilidades de XPath, es importante validar todas las entradas de usuario y evitar la construcción dinámica de consultas XPath. Además, se recomienda restringir los permisos de acceso a los recursos de la aplicación web y mantener actualizado el software y los sistemas operativos. Por último, se recomienda utilizar herramientas de análisis de seguridad y realizar pruebas de penetración regulares para identificar y corregir cualquier vulnerabilidad en la aplicación web.
|
||
|
||
A continuación, se proporciona el enlace directo de descarga a la máquina XVWA 1 de Vulnhub, la cual usamos en esta clase para explotar las vulnerabilidades existentes en XPath:
|
||
|
||
- XVWA 1: https://www.vulnhub.com/entry/xtreme-vulnerable-web-application-xvwa-1,209/
|
||
- script Python [xpath_injection.py](./26_xpath/xpath_injection.py)
|
||
|
||
|
||
## 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.
|
||
|
||
|
||
---
|
||
|
||
[README.md principal](README.md)
|
||
|
||
[README6.md](README6.md) <--> [README8.md](README8.md)
|