Introdução
A segurança dos usuários e seus dados pessoais ao usar um aplicativo da web é primordial. Embora esse princípio orientador tenha sido reconhecido desde os estágios iniciais do desenvolvimento da Web, os agentes mal-intencionados encontram brechas nos aplicativos e podem explorar seus usuários.
Muitos ataques “padrão” são bem conhecidos e documentados, e a proteção contra eles não é difícil. Para aliviar o desenvolvedor da implementação de práticas de segurança, frameworks como Spring Boot abstraíram várias medidas de segurança e permitem que você simplesmente aplique filtros de segurança em seus aplicativos para evitar ataques conhecidos.
Neste pequeno guia, veremos o que é Cross-Site Scripting (XSS), como alguém pode executar esse ataque em seu próprio aplicativo e como você pode evitá-lo facilmente com o Spring Boot.
O que é Cross-Site Scripting (XSS)?
Cross-Site Scripting é uma exploração bem conhecida e amplamente difundida, na qual um agente mal-intencionado injeta um script em um aplicativo da web.
Normalmente, uma política de mesma origem é aplicada a aplicativos da Web, o que restringe scripts em uma página da Web para acessar dados de origens se suas origens não corresponderem. Sob a política de mesma origem – se uma página de um site confiável pode acessar dados de interface com o usuário (como cookies, por exemplo), outras páginas da mesma origem também podem fazê-lo. Essa forma de controle de acesso parecia suficiente para proteger a integridade dos dados nas aplicações web na época.
Cross-Site Scripting burla a política de mesma origem, injetando um script malicioso na página de um site confiável. Como o script é executado em um site confiável, ele é executado como um script confiável. Não havia uma maneira clara de diferenciar entre scripts maliciosos e scripts não maliciosos – portanto, a execução arbitrária de código era possível com o Cross-Site Scripting. Isso varia desde a inserção de alertas irritantes até ataques de engenharia social, coleta silenciosa de informações do usuário ou redirecionamento de usuários para páginas de phishing que parecem fazer parte de sites confiáveis.
Muitos sites são suscetíveis a ataques Cross-Site Scripting, e continua sendo um ataque comum hoje em dia, embora esse tipo de exploração seja conhecido desde os anos 90.
Prevenindo XSS em um aplicativo Spring Boot com política de segurança de conteúdo (CSP)
O Spring Boot leva a segurança a sério, e o módulo de segurança do Spring implementa práticas de segurança flexíveis e poderosas que permitem que os desenvolvedores minimizem suas preocupações quando se trata de segurança, o que muitas vezes requer uma compreensão de baixo nível dos princípios de como as mensagens estão sendo trocadas em uma web inscrição.
Por padrão, o Spring Boot implementa vários cabeçalhos de segurança:
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
A proteção X-XSS está incluída por padrão! Este cabeçalho de segurança tenta descobrir Tentativas de XSS e as bloqueia. No entanto, este não é um processo à prova de falhas, e os navegadores têm diferentes implementações de detectores. Alguns navegadores, como o Chrome, têm até removeu seu XSS Auditor. Além disso, a detecção automatizada funciona para Ataques XSS refletidos, enquanto outros tipos de ataques também existem.
Uma alternativa mais moderna ao X-XSS-Protection é o Política de segurança de conteúdo (CSP), que lidam principalmente com políticas sobre quais recursos podem ser carregados, de quais origens e em quais terminais. A partir de 2022, o CSP é a melhor medida de prevenção contra XSS, Clickjacking e outros tipos de ataques. Nem todos os navegadores implementam o CSP, e é por isso que ele não é incluído nos cabeçalhos de segurança por padrão.
Observação: Mesmo com o CSP implementado, é sempre o melhor curso de ação validar qualquer entrada do usuário e certifique-se de que é seguro processar usando seu sistema, para evitar a injeção de código.
No Spring Boot – para configurar medidas de segurança da Web personalizadas, você normalmente estenderá o WebSecurityConfigurerAdapter classe e substituir o configure() método:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("csp-directives");
}
}
Quando as diretivas de política de segurança de conteúdo (fornecidas como ;-separated string) dependem do seu caso de uso e em quais fontes você deseja confiar:
Content-Security Policy: directive1; directive2; directive3; ... directiveN;
Por exemplo, um aplicativo da web pode listar sites confiáveis dos quais os scripts podem ser carregados com:
script-src https://trusted.com;
Ou você pode pular a confiança em qualquer site de terceiros:
script-src self;
Da mesma forma, um aplicativo pode confiar em plugins:
object-src https://trusted.com
Há uma grande variedade de diretivas que você pode fornecer, incluindo:
default-src– Retorno padrãochild-src– Fontes válidas de web workersframe-src– Fontes válidas paraareiasimg-src– Fontes válidas para imagensmedia-src– Fontes válidas para,eTagscript-src– Fontes de script válidas (ajuda a evitar XSS)style-src– Fontes válidas paraelementosbase-uri– Restringe recursos acessíveis a partir doelementoframe-ancestors– Pais válidos de,,, etc. elementos- etc.
Confira nosso guia prático e prático para aprender Git, com práticas recomendadas, padrões aceitos pelo setor e folha de dicas incluída. Pare de pesquisar comandos Git no Google e realmente aprender -lo!
Por exemplo, aqui está um conjunto seguro de diretivas de política:
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
report-uri https://csp.example.com;
Vamos adicioná-los ao nosso aplicativo Spring Boot:
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.headers()
.contentSecurityPolicy("script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; report-uri https://csp.example.com;");
}
}
Você pode usar o CSP-Avaliador para avaliar se suas diretivas CSP são válidas e safe, e indicará quais diretivas são facilmente exploráveis. Aqui está uma diretiva CSP que permite APIs do Google:
default-src 'self';
object-src 'none';
frame-src 'self' data:;
script-src 'self' 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' https://storage.googleapis.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self' data:;
base-uri 'self'
Conclusão
Neste pequeno guia, demos uma olhada no que é Cross-Site Scripting (XSS) e como ele funciona em um nível holístico. Em seguida, exploramos algumas medidas de prevenção de XSS que podem ser facilmente implementadas com Spring Boot para tornar seus aplicativos seguros e definir um Política de segurança de conteúdo (CSP).
Por fim, exploramos as diretivas CSP e analisamos algumas políticas seguras diferentes.
