Categorías

Una referencia directa insegura a objetos (IDOR, o BOLA en APIs) aparece cuando la aplicación entrega o modifica un recurso solo porque le pasas su identificador, sin comprobar que sea tuyo. Basta con cambiar un número en la URL o en el cuerpo de la petición para leer facturas, mensajes o perfiles ajenos. Es de los fallos más reportados en bug bounty porque es fácil de pasar por alto y fácil de probar.

El cross-site scripting permite colar JavaScript en una página que luego se ejecuta en el navegador de otra persona, con su sesión y sus permisos. Puede ser reflejado (viaja en el enlace), almacenado (queda guardado en la web) o basado en DOM. En estos casos verás de dónde entraba el código, por qué el filtro no lo paraba y cómo se corrigió el escapado.

En una falsificación de peticiones del lado del servidor (SSRF), el atacante consigue que el propio servidor haga peticiones a donde él quiere: servicios internos, metadatos de la nube o puertos que desde fuera no se ven. Suele esconderse en funciones inocentes como importar desde una URL, generar vistas previas o recibir webhooks.

La inyección SQL ocurre cuando datos del usuario acaban dentro de una consulta a la base de datos sin separarse del código de la consulta. Según el caso permite leer tablas enteras, saltarse un inicio de sesión o modificar datos. La defensa es conocida (consultas parametrizadas), pero sigue apareciendo en filtros, ordenaciones y búsquedas avanzadas.

Fallos en cómo una aplicación crea, guarda o delega sesiones: flujos OAuth con redirecciones mal validadas, tokens que no caducan, cookies sin las protecciones adecuadas o sesiones que sobreviven a un cambio de contraseña. El resultado habitual es el robo o la toma de cuentas.

La ejecución remota de código (RCE) es el escenario más grave: el atacante consigue ejecutar sus propios comandos en el servidor. Suele llegar por deserialización insegura, inyección de comandos, plantillas o subida de ficheros, y casi siempre recibe la severidad más alta.

Fallos propios de las APIs: endpoints que devuelven más datos de los que la aplicación muestra, asignación masiva de campos que no deberían poder tocarse, versiones antiguas olvidadas o límites de uso que no existen. Muchos se descubren leyendo con calma las peticiones que hace la propia aplicación.

Errores en las reglas de la aplicación, no en el código de bajo nivel: aplicar un descuento dos veces, saltarse un paso de un proceso, usar cantidades negativas o aprovechar una condición de carrera. No hay herramienta que los detecte sola; hay que entender qué debería pasar y probar qué pasa de verdad.

Formas de entrar donde no se debe: recuperaciones de contraseña manipulables, segundos factores que se pueden saltar, códigos que admiten fuerza bruta o comprobaciones de identidad que dependen de datos que controla el atacante.

Problemas que no vienen del código sino de cómo está desplegado: paneles expuestos, cabeceras de seguridad ausentes, CORS demasiado permisivo, subdominios huérfanos que se pueden tomar o ficheros internos accesibles desde fuera.

Fallos típicos de programas en C y C++: desbordamientos de búfer y de pila, lecturas fuera de límites, uso de memoria ya liberada (use-after-free) o desbordamientos de enteros. Según el caso permiten tumbar el programa, leer memoria que no se debería o, en el peor escenario, ejecutar código.

Formas de dejar un servicio inutilizable o muy lento con poco esfuerzo: peticiones pequeñas que consumen mucha CPU, cachés o colas que crecen sin límite, o entradas que provocan bucles o bloqueos. En bug bounty solo cuentan las que no requieren inundar el servicio de tráfico.

Fallos al proteger las comunicaciones o los datos cifrados: certificados que no se validan bien, conexiones reutilizadas sin volver a comprobar la confianza, algoritmos débiles o claves mal gestionadas. Suelen permitir interceptar o suplantar a una de las partes.

El recorrido de directorios permite salirse de la carpeta prevista usando rutas como ../ o barras invertidas, para leer o escribir ficheros donde no se debe: configuración con contraseñas, claves o ficheros de otros usuarios. Aparece al descargar, subir, descomprimir o mover ficheros.

Inyecciones distintas de SQL: cabeceras de correo (SMTP), comandos del sistema, plantillas del servidor (SSTI), LDAP o cabeceras HTTP. La idea es la misma: un dato del usuario acaba interpretado como parte de una orden.

Información sensible que queda al alcance de quien no debería verla: claves que se guardan donde no toca, datos personales en respuestas o registros, ficheros de copia accesibles o mensajes de error demasiado explícitos.

Reportes que no encajan en ninguna de las demás categorías: técnicas menos habituales o fallos que mezclan varios tipos.