90 lines
9.8 KiB
Markdown
90 lines
9.8 KiB
Markdown
# README9.md
|
|
|
|
|
|
Índice de subtermas:
|
|
- [README9.md](#README9.md)
|
|
- [6.33 Inyecciones CSS (CSSI)](#633-inyecciones-css-cssi)
|
|
- [6.34 Python - Ataque de Deserialización Yaml (DES-Yaml)](#634-python---ataque-de-deserialización-yaml-des-yaml)
|
|
- [6.35 Python - Ataque de Deserialización Pickle (DES-Pickle)](#635-python---ataque-de-deserialización-pickle-des-pickle)
|
|
- [6.36 GraphQL Introspection, Mutations e IDORs](#636-graphql-introspection-mutations-e-idors)
|
|
|
|
## 6.33 Inyecciones CSS (CSSI)
|
|
|
|
Las Inyecciones CSS (CSSI) son un tipo de vulnerabilidad web que permite a un atacante inyectar código CSS malicioso en una página web. Esto ocurre cuando una aplicación web confía en entradas no confiables del usuario y las utiliza directamente en su código CSS, sin realizar una validación adecuada.
|
|
|
|
El código CSS malicioso inyectado puede alterar el estilo y diseño de la página, permitiendo a los atacantes realizar acciones como la suplantación de identidad o el robo de información confidencial.
|
|
|
|
Las Inyecciones CSS (CSSI) pueden ser utilizadas por los atacantes como un vector de ataque para explotar vulnerabilidades de Cross-Site Scripting (XSS). Imagina que una aplicación web permite a los usuarios introducir texto en un campo de entrada que se muestra en una página web. Si el desarrollador de la aplicación no valida y filtra adecuadamente el texto introducido por el usuario, un atacante podría inyectar código malicioso en el campo de entrada, incluyendo código Javascript.
|
|
|
|
Si el código CSS inyectado es lo “suficientemente complejo”, puede hacer que el navegador web interprete el código como si fuera código JavaScript. Esto significa que el código CSS malicioso puede ser utilizado para inyectar código JavaScript en la página web, lo que se conoce como una inyección de JavaScript inducida por CSS (CSS-Induced JavaScript Injection).
|
|
|
|
Una vez que el código JavaScript ha sido inyectado en la página, este puede ser utilizado por el atacante para realizar un ataque de Cross-Site Scripting (XSS). Una vez en este punto, el atacante podría ser capaz de inyectar un script malicioso que robe las credenciales del usuario o que los redirija a una página web falsa, entre otros muchos posibles vectores.
|
|
|
|
A continuación, se os proporciona el enlace directo del proyecto de Github, el cual utilizamos en esta clase para desplegar el entorno vulnerable con el objetivo de practicar las inyecciones CSS:
|
|
|
|
- SKF-LABS CSSI: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/CSSI
|
|
|
|
|
|
|
|
## 6.34 Python - Ataque de Deserialización Yaml (DES-Yaml)
|
|
|
|
Un Ataque de Deserialización Yaml (DES-Yaml) es un tipo de vulnerabilidad que puede ocurrir en aplicaciones Python que usan YAML (Yet Another Markup Language) para serializar y deserializar objetos.
|
|
|
|
La vulnerabilidad se produce cuando un atacante es capaz de controlar la entrada YAML que se pasa a una función de deserialización en la aplicación. Si el código de la aplicación no valida adecuadamente la entrada YAML, puede permitir que un atacante inyecte código malicioso en el objeto deserializado.
|
|
|
|
Una vez que el objeto ha sido deserializado, el código malicioso puede ser ejecutado en el contexto de la aplicación, lo que puede permitir al atacante tomar el control del sistema, acceder a datos sensibles, o incluso ejecutar código remoto.
|
|
|
|
Los atacantes pueden aprovecharse de las vulnerabilidades de DES-Yaml para realizar ataques de denegación de servicio (DoS), inyectar código malicioso, o incluso tomar el control completo del sistema.
|
|
|
|
El impacto de un Ataque de Deserialización Yaml depende del tipo y la sensibilidad de los datos que se puedan obtener, pero puede ser muy grave. Por lo tanto, es importante que los desarrolladores de aplicaciones Python validen y filtren adecuadamente la entrada YAML que se pasa a las funciones de deserialización, y que utilicen técnicas de seguridad como la limitación de recursos para prevenir ataques DoS y la desactivación de la deserialización automática de objetos no confiables.
|
|
|
|
A continuación, se os proporciona el proyecto de Github correspondiente al laboratorio que estaremos desplegando en esta clase para practicar esta vulnerabilidad:
|
|
|
|
- SKF-LABS DES-Yaml: https://github.com/blabla1337/skf-labs/tree/master/python/DES-Yaml
|
|
|
|
|
|
## 6.35 Python - Ataque de Deserialización Pickle (DES-Pickle)
|
|
|
|
Un Ataque de Deserialización Pickle (DES-Pickle) es un tipo de vulnerabilidad que puede ocurrir en aplicaciones Python que usan la biblioteca Pickle para serializar y deserializar objetos.
|
|
|
|
La vulnerabilidad se produce cuando un atacante es capaz de controlar la entrada Pickle que se pasa a una función de deserialización en la aplicación. Si el código de la aplicación no valida adecuadamente la entrada Pickle, puede permitir que un atacante inyecte código malicioso en el objeto deserializado.
|
|
|
|
Una vez que el objeto ha sido deserializado, el código malicioso puede ser ejecutado en el contexto de la aplicación, lo que puede permitir al atacante tomar el control del sistema, acceder a datos sensibles, o incluso ejecutar código remoto.
|
|
|
|
Los atacantes pueden aprovecharse de las vulnerabilidades de DES-Pickle para realizar ataques de denegación de servicio (DoS), inyectar código malicioso, o incluso tomar el control completo del sistema.
|
|
|
|
El impacto de un Ataque de Deserialización Pickle depende del tipo y la sensibilidad de los datos que se puedan obtener, pero puede ser muy grave. Por lo tanto, es importante que los desarrolladores de aplicaciones Python validen y filtren de forma adecuada la entrada Pickle que se pasa a las funciones de deserialización, y que utilicen técnicas de seguridad como la limitación de recursos para prevenir ataques DoS y la desactivación de la deserialización automática de objetos no confiables.
|
|
|
|
A continuación, se os proporciona el enlace al proyecto de Github el cual estaremos utilizando en esta clase para explotar la vulnerabilidad DES-Pickle:
|
|
|
|
- SKF-LABS DES-Pickle: https://github.com/blabla1337/skf-labs/tree/master/python/DES-Pickle
|
|
|
|
|
|
## 6.36 GraphQL Introspection, Mutations e IDORs
|
|
|
|
GraphQL es un lenguaje de consulta para APIs (Application Programming Interfaces) que se ha vuelto cada vez más popular en los últimos años. A diferencia de las APIs tradicionales que tienen endpoints fijos, GraphQL permite a los clientes solicitar sólo la información que necesitan y obtener una respuesta personalizada en función de sus necesidades.
|
|
|
|
Introspection en GraphQL es un mecanismo que permite a los clientes obtener información sobre el esquema GraphQL de una API. Esto significa que los clientes pueden explorar y descubrir los tipos de datos, los campos y las relaciones que existen en la API, lo que puede ser muy útil para los desarrolladores que necesitan construir clientes GraphQL. Sin embargo, la introspección también puede ser utilizada por los atacantes para obtener información sensible sobre la estructura y los datos que existen en la API, lo que puede ser utilizado para llevar a cabo ataques más sofisticados.
|
|
|
|
Por otro lado, las Mutations en GraphQL son operaciones que permiten a los clientes modificar los datos en la API. A diferencia de las consultas, que sólo permiten la lectura de datos, las mutaciones permiten a los clientes agregar, actualizar o eliminar datos. Esto significa que las mutaciones tienen el potencial de ser utilizadas para realizar cambios importantes en la base de datos subyacente de la API. Si no se protegen adecuadamente, las mutaciones pueden ser explotadas por los atacantes para realizar cambios malintencionados en la API, como la eliminación de datos importantes o la creación de nuevos registros.
|
|
|
|
En el contexto de GraphQL, los IDORs pueden ocurrir cuando un atacante es capaz de adivinar o enumerar identificadores (IDs) de objetos dentro de la API, y puede utilizar esos IDs para acceder a objetos a los que no debería tener acceso. Esto puede ocurrir porque los desarrolladores de la API pueden no haber implementado adecuadamente los mecanismos de autenticación y autorización en su API.
|
|
|
|
Por ejemplo, supongamos que una API GraphQL permite a los usuarios acceder a información sobre sus propios pedidos utilizando el ID de pedido. Si el desarrollador de la API no ha implementado la autorización adecuada, un atacante podría utilizar la introspección de GraphQL para descubrir todos los IDs de pedido existentes en la API, incluyendo los pedidos de otros usuarios. El atacante podría luego utilizar estos IDs para acceder a los pedidos de otros usuarios sin la debida autorización, lo que constituye un IDOR.
|
|
|
|
Los atacantes también pueden utilizar las Mutaciones de GraphQL para llevar a cabo ataques IDOR. Por ejemplo, supongamos que una API GraphQL permite a los usuarios actualizar la información de sus propios pedidos. Si el desarrollador de la API no ha implementado adecuadamente la autorización, un atacante podría utilizar una mutación para actualizar los datos de los pedidos de otros usuarios, utilizando los IDs de pedido que ha descubierto mediante la introspección.
|
|
|
|
En resumen, GraphQL es un lenguaje de consulta para APIs que permite a los clientes solicitar sólo la información que necesitan. Es importante que los desarrolladores de APIs protejan adecuadamente la introspección y las mutaciones para evitar ataques maliciosos por parte de los atacantes.
|
|
|
|
A continuación, se os proporciona el enlace directo a los distintos proyectos de Github los cuales empleamos en esta clase para enumerar y abusar del GraphQL:
|
|
|
|
- GraphQL Introspection: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/Graphql-Introspection
|
|
- GraphQL Mutations: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/Graphql-Mutations
|
|
- GraphQL Injection: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/Graphql-Injection
|
|
- GraphQL IDOR: https://github.com/blabla1337/skf-labs/tree/master/nodeJs/Graphql-IDOR
|
|
|
|
|
|
---
|
|
|
|
[README8.md](README8.md) <--> [README.md principal](README.md)
|