Saltar al contenido

Usando OWASP Juice Shop - Resolviendo tus primeros desafíos en OWASP Juice Shop

Posteado en 7 minutos de lectura
Índice

Este artículo es el segundo de una serie sobre OWASP Juice Shop. Si aún no has instalado la aplicación, puedes revisar el post anterior.

Introducción a la resolución de desafíos

Una vez que tenemos OWASP Juice Shop instalado y funcionando, es hora de adentrarnos en lo más interesante: resolver los desafíos de seguridad que esconde esta aplicación deliberadamente vulnerable.

Pero antes de empezar a “hackear”, necesitamos entender cómo funciona el sistema de desafíos de Juice Shop. El corazón de esta experiencia es el Score Board o Tablero de Puntuaciones, una página especial que lista todos los retos disponibles, clasificados por categoría y nivel de dificultad.

El sistema de dificultad

Los desafíos en Juice Shop están clasificados con estrellas según su dificultad:

  • ⭐ (1 estrella): Desafíos fáciles, ideales para principiantes
  • ⭐⭐ (2 estrellas): Dificultad baja-media
  • ⭐⭐⭐ (3 estrellas): Dificultad media
  • ⭐⭐⭐⭐ y más: Desafíos avanzados

En este artículo nos centraremos en resolver tres desafíos de dificultad ⭐ (1 estrella), perfectos para quienes comienzan en el mundo de la seguridad web.

Primer desafío: Encontrando el Score Board (★)

¡Aquí tenemos nuestro primer reto! El Score Board no está enlazado desde ninguna parte visible de la aplicación. Encontrarlo es, de hecho, el primer desafío que debemos superar.

¿Por qué es importante?

En aplicaciones reales, es común encontrar páginas administrativas o confidenciales que no están enlazadas desde la interfaz principal pero siguen siendo accesibles si conoces la URL exacta. Estas páginas “ocultas” pueden representar un riesgo de seguridad si contienen información sensible.

Solución paso a paso

Hay varias formas de encontrar el Score Board:

Método 1: Inspección del código fuente

  1. Abre tu navegador y accede a Juice Shop (http://localhost:3000).
  2. Presiona F12 para abrir las herramientas de desarrollo.
  3. Ve a la pestaña “Sources” (Chrome) o “Debugger” (Firefox).
  4. Busca el archivo principal de JavaScript (normalmente main.js).
  5. Presiona Ctrl+F para buscar y escribe “score”. También puede usar palabras como route, router o link ya que se usan comúnmente para definir los enlaces en los sitios.
  6. Entre los resultados encontrarás referencias a la ruta /score-board.

Búsqueda en el código fuente

Método 2: Adivinación directa

Como muchas aplicaciones web modernas siguen convenciones similares para nombrar sus rutas, podríamos intentar directamente algunas URL comunes:

  1. Intenta acceder a http://localhost:3000/#/score-board o http://localhost:3000/score-board
  2. ¡Éxito! La página del Score Board aparecerá, mostrando todos los desafíos disponibles

Score Board de Juice Shop

Entendiendo el Score Board

Una vez que accedemos al Score Board, podemos ver:

  • Todos los desafíos disponibles organizados por categorías.
  • Su nivel de dificultad (estrellas).
  • Una breve descripción de cada uno.
  • El estado (resuelto/no resuelto).
  • Los desafíos no disponibles dependiendo de la instalación.

El tablero también ofrece filtros para mostrar desafíos por dificultad, categoría o estado, lo que facilita enfocarse en retos específicos.

Segundo desafío: Realizando un ataque DOM XSS (★)

Nuestro siguiente desafío consiste en ejecutar un ataque XSS (Cross-Site Scripting) basado en DOM.

¿Qué es DOM XSS?

El XSS basado en DOM es un tipo de vulnerabilidad donde el código malicioso se ejecuta a través del Document Object Model (DOM) del navegador. A diferencia de otros tipos de XSS, el código malicioso nunca se envía al servidor, sino que se ejecuta completamente en el lado del cliente.

Esta vulnerabilidad puede permitir a un atacante: - Robar cookies de sesión. - Capturar credenciales. - Redireccionar a sitios maliciosos. - Modificar el contenido de la página.

Resolución paso a paso

El desafío nos pide específicamente usar el payload: <iframe src="javascript:alert(xss)">

  1. Primero, debemos identificar dónde podría estar la vulnerabilidad. El campo de búsqueda en la barra de navegación es un buen candidato, ya que procesa la entrada del usuario.

  2. Haz clic en la barra de búsqueda en la parte superior de la página.

  3. Introduce el payload proporcionado: <iframe src="javascript:alert(xss)">

  4. Presiona Enter para ejecutar la búsqueda.

  5. ¡Bingo! Un cuadro de alerta con el texto “xss” aparecerá, indicando que hemos explotado exitosamente la vulnerabilidad.

Introducir XSS

Alerta XSS

¿Por qué funcionó?

El campo de búsqueda en Juice Shop es vulnerable porque:

  1. La aplicación toma el texto de búsqueda directamente del usuario.
  2. Inserta este texto en el DOM sin sanear adecuadamente.
  3. El navegador interpreta el código HTML inyectado (en este caso, un iframe).
  4. El iframe ejecuta el código JavaScript contenido en su atributo “src”.

¿Cómo se previene?

Para prevenir vulnerabilidades DOM XSS, los desarrolladores deberían:

  • Escapar adecuadamente cualquier entrada de usuario antes de insertarla en el DOM.
  • Utilizar funciones seguras como textContent en lugar de innerHTML.
  • Implementar Content Security Policy (CSP) para restringir la ejecución de scripts.
  • Usar bibliotecas seguras de saneamiento HTML.

Tercer desafío: Accediendo a un documento confidencial (★)

El último desafío que abordaremos implica encontrar y acceder a un documento confidencial dentro de la aplicación.

El problema de seguridad

Este desafío representa un escenario común: archivos sensibles que se colocan en directorios accesibles públicamente sin las debidas restricciones de acceso. En aplicaciones reales, este tipo de error puede llevar a la filtración de:

  • Documentos internos.
  • Credenciales.
  • Información de clientes.
  • Código fuente.
  • Copias de seguridad de bases de datos.

Resolución paso a paso

  1. Primero, exploremos las secciones públicas de la aplicación. Visita la página “About Us” haciendo clic en el menú de hamburguesa y seleccionando “About Us”.

  2. En esta página, encontrarás un enlace a los “Términos de uso” (Check out our boring terms of use if you are interested in such lame stuff.) que lleva a una URL como http://localhost:3000/ftp/legal.md.

  3. Aquí tenemos una pista importante: la aplicación tiene una carpeta /ftp accesible públicamente.

  4. Intenta acceder directamente a esta carpeta cambiando la URL a http://localhost:3000/ftp.

  5. ¡Sorpresa! Podemos ver un listado de todos los archivos en este directorio:

Listado del directorio FTP

  1. Entre los archivos listados, verás uno llamado acquisitions.md. Este archivo contiene información confidencial sobre posibles adquisiciones empresariales.

  2. Haz clic en acquisitions.md para abrirlo.

  3. Al acceder a este documento, el desafío se marca automáticamente como resuelto en el Score Board.

Análisis de la vulnerabilidad

Esta vulnerabilidad se conoce como “Directory Listing” o “Path Traversal” y ocurre cuando:

  1. Los servidores web están configurados para mostrar el contenido de los directorios.
  2. No hay restricciones de acceso adecuadas para archivos sensibles.
  3. Falta una estructura adecuada de permisos.

Solución adecuada

Para prevenir este tipo de vulnerabilidad, se recomienda:

  • Deshabilitar el listado de directorios en el servidor web.
  • Implementar control de acceso para archivos sensibles.
  • Almacenar documentos confidenciales fuera del directorio público.
  • Utilizar un sistema de gestión documental con autenticación.
  • Implementar una estructura adecuada de permisos.

Recapitulando

Estos tres desafíos aparentemente simples nos muestran vulnerabilidades que siguen siendo extremadamente comunes en aplicaciones web reales:

  1. Recursos no enlazados pero accesibles: Muchas organizaciones creen erróneamente en la “seguridad por oscuridad”, asumiendo que si una página no está enlazada, no será encontrada.

  2. Falta de saneamiento de entrada: El saneamiento inadecuado de la entrada del usuario sigue siendo una de las principales causas de vulnerabilidades XSS, que pueden tener consecuencias graves.

  3. Exposición de archivos sensibles: La configuración incorrecta de directorios y permisos puede llevar a la exposición de información confidencial, lo que representa un riesgo significativo.

Mejores prácticas de seguridad

Para proteger las aplicaciones web contra estas vulnerabilidades básicas:

  1. Principio de menor privilegio: Proporciona acceso solo a lo que es estrictamente necesario.
  2. Defensa en profundidad: Implementa múltiples capas de seguridad.
  3. Validación y saneamiento: Valida y sanea todas las entradas del usuario.
  4. Auditorías regulares: Realiza pruebas de penetración y auditorías de código.
  5. Mantenimiento actualizado: Actualiza regularmente todas las dependencias y componentes.

Conclusión

Hemos completado con éxito nuestros primeros tres desafíos en OWASP Juice Shop, todos de dificultad ⭐ (1 estrella). Estas vulnerabilidades, aunque básicas, reflejan problemas reales que siguen afectando a muchas aplicaciones web modernas.

En nuestro próximo artículo, avanzaremos a desafíos de dificultad media (⭐⭐), donde exploraremos vulnerabilidades más complejas como inyección SQL, autenticación rota y falsificación de solicitudes entre sitios (CSRF).

¡Comparte tu experiencia en los comentarios!

Nota de seguridad: Las técnicas descritas en este artículo deben utilizarse únicamente en entornos controlados como OWASP Juice Shop. Realizar estas mismas acciones en aplicaciones reales sin autorización explícita es ilegal y puede tener consecuencias legales graves.