Guia rápido: as 10 principais siglas de segurança de aplicações
1 de dezembro de 2020
0 minutos de leituraImagine a seguinte situação: você é uma pessoa desenvolvedora em uma reunião, e alguém da equipe de segurança está discutindo os resultados de um teste de invasão recente ou de uma análise estática do código que você escreveu.
Durante a discussão, essa pessoa usa várias siglas e presume que você sabe o que significam, mas, na verdade, são termos com os quais você não está familiarizado. Isso parece familiar? Infelizmente, essa situação é comum em muitas organizações de DevSecOps. Na verdade, nós da Snyk caímos nessa armadilha ao anunciar recentemente os recursos de SAST da Snyk. Recebemos muitos comentários nas redes sociais de pessoas que não sabiam o que era SAST. Por isso, achamos que seria uma boa ideia preparar um guia rápido com as 10 siglas de segurança mais comuns — e não se preocupe: incluímos SAST na lista. Continue lendo para descobrir do que se trata.
DAST — teste dinâmico de segurança de aplicações
SCA — análise de composição de software
OWASP — Projeto Aberto de Segurança em Aplicações Web
XSS — cross-site scripting
CSRF — falsificação de solicitação entre sites
RASP — autoproteção de aplicações em tempo de execução
DoS — negação de serviço
CSP — política de segurança de conteúdo
SSRF — falsificação de solicitação do lado do servidor
1. SAST — teste estático de segurança de aplicações
O teste estático de segurança de aplicações, ou SAST, consiste em analisar o código-fonte de uma aplicação, serviço, microsserviço etc. para identificar possíveis vulnerabilidades de segurança decorrentes de práticas de programação inseguras. O SAST costuma ser implementado com ferramentas automatizadas que examinam o código-fonte em busca de padrões de programação, funções ou objetos inseguros que possam levar a vulnerabilidades de segurança. É usado principalmente para identificar vulnerabilidades em código recém-desenvolvido. Em geral, é executado durante a etapa de programação ou quando o código é promovido para um ambiente de testes.
Uma das principais vantagens do SAST é identificar vulnerabilidades no início do processo de desenvolvimento e encontrar falhas ocultas que poderiam passar despercebidas ao analisar apenas as funcionalidades da aplicação. As ferramentas automatizadas de SAST conseguem analisar grandes volumes de código rapidamente. No entanto, também podem gerar muitos resultados, muitas vezes com falsos positivos ou vulnerabilidades que, no contexto da aplicação, não representam um risco real. Com algumas ferramentas, pode levar bastante tempo ajustar as configurações e eliminar esses problemas. Ainda assim, essas ferramentas são essenciais para a sua postura de segurança.
2. DAST — teste dinâmico de segurança de aplicações
O teste dinâmico de segurança de aplicações, ou DAST, consiste em analisar uma aplicação ou serviço em execução para identificar vulnerabilidades de segurança. O DAST busca simular os tipos de ataque que uma pessoa mal-intencionada poderia realizar contra a aplicação por meio da interface do usuário ou da própria aplicação. A vantagem dessa abordagem é identificar vulnerabilidades complexas, decorrentes de funcionalidades específicas da aplicação, que poderiam passar despercebidas em uma análise apenas do código-fonte.
No DAST, a interface é analisada em busca de diferentes indicadores de vulnerabilidade, observando como a aplicação responde a várias solicitações e entradas (geralmente chamadas de payloads). Tudo é analisado, desde os campos de entrada de dados até os cabeçalhos HTTP, para determinar se foram implementados controles adequados de tratamento de dados e medidas de segurança para impedir que atacantes manipulem a aplicação ou o serviço.
Para realizar DAST, é possível usar ferramentas automatizadas, semiautomatizadas e manuais. As ferramentas de DAST totalmente automatizadas geralmente conseguem mapear as diferentes páginas de uma aplicação e testá-las em busca de uma ampla variedade de possíveis vulnerabilidades de segurança, usando variações de payloads. Muitas também conseguem testar serviços web e microsserviços. Outras ferramentas usadas em DAST são mais especializadas e analisam com mais profundidade um ou alguns tipos específicos de vulnerabilidade. Em geral, o DAST é realizado nas etapas finais de testes, pouco antes da implantação da aplicação ou do serviço em um ambiente de produção.
Para saber mais sobre as diferenças entre SAST e DAST, acesse nossa página SAST vs. DAST no Snyk Learn.
3. SCA — análise de composição de software
Análise de composição de software, ou SCA, é a análise de uma aplicação para identificar componentes de software de terceiros ou de código aberto incluídos nela. Em geral, a SCA analisa essas dependências externas em busca de vulnerabilidades de segurança conhecidas e possíveis problemas de licença. Ferramentas automatizadas de SCA, como o Snyk Open Source, geralmente conseguem mapear toda a árvore de dependências. Elas não verificam apenas os componentes incluídos no código-fonte da aplicação, mas também analisam as dependências de cada um deles, e assim por diante.
A análise de composição de software pode ser executada em qualquer etapa do pipeline de entrega, mas é recomendável fazê-la mais cedo, muitas vezes durante a programação, para que qualquer problema identificado possa ser resolvido rapidamente. Um dos principais motivos para usar SCA é identificar possíveis falhas de segurança introduzidas por componentes de terceiros durante o desenvolvimento de uma aplicação. Além disso, quando novas vulnerabilidades são identificadas em softwares de terceiros ou de código aberto, a organização pode avaliar rapidamente se foi afetada e planejar a correção.
4. OWASP — Projeto Aberto de Segurança em Aplicações Web
O Open Web Application Security Project, ou OWASP, é uma organização sem fins lucrativos dedicada à segurança de software. A OWASP é conhecida por seus diversos projetos colaborativos, que têm como objetivo oferecer educação e orientação para o desenvolvimento de softwares mais seguros. A organização reúne uma grande comunidade de pessoas voluntárias que propõem, desenvolvem e gerenciam esses projetos e materiais educativos em benefício de toda a comunidade de segurança e desenvolvimento de software.
Um dos projetos mais conhecidos é o OWASP Top 10, uma lista dos dez tipos mais comuns de vulnerabilidade em aplicações web, atualizada periodicamente com contribuições da comunidade. Ao realizar SAST ou DAST, você pode ouvir alguém mencionar o OWASP Top 10 como referência para os tipos de vulnerabilidade que a equipe de testes pode procurar. Embora não seja uma classificação completa de todos os tipos possíveis de vulnerabilidade, é um bom ponto de partida.
A OWASP também organiza várias conferências de segurança pelo mundo e tem capítulos locais que se reúnem regularmente para trocar ideias, trabalhar em projetos e compartilhar conhecimento. De tempos em tempos, projetos específicos também podem organizar encontros para reunir profissionais e participantes dos projetos para discutir e aprimorar diferentes aspectos do trabalho.
5. XSS — cross-site scripting
Cross-site scripting, ou XSS, é um tipo de vulnerabilidade de segurança comum em aplicações web. Está na lista OWASP Top 10 desde a primeira edição, publicada em 2003. O XSS é uma forma de ataque a aplicações que pode permitir que uma pessoa atacante execute código de script malicioso (geralmente JavaScript) no navegador de uma pessoa usuária ou de várias. Esse tipo de exploração pode ser usado para obter informações confidenciais, como dados de sessão ou informações pessoais.
Há três tipos de XSS que costumam ser mencionados:
Refletido: a pessoa atacante faz com que a pessoa usuária envie à aplicação uma solicitação que contém o payload do ataque. A aplicação o inclui na resposta, fazendo com que seja executado no navegador.
Armazenado: a pessoa atacante envia o payload do ataque à aplicação, que o armazena em um valor retornado a outras pessoas como parte de páginas geradas dinamicamente. Com isso, o script é executado nos navegadores dessas pessoas.
Baseado em DOM: a pessoa atacante envia o script malicioso à pessoa usuária (geralmente por meio de um link malicioso), e ele é executado diretamente no DOM da página, sem passar pela aplicação.
Saiba mais sobre XSS e como evitá-lo na página XSS do Snyk Learn.
6. CSRF — falsificação de solicitação entre sites
Falsificação de solicitação entre sites, ou CSRF, é outra forma comum de ataque a aplicações web. Em um ataque CSRF, a pessoa atacante aproveita uma sessão já autenticada entre o navegador da pessoa usuária e a aplicação para executar funcionalidades da aplicação por meio de solicitações incorporadas a um site malicioso sob seu controle. O CSRF também é chamado de sequestro de sessão, e algumas pessoas preferem pronunciá-lo como “C-Surf”.
A falsificação de solicitação entre sites costuma ser explorada por meio de uma solicitação válida à aplicação-alvo, que é reproduzida no navegador da vítima enquanto ela mantém uma sessão autenticada ativa com a aplicação. Por exemplo, a pessoa atacante pode capturar uma solicitação de uma aplicação de banco online que realiza uma transferência bancária. Em seguida, cria um site malicioso e hospeda essa mesma solicitação em um IFRAME, para que qualquer pessoa que visite o site a envie à aplicação bancária. Assim, se a pessoa visitante tiver uma sessão ativa com essa aplicação bancária (talvez em outra aba do navegador), a solicitação será enviada usando essa sessão. Para atrair visitantes ao site, a pessoa atacante provavelmente usará uma campanha de phishing direcionada para tentar enganar clientes do banco — e, portanto, possíveis usuários da aplicação bancária — e fazê-los visitar o site malicioso.
Para saber mais sobre falsificação de solicitação entre sites e como evitá-la, consulte a página CSRF do Snyk Learn.
7. RASP — autoproteção de aplicações em tempo de execução
Autoproteção de aplicações em tempo de execução, ou RASP, é uma técnica de defesa integrada à aplicação que permite detectar ataques e reagir a eles imediatamente. Em geral, o RASP é implementado com ferramentas de terceiros. Essas ferramentas costumam se integrar à aplicação e monitorar não apenas as solicitações recebidas, mas também o comportamento da aplicação para identificar e impedir ataques. Isso pode ser feito por meio de pacotes, bibliotecas ou plug-ins que funcionam quase como um filtro na entrada da aplicação, inspecionando solicitações e o comportamento da aplicação. O principal benefício do RASP é garantir que, mesmo que existam vulnerabilidades na aplicação, uma pessoa atacante não consiga explorá-las com sucesso — ou, pelo menos, limitar bastante os danos da exploração.
8. DoS — negação de serviço
Negação de serviço, ou DoS, é um tipo de ataque em que a pessoa atacante tenta limitar ou impedir a disponibilidade de uma aplicação ou serviço. Isso costuma ser feito deixando a aplicação, o serviço ou o sistema sem resposta ou extremamente lento. Também é possível atacar a infraestrutura de rede que permite a comunicação com a aplicação. Ataques DoS ocorrem quando uma pessoa atacante explora uma falha no código, no software do sistema ou na infraestrutura de rede de uma aplicação para torná-la indisponível. Há muitas maneiras de realizar um ataque DoS, mas dois tipos específicos são frequentemente mencionados:
DDoS: negação de serviço distribuída. A pessoa atacante usa um grande número de sistemas (geralmente parte de uma botnet) para sobrecarregar um alvo com tráfego e torná-lo indisponível.
REDoS: negação de serviço por expressão regular. É uma falha específica, comum em aplicações JavaScript do lado do servidor, que permite que uma pessoa atacante faça o mecanismo de expressões regulares consumir muitos recursos e deixe a aplicação sem resposta.
9. CSP — política de segurança de conteúdo
A Content Security Policy, ou CSP, é uma medida de proteção para aplicações web criada para impedir ataques XSS. Ela permite que desenvolvedores de aplicações usem um cabeçalho HTTP para instruir o navegador a carregar e executar scripts somente de fontes específicas. Ao impedir que scripts sejam carregados de fontes não autorizadas, o desenvolvedor pode evitar que um script fornecido por meio de um ataque XSS seja executado ao chegar ao navegador.
Confira mais recursos e informações sobre CSP no nosso blog.
10. SSRF — falsificação de solicitações do lado do servidor
Falsificação de solicitações do lado do servidor, ou SSRF, é um tipo de ataque a aplicações em que o invasor consegue fazer com que a aplicação front-end envie solicitações para locais arbitrários (como outros servidores internos, servidores externos ou até para ela mesma). Isso pode dar ao invasor acesso a dados ou funções não autorizados.
Para saber mais sobre SSRF, recomendamos este guia da OWASP.
Em resumo
Como em qualquer setor, a segurança tem muitos termos técnicos, que costumam ser abreviados em siglas para facilitar a comunicação. Isso pode gerar confusão para quem não trabalha com segurança. Para desenvolvedores, entender os termos usados por suas equipes de segurança pode ser uma ferramenta poderosa para promover uma colaboração melhor no fluxo de entrega DevSecOps.
Baixe agora o guia das 10 principais siglas de segurança de aplicações!
