RASP, Runtime Application Self-Protection, é uma tecnologia de segurança que roda dentro de uma aplicação e a protege a partir de dentro. Ao instrumentar o runtime da aplicação, o RASP observa como a entrada é de fato usada e pode detectar e bloquear ataques no momento da exploração, com um contexto que uma defesa de perímetro nunca vê.
Resumo: proteção em tempo de execução de dentro da aplicação
- O que é: Uma tecnologia que roda dentro do runtime de uma aplicação e bloqueia ataques no momento da exploração, usando o contexto de execução do próprio código.
- RASP versus WAF: Um WAF filtra o tráfego no perímetro por padrões; o RASP observa o que o código realmente faz, o que reduz a maior parte do compromisso entre falsos positivos e falsos negativos.
- Onde ele para: O RASP instrumenta apenas o runtime do servidor, então os ataques do navegador (Magecart, formjacking, DOM XSS) ficam totalmente fora do seu alcance.
Sem tempo? Veja o monitoramento do lado do cliente da cside. Ele aplica ao navegador a ideia do RASP de vigiar o runtime, a metade da aplicação que o RASP não consegue ver.
Como o RASP funciona?
O RASP se acopla ao runtime da aplicação (um agente JVM, um profiler .NET, um hook de instrumentação do Node) e intercepta operações relevantes para a segurança: queries de banco de dados, acesso a arquivos, execução de comandos, desserialização. Quando os dados de uma requisição chegam a uma dessas operações de um jeito que corresponde a uma exploração (um parâmetro que reescreve a estrutura do SQL, um caminho que escapa do seu diretório), o RASP pode registrar, alertar ou bloquear a operação dentro do processo.
A propriedade definidora é o contexto. Um filtro de perímetro adivinha a malícia pela forma da requisição; o RASP observa o que o código realmente faz com ela, o que elimina a maior parte do dilema entre falsos positivos e falsos negativos.
RASP vs WAF vs monitoramento client-side
| WAF | RASP | Monitoramento na camada do navegador | |
|---|---|---|---|
| Onde roda | Na frente do app | Dentro do runtime do servidor | Na sessão do navegador do visitante |
| Vê | Requisições e respostas | A execução real do código | Scripts em execução na página |
| Ponto cego | Como a entrada é usada | Tudo no lado do cliente | Os internos do servidor |
| Impede | Padrões de ataque conhecidos | Exploits que chegam ao runtime | Skimming, scripts injetados, exfiltração de dados |
| Implantação | Em nível de rede | Agente por linguagem/runtime | Tag de script |
Onde o RASP termina
O limite do RASP é o processo do servidor. Tudo o que acontece depois que a resposta sai (o JavaScript que a sua página e as dezenas de fornecedores terceiros dela executam no navegador do visitante) é invisível para ele. Uma tag de analytics comprometida fazendo skimming em um formulário de checkout nunca toca o runtime instrumentado; do ponto de vista do servidor, nada de anormal aconteceu.
Essa lacuna no lado do cliente tem suas próprias classes de ataque (injeção de JavaScript, XSS baseado em DOM, Magecart) e, para páginas de pagamento, sua própria resposta regulatória nos requisitos de inventário de scripts e detecção de adulteração do PCI DSS 4.0.1 (6.4.3 e 11.6.1).
O equivalente na camada do navegador
A ideia por trás do RASP (observar o runtime, não o perímetro) se aplica igualmente ao navegador, onde o "runtime" é cada script executado em uma sessão real. É isso que o monitoramento client-side da cside faz: ele observa o que cada script realmente faz enquanto roda (acesso ao DOM, leitura de formulários, requisições de saída) e sinaliza comportamentos que não deveriam estar ali. A cside não é um RASP; é a mesma filosofia de proteção aplicada à metade da aplicação que o RASP não consegue ver. A maioria dos stacks maduros acaba com um WAF no perímetro, RASP ou controles equivalentes no runtime do servidor e monitoramento em runtime no navegador, uma segurança client-side em camadas em vez de uma única caixa.
