RASP — Runtime Application Self-Protection — es una tecnología de seguridad que se ejecuta dentro de una aplicación y la protege desde el interior. Al instrumentar el runtime de la aplicación, RASP observa cómo se usa realmente la entrada y puede detectar y bloquear ataques en el momento de la explotación, con un contexto que una defensa perimetral nunca ve.
¿Cómo funciona RASP?
RASP se acopla al runtime de la aplicación — un agente JVM, un profiler .NET, un hook de instrumentación de Node — e intercepta las operaciones relevantes para la seguridad: consultas a la base de datos, acceso a archivos, ejecución de comandos, deserialización. Cuando los datos de una petición llegan a una de esas operaciones de una forma que coincide con una explotación (un parámetro que reescribe la estructura del SQL, una ruta que escapa de su directorio), RASP puede registrarla, alertar o bloquear la operación dentro del proceso.
La propiedad definitoria es el contexto. Un filtro perimetral adivina la malicia a partir de la forma de la petición; RASP observa lo que el código hace realmente con ella, lo que elimina la mayor parte del compromiso entre falsos positivos y falsos negativos.
RASP vs WAF vs monitoreo client-side
| WAF | RASP | Monitoreo en la capa del navegador | |
|---|---|---|---|
| Dónde se ejecuta | Delante de la app | Dentro del runtime del servidor | En la sesión del navegador del visitante |
| Ve | Peticiones y respuestas | La ejecución real del código | Los scripts que se ejecutan en la página |
| Punto ciego | Cómo se usa la entrada | Todo el lado del cliente | Los internos del servidor |
| Detiene | Patrones de ataque conocidos | Exploits que llegan al runtime | Skimming, scripts inyectados, exfiltración de datos |
| Despliegue | A nivel de red | Agente por lenguaje/runtime | Etiqueta de script |
Dónde termina RASP
El límite de RASP es el proceso del servidor. Todo lo que ocurre después de que la respuesta sale — el JavaScript que tu página y sus decenas de proveedores externos ejecutan en el navegador del visitante — es invisible para él. Una etiqueta de analítica comprometida que hace skimming en un formulario de pago nunca toca el runtime instrumentado; desde la perspectiva del servidor, no ocurrió nada anormal.
Esa brecha del lado del cliente tiene sus propias clases de ataque — inyección de JavaScript, XSS basado en DOM, Magecart — y, para las páginas de pago, su propia respuesta regulatoria en los requisitos de inventario de scripts y detección de manipulación de PCI DSS 4.0.1 (6.4.3 y 11.6.1).
El equivalente en la capa del navegador
La idea detrás de RASP — vigilar el runtime, no el perímetro — se aplica igualmente al navegador, donde el "runtime" es cada script que se ejecuta en una sesión real. Eso es lo que hace el monitoreo client-side de cside: observa lo que cada script hace realmente mientras se ejecuta — acceso al DOM, lectura de formularios, peticiones salientes — y señala el comportamiento que no debería estar ahí. cside no es un RASP; es la misma filosofía de protección aplicada a la mitad de la aplicación que RASP no puede ver. La mayoría de los stacks maduros terminan con un WAF en el perímetro, RASP o controles equivalentes en el runtime del servidor y monitoreo en runtime en el navegador — una seguridad client-side en capas en lugar de una sola caja.
