10 siglas de segurança de aplicações que você precisa conhecer
Entenda as siglas mais comuns de AppSec
Escrito por
0 minutos de leitura
Guia rápido
Explicação das 10 principais siglas de segurança de aplicações
Imagine a seguinte situação: você é uma pessoa desenvolvedora em uma reunião na qual alguém da área de segurança está apresentando os resultados de um teste de invasão recente ou de uma análise estática do código que você escreveu.
Durante a conversa, essa pessoa usa várias siglas de segurança de aplicações como se você já soubesse o que elas significam, mas, na realidade, são termos que você não conhece. Isso soa familiar? Infelizmente, essa situação parece ser comum em muitas organizações de DevSecOps. Na verdade, nós da Snyk também 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, pensamos em reunir as 10 siglas de segurança mais comuns em um guia rápido — e não se preocupe: incluímos SAST na lista. Continue lendo para saber mais.
1. SAST — Teste estático de segurança de aplicações
Teste estático de segurança de aplicações, ou SAST, é a prática de 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 buscam no código-fonte padrões de programação, funções ou objetos inseguros que possam levar a vulnerabilidades. O SAST é usado principalmente para identificar vulnerabilidades em código recém-desenvolvido. Em geral, ele é executado durante a etapa de programação ou quando o código é promovido para um ambiente de teste.
Uma das principais vantagens do SAST é identificar vulnerabilidades no início do processo de desenvolvimento e encontrar problemas ocultos que talvez passassem despercebidos ao analisar apenas as funcionalidades da aplicação. As ferramentas automatizadas de SAST conseguem analisar grandes volumes de código rapidamente. No entanto, por isso mesmo, também podem gerar muitos resultados, que frequentemente incluem falsos positivos ou vulnerabilidades que, no contexto da aplicação, não representam um risco real. Algumas ferramentas exigem bastante tempo de configuração para ajustar os resultados e eliminar esses problemas. Ainda assim, elas são essenciais para a sua postura de segurança.
Comece a jogar Capture the Flag
Aprenda a resolver desafios de Capture the Flag assistindo à gravação sob demanda do nosso workshop virtual introdutório.
2. DAST — Teste dinâmico de segurança de aplicações
O teste dinâmico de segurança de aplicações, ou DAST, é a prática de analisar uma aplicação ou serviço em execução em busca de 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 aplicação. Uma vantagem dessa abordagem é que ela pode identificar vulnerabilidades complexas decorrentes de funcionalidades específicas da aplicação, que talvez não fossem encontradas apenas pela análise do código-fonte.
No DAST, a interface é analisada em busca de vários indícios de vulnerabilidade, observando como a aplicação responde a diferentes solicitações e entradas (geralmente chamadas de payloads). Tudo é examinado, desde os campos de entrada de dados até os cabeçalhos HTTP, para verificar se foram implementados os controles adequados de tratamento de dados e as medidas de segurança necessárias para impedir que invasores manipulem a aplicação ou o serviço.
O DAST pode ser realizado com ferramentas automatizadas, semiautomatizadas ou manuais. Em geral, as ferramentas totalmente automatizadas de DAST conseguem mapear as diferentes páginas de uma aplicação e testá-las em busca de uma grande variedade de possíveis vulnerabilidades de segurança, usando variações de payloads. Muitas delas também testam serviços web e microsserviços. Outras ferramentas de DAST têm um foco mais específico e analisam com mais profundidade um ou alguns tipos de vulnerabilidade. Normalmente, o DAST é realizado nas etapas finais de teste, 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, leia nosso artigo SAST vs. DAST.
3. SCA — Análise de composição de software
A análise de composição de software, ou SCA, consiste em analisar uma aplicação para identificar componentes de software de terceiros ou de código aberto que fazem parte dela. Em geral, a SCA analisa essas dependências externas em busca de vulnerabilidades de segurança conhecidas e possíveis problemas de licenciamento. Ferramentas automatizadas de SCA, como o Snyk Open Source, normalmente conseguem mapear toda a árvore de dependências: não apenas identificam as inclusões no código-fonte da aplicação, mas também analisam as dependências de cada uma dessas dependências, e assim por diante.
A análise de composição de software pode ser executada em qualquer etapa do pipeline de entrega, mas geralmente é melhor fazê-la o quanto antes, muitas vezes durante a programação, para que qualquer problema encontrado 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.
Saiba mais sobre SAST vs. SCA e como usar essas abordagens para lançar software seguro.
Comece a resolver desafios de capture the flag
Aprenda a resolver desafios de capture the flag assistindo sob demanda ao nosso workshop virtual introdutório.
4. OWASP — Projeto Aberto de Segurança de Aplicações Web
O Projeto Aberto de Segurança de Aplicações Web, ou OWASP, é uma organização sem fins lucrativos dedicada à segurança de software. A OWASP é conhecida por seus diversos projetos conduzidos pela comunidade, que buscam oferecer educação e orientação para a criação 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 vulnerabilidades em aplicações web, atualizada periodicamente com contribuições da comunidade. Ao realizar SAST ou DAST, você pode ouvir falar do OWASP Top 10 como uma referência para os tipos de vulnerabilidade que as pessoas responsáveis pelos testes procuram. Embora não seja uma categorização abrangente 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 compartilhar ideias, trabalhar em projetos e disseminar conhecimento. De tempos em tempos, projetos específicos também podem organizar encontros para reunir profissionais e participantes dos projetos, discutir e aprimorar diferentes aspectos.
5. XSS — Script entre sites
Script entre sites, ou XSS, é um tipo de vulnerabilidade de segurança comum em aplicações web. Ela faz parte do OWASP Top 10 desde a primeira versão, lançada em 2003. O XSS é um tipo de ataque a aplicações que pode permitir que uma pessoa invasora execute código de script malicioso (geralmente JavaScript) no navegador de uma ou várias pessoas usuárias. Esse tipo de exploração pode ser usado para coletar informações confidenciais, como dados de sessão ou informações pessoais.
Há três tipos de XSS geralmente discutidos:
Refletido: a pessoa invasora 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 ele seja executado no navegador.
Armazenado: a pessoa invasora envia o payload do ataque à aplicação, que o armazena em um valor posteriormente exibido a outras pessoas como parte de páginas criadas dinamicamente. Assim, o script é executado nos navegadores delas.
Baseado em DOM: a pessoa invasora envia o script malicioso à pessoa usuária (geralmente em um link malicioso), e ele é executado diretamente no DOM da página, sem passar pela aplicação.
Encontre mais informações sobre XSS e como se proteger na página de XSS do Snyk Learn.
6. CSRF — Falsificação de solicitação entre sites
Falsificação de solicitação entre sites, ou CSRF, é outro tipo comum de ataque a aplicações web. Em um ataque CSRF, a pessoa invasora 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 inseridas em um site malicioso sob seu controle. O CSRF também é chamado, às vezes, de sequestro de sessão, e algumas pessoas preferem pronunciar a sigla como “C-Surf”.
A falsificação de solicitação entre sites costuma ser explorada ao se capturar uma solicitação válida feita à aplicação-alvo e fazer com que ela seja reenviada pelo navegador da vítima enquanto a sessão autenticada com a aplicação continua ativa. Por exemplo, a pessoa invasora pode capturar uma solicitação de um serviço de banco on-line que realiza uma transferência bancária. Em seguida, cria um site malicioso e insere essa mesma solicitação em um IFRAME, para que qualquer pessoa que acesse o site a envie ao serviço bancário. Assim, se a pessoa visitante tiver uma sessão ativa com esse serviço (talvez em outra aba do navegador), a solicitação será enviada usando essa sessão. Para atrair visitantes ao site, a pessoa invasora provavelmente usará uma campanha direcionada de phishing para tentar convencer clientes do banco — e, portanto, prováveis usuários do serviço bancário — a acessar o site malicioso.
Para saber mais sobre falsificação de solicitação entre sites e como se proteger, acesse a página de CSRF no 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 defensiva integrada a uma aplicação que permite detectar ataques e reagir a eles imediatamente. Em geral, o RASP é implementado com ferramentas de terceiros, que costumam ser incorporadas à aplicação para monitorar não apenas as solicitações recebidas, mas também o comportamento da aplicação, identificando e impedindo 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 as 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 invasora não consiga explorá-las com sucesso — ou, pelo menos, limitar significativamente o alcance da exploração.
8. DoS — Negação de serviço
Negação de serviço, ou DoS, é um tipo de exploração em que a pessoa invasora tenta limitar ou impedir a disponibilidade de uma aplicação ou serviço. Isso costuma ser feito fazendo com que a aplicação, o serviço ou o sistema pare de responder ou fique extremamente lento. Também é possível atacar a infraestrutura de rede que permite a comunicação com a aplicação. Os ataques de DoS acontecem quando a pessoa invasora explora uma falha no código, no software do sistema ou na infraestrutura de rede de uma aplicação para torná-la indisponível para outras pessoas. Há várias maneiras de realizar um ataque de DoS, mas dois tipos específicos são frequentemente mencionados:
DDoS: ataque distribuído de negação de serviço, em que a pessoa invasora 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: Regular Expression Denial of Service é uma falha específica, comum em aplicações JavaScript executadas no servidor, que permite a um invasor fazer o mecanismo de expressões regulares consumir muitos recursos e deixar a aplicação sem resposta.
9. CSP — Política de Segurança de Conteúdo
A Política de Segurança de Conteúdo, ou CSP, é uma medida de proteção para aplicações web projetada para prevenir ataques XSS. Ela permite que os 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, os desenvolvedores podem evitar que scripts inseridos por meio de um ataque XSS sejam executados ao chegar ao navegador.
Confira mais recursos e informações sobre CSP no nosso blog.
10. SSRF — Falsificação de Solicitação do Lado do Servidor
Falsificação de Solicitação do Lado do Servidor, ou SSRF, é um tipo de ataque a aplicações no qual um invasor pode fazer a aplicação de front-end enviar solicitações para locais arbitrários (como outros servidores internos, servidores externos ou até para ela mesma). Isso pode permitir que o invasor acesse dados ou funções sem autorização.
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 os desenvolvedores, entender os termos usados por suas equipes de segurança pode ser uma ferramenta poderosa para fortalecer a colaboração no pipeline de entrega DevSecOps.