ageofalgorithms/mahoraga-webapp-defenderSistema de defensa reactivo para sitios web impulsado por IA que detecta ataques, los analiza y parchea el código fuente de forma autónoma en tiempo real utilizando agentes LLM.
Sistema de defensa reactivo para aplicaciones web impulsado por IA, diseñado para resistir ataques automatizados con IA en tiempo real.
Mahoraga Defender es una Prueba de Concepto de un sistema de defensa reactivo, independiente del tipo de atacante, y en tiempo real. El mecanismo central consiste en engañar a un adversario para que realice descubrimientos y ataques en un entorno benigno y falso (entorno "sombra") y registrar estos ataques. Luego, un agente LLM analiza los registros y entrega los detalles de cualquier exploit detectado a más agentes LLM para que corrijan las vulnerabilidades y desplieguen los parches.
El sistema está diseñado para ser totalmente automatizado, con optimización de costos de API en mente. Se creó una interfaz gráfica para monitorear fácilmente los registros de tráfico, la actividad de los agentes y el pipeline de parches, así como para controlar la cantidad de agentes a desplegar.
El sitio web objetivo (víctima) es un fork de crAPI (Completely Ridiculous API), una aplicación web intencionalmente vulnerable creada por OWASP para la enseñanza de pruebas de seguridad en APIs. crAPI simula una plataforma de propietarios de vehículos con microservicios que cubren las vulnerabilidades de API del OWASP Top 10. El defensor está diseñado para distinguir claramente entre sesiones de usuarios normales y adversarias, de modo que los usuarios normales no experimenten ninguna caída en la calidad de la experiencia de usuario mientras el defensor protege el sitio web de los atacantes.
Nuestro fork (crapi-fork/) añade:
Se mantiene una copia prístina en crapi-original/ para poder reiniciar el entorno entre experimentos.
crapi-fork/. Opera en un entorno bash aislado con acceso restringido solo a crapi-fork/.Al desplegar, los servicios Python se recargan en caliente mediante gunicorn (instantáneo), mientras que los servicios Java/Go se reconstruyen mediante docker compose up -d --build.
¿Por qué no hay un agente Tester? Consideramos agregar un agente dedicado de pruebas de usuario y un entorno de pruebas separado, pero ambos fueron eliminados para mantener el sistema ligero.
conda create -n XYZ python=3.13, luego conda activate XYZ).pip install -r requirements.txt./start.sh desde el directorio raíz del proyecto — restablece el código fuente de crapi-fork/ desde crapi-original/, reconstruye todos los servicios, planta banderas y honeypots.python3 -m harness.main --app-url http://localhost:8888 -v.localhost:8888 (la descripción del desafío está en localhost:8888/challenge). Si realiza pruebas de penetración usando un agente de IA, el agente no debe tener acceso a los procesos internos de Docker, ya que esto se consideraría trampa.localhost:3000 para ver registros en tiempo real, acciones de los agentes, parches, banderas capturadas, etc.docker compose down -v para eliminar los contenedores Docker y las bases de datos que se iniciaron para este proyecto.Panel de control: http://localhost:3000
Una barra de estado global de agentes es visible en todas las pestañas, mostrando la salud del agente (activo/colgado/inactivo/error) con controles de escalado.
Visor de registros de solicitudes de producción/sombra en pantalla dividida en tiempo real con entradas coloreadas por severidad y agrupación de tráfico
Feed de actividad por agente con indicaciones del sistema, llamadas a herramientas y etiquetas de modelo LLM
Tablero Kanban: Detectado → Reparando → Revisando → Desplegado, con panel de detalle redimensionable
Diffs de código, archivos modificados, comandos de reversión y línea de tiempo por parche
El sistema utiliza cualquier API compatible con OpenAI. Configure los modelos en config/llm.yaml:
# Shadow Analyzer — lee los registros de sombra para detectar exploits (sin llamadas a herramientas)
shadow_analyzer:
provider: gemini
model: gemini-2.5-flash
api_key_env: GEMINI_API_KEY # definido en harness/.env
pricing:
input_per_million: 0.30
output_per_million: 2.50
# Fixer — parchea el código fuente (agente con llamadas a herramientas)
fixer:
provider: gemini
model: gemini-3-flash-preview
api_key_env: GEMINI_API_KEY # definido en harness/.env
pricing:
input_per_million: 0.50
output_per_million: 3.00
# Reviewer — verifica los parches (agente con llamadas a herramientas)
reviewer:
provider: gemini
model: gemini-3-flash-preview
api_key_env: GEMINI_API_KEY # definido en harness/.env
pricing:
input_per_million: 0.50
output_per_million: 3.00
Para cambiar de proveedor, modifique provider y model, luego establezca la clave API correspondiente en harness/.env:
Proveedores compatibles: OpenAI, Gemini, Anthropic, Groq, Together, Ollama, Mistral, DeepSeek, Fireworks, xAI, Perplexity, OpenRouter, Zhipu.
Agregue proveedores personalizados añadiendo su URL base a la sección providers en el YAML.
providers:
openai: https://api.openai.com/v1
gemini: https://generativelanguage.googleapis.com/v1beta/openai/
anthropic: https://api.anthropic.com/v1/
groq: https://api.groq.com/openai/v1
... # agregue más si es necesario
Nota: Solo unos pocos proveedores de API tienen un límite de tasa lo suficientemente alto como para soportar 3 o más agentes trabajando simultáneamente. Google Gemini es uno de ellos.
Agradecimientos especiales a d3lta05 (LinkedIn) y aleemladha por su ayuda con las pruebas de penetración.