Hoy vamos a ver una de las vulnerabilidades más comunes y a la vez más infravaloradas en aplicaciones web: el famoso IDOR (Insecure Direct Object Reference). Un IDOR ocurre cuando una aplicación permite acceder a recursos internos —como datos de usuario, archivos, tickets, facturas o endpoints sensibles— simplemente cambiando un identificador en la URL o en la petición. En pocas palabras:Si puedes manipular id=123 por id=124 y acceder a información que no deberías, estás ante un IDOR. Ejemplo rápido: GET /api/user?id=103 Si cambias a: GET /api/user?id=104 …y puedes ver datos de otra persona, entonces la aplicación no está validando correctamente los privilegios, solo confía en el número que tú le pones. Esto, a nivel de seguridad, es un desastre. ¿Por qué pasa esto? Porque los desarrolladores suelen validar que la solicitud está “correctamente formada”, pero no validan si realmente el usuario tiene permiso para ver ese recurso Es decir:Validan la forma, pero no la autoridad. ¿Qué puede provocar un IDOR? - 🗂 Acceso a datos personales de otros usuarios - 💸 Modificación de pedidos, facturas o pagos - 🤯 Gestión de cuentas ajenas - 🔥 Escalación horizontal o incluso vertical - 🧨 Filtración masiva de información interna de la empresa Este tipo de fallos ha aparecido en programas enormes como Meta, TikTok, Uber, Google… y ha generado recompensas de miles de dólares en bug bounty. Si quieres ver cómo explotar un IDOR en entornos reales, cómo automatizar su detección y cómo reportarlo de forma profesional… 👉 Únete a Zhack Pro, mi comunidad y mentoría premium de hacking ético profesional: https://www.skool.com/zhack-3722

La SQL Injection (SQLi) es una de las vulnerabilidades más clásicas y poderosas del hacking web. A pesar de tener más de 20 años, sigue apareciendo en bug bounties y entornos reales, y si la sabes explotar bien… puede darte acceso completo a bases de datos y sistemas. 🔍 ¿Qué es una SQLi? Una inyección SQL ocurre cuando una aplicación web no filtra correctamente los datos que el usuario introduce, permitiendo que el atacante inserte código SQL malicioso dentro de una consulta legítima a la base de datos. Por ejemplo: SELECT * FROM users WHERE username = 'admin' AND password = '1234'; Si el campo de usuario no se valida, un atacante podría poner: admin' OR '1'='1 Y la consulta final quedaría: SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = '1234'; Lo que devuelve todas las filas → autenticación bypassed ✅ ⚔️ Tipos de SQL Injection Existen varias formas de inyección dependiendo de cómo se comporta la aplicación y qué feedback obtenemos.Aquí te dejo las principales 👇 1. Inyección Clásica (Error-Based) Basada en errores visibles del servidor SQL.Se explota cuando la aplicación muestra mensajes de error detallados que revelan la estructura de la base de datos. 🧠 Ejemplo:' ORDER BY 1--' UNION SELECT 1, @@version, user()-- 2. Blind SQLi (Boolean-Based) La aplicación no muestra errores, pero el comportamiento cambia dependiendo de si la consulta devuelve “verdadero” o “falso”. 🧩 Ejemplo: ' AND 1=1-- → Respuesta normal ' AND 1=2-- → No devuelve nada Así puedes ir preguntando bit a bit hasta extraer información. Si quieres aprender muchas sobre sqli y todas su formas te recomiendo que desbloquees Zhack PRO https://www.skool.com/zhack-3722/about?ref=5a73ec72dcdb489c8eab22ff09784f09

La vulnerabilidad XSS (Cross-Site Scripting) es una de las más comunes en aplicaciones web… y también una de las más peligrosamente subestimadas. Permite a un atacante inyectar código JavaScript malicioso en una página que otros usuarios visitan. ¿Resultado? Robo de cookies, suplantación de sesiones, defacement, ejecución de acciones en nombre de la víctima, y mucho más. ✅ ¿Cómo funciona realmente? 1. La aplicación web recibe datos del usuario (input). 2. No los valida ni los “escapa” correctamente. 3. Ese input se muestra en la página web, y el navegador lo interpreta como código ejecutable. 4. Ese código se ejecuta en el navegador de la víctima → secuestro de navegador. 💡 En resumen: el atacante no ataca directamente al servidor, ataca al usuario a través del servidor. 🎯 Tipos de XSS 1️⃣ Stored XSS (Persistente) El payload malicioso se guarda en la base de datos y se ejecuta cada vez que otro usuario carga esa página. 📌 Ejemplo clásico: - Dejas un comentario con <script>alert('Hacked')</script> en un foro. - Cada visitante que vea el comentario ejecuta ese script. ⚠️ Es el más peligroso, porque afecta a muchos usuarios sin necesidad de interacción. 2️⃣ Reflected XSS (No persistente) El script viaja dentro de una URL o parámetro, y se refleja temporalmente en la respuesta del servidor. 📌 Ejemplo: https://web.com/search?q=<script>alert('xss')</script> Si la página muestra “Resultados para <script>...” sin sanitizar, se ejecuta el script. 3️⃣ DOM-Based XSS (XSS en el navegador) Aquí el fallo no está en el servidor, sino en el JavaScript del lado del cliente.El DOM manipula datos inseguros (como location.hash, document.URL, etc.), y los inyecta en la página. 📌 Ejemplo: document.getElementById("resultado").innerHTML = location.hash.substring(1); Si accedes a: https://web.com/#<img src=x onerror=alert('XSS')>