A segurança de navegadores e aplicações web é fundamental para proteger dados e usuários na internet. Nesta aula, exploraremos os principais mecanismos de segurança implementados pelos navegadores, como a Same-Origin Policy e o Content Security Policy (CSP), além de entender como os cookies funcionam e como vulnerabilidades como XSS e CSRF podem ser exploradas e mitigadas.

Compreender esses conceitos é essencial para desenvolvedores web que desejam construir aplicações robustas e seguras, evitando ataques comuns que podem comprometer a integridade, confidencialidade e disponibilidade dos sistemas.

Same-origin policy

A Same-Origin Policy (Política de Mesma Origem) é um mecanismo de segurança fundamental implementado pelos navegadores. Ela restringe como um documento ou script carregado de uma origem pode interagir com recursos de outra origem. Uma origem é definida pela combinação de protocolo, domínio e porta. Por exemplo, https://exemplo.com:443 é uma origem diferente de http://exemplo.com:80 ou https://outro.com.

Essa política impede que scripts maliciosos de um site acessem dados sensíveis de outro site, como cookies, localStorage ou respostas de requisições. Sem ela, um site malicioso poderia, por exemplo, ler seus e-mails em outro serviço. A política se aplica a várias operações, como requisições AJAX, acesso a frames e manipulação do DOM entre origens diferentes.

Existem exceções controladas, como o Cross-Origin Resource Sharing (CORS), que permite que servidores especifiquem quais origens podem acessar seus recursos por meio de cabeçalhos HTTP como Access-Control-Allow-Origin.

CSP

Content Security Policy (CSP) é uma camada adicional de segurança que ajuda a detectar e mitigar ataques como Cross-Site Scripting (XSS) e injeção de dados. Ela permite que desenvolvedores controlem quais recursos podem ser carregados e executados em uma página web, através de um cabeçalho HTTP Content-Security-Policy ou de uma meta tag <meta http-equiv="Content-Security-Policy">.

Com CSP, é possível especificar origens permitidas para scripts, estilos, imagens, fontes, entre outros. Por exemplo, uma política pode permitir apenas scripts do próprio domínio e de CDNs confiáveis, bloqueando scripts inline ou eval(). Isso reduz drasticamente a superfície de ataque de XSS.

Exemplo de cabeçalho CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' 'unsafe-inline'; img-src *

Neste exemplo, scripts só podem ser carregados da mesma origem e de https://apis.google.com, estilos podem ser inline, e imagens de qualquer origem. É importante testar políticas rigorosas para não quebrar funcionalidades legítimas.

Cookies

Cookies são pequenos arquivos de texto armazenados no navegador do usuário, utilizados para manter estado entre requisições HTTP. Eles são amplamente usados para sessões de login, preferências e rastreamento. Cada cookie possui atributos que controlam seu comportamento e segurança.

Os principais atributos de segurança são: Secure (envia apenas por HTTPS), HttpOnly (inacessível via JavaScript, prevenindo XSS), SameSite (controla envio em requisições cross-site) e Domain/Path (escopo). O atributo SameSite pode ser Strict, Lax ou None. Strict impede envio em requisições de outros sites, Lax permite envio em navegação top-level (como clicar em um link), e None permite envio em qualquer requisição, mas exige Secure.

Exemplo de configuração de cookie seguro:

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600

Boas práticas incluem sempre usar HttpOnly e Secure em cookies de sessão, e utilizar SameSite=Lax ou Strict para mitigar CSRF.

XSS e CSRF

XSS (Cross-Site Scripting) é uma vulnerabilidade que permite a um atacante injetar scripts maliciosos em páginas web visualizadas por outros usuários. Existem três tipos principais: Reflected (refletido), Stored (armazenado) e DOM-based. O ataque ocorre quando a aplicação não valida ou sanitiza adequadamente entradas do usuário, permitindo que código JavaScript seja executado no contexto de outro usuário.

Para mitigar XSS, as principais práticas são: escapar saídas (usar encoding HTML, URL, JavaScript), validar entradas (whitelist), usar CSP para restringir fontes de script, e evitar funções perigosas como innerHTML e eval(). Frameworks modernos geralmente oferecem proteção automática, mas é importante entender os mecanismos.

CSRF (Cross-Site Request Forgery) é um ataque que força um usuário autenticado a executar ações indesejadas em uma aplicação web onde está logado. Por exemplo, um atacante pode enganar o usuário para clicar em um link que transfere dinheiro ou altera a senha. A requisição maliciosa é enviada com os cookies do usuário, que são automaticamente incluídos pelo navegador.

As principais defesas contra CSRF incluem: uso de tokens CSRF (enviados como campo oculto em formulários ou cabeçalho personalizado), cookies com SameSite=Strict ou Lax, validação de cabeçalho Origin ou Referer, e reautenticação para ações sensíveis.

Boas práticas e observações finais

Para construir aplicações web seguras, é essencial adotar uma abordagem de defesa em profundidade. Combine CSP, cookies seguros, validação e sanitização de entradas, uso de tokens CSRF e práticas modernas de desenvolvimento. Mantenha-se atualizado sobre novas vulnerabilidades e atualizações de segurança dos navegadores. Lembre-se de que a segurança é um processo contínuo, não um estado final.

Referências

Exercícios

  1. Explique o que é a Same-Origin Policy e como ela protege o usuário. Dê um exemplo de situação em que a política seria violada.

    ✓ Resposta: A Same-Origin Policy (SOP) é uma regra de segurança do navegador que impede que um script de uma origem acesse dados de outra origem. Por exemplo, um script em https://site-malicioso.com não pode ler o conteúdo de https://banco.com por meio de requisições AJAX. Uma violação ocorreria se o navegador permitisse que um site acessasse cookies de outro site sem restrições.

  2. Considere a seguinte política CSP: default-src 'self'; script-src 'self' https://cdn.trusted.com; style-src 'unsafe-inline'; img-src *. Explique o que cada diretiva permite ou bloqueia.

    ✓ Resposta: default-src 'self' define a política padrão para todos os recursos: apenas da mesma origem. script-src 'self' https://cdn.trusted.com permite scripts apenas da mesma origem e do CDN especificado. style-src 'unsafe-inline' permite estilos inline (potencialmente perigoso). img-src * permite imagens de qualquer origem.

  3. Você está configurando um cookie de sessão para um site bancário. Quais atributos de segurança você deve definir e por quê?

    ✓ Resposta: Deve-se definir Secure (para enviar apenas via HTTPS), HttpOnly (para impedir acesso via JavaScript), SameSite=Lax ou Strict (para mitigar CSRF) e Path=/ (para aplicar a todo o site). Isso protege contra interceptação, XSS e CSRF.

  4. Descreva a diferença entre XSS Reflected e XSS Stored. Dê um exemplo de como cada um pode ser explorado.

    ✓ Resposta: XSS Reflected: o script malicioso é refletido na resposta HTTP, geralmente via URL (ex: <script>alert('XSS')</script> em um parâmetro de busca). XSS Stored: o script é armazenado no servidor (ex: em um comentário) e executado quando outros usuários visualizam a página.

  5. Um atacante quer realizar um ataque CSRF em um site de transferências bancárias. Descreva como o ataque funciona e quais medidas podem preveni-lo.

    ✓ Resposta: O atacante cria uma página maliciosa que envia uma requisição (ex: via formulário ou imagem) para o site bancário, aproveitando que a vítima está autenticada. O navegador inclui automaticamente os cookies da vítima. Prevenções: uso de token CSRF (campo oculto), cookie com SameSite=Strict, validação de cabeçalho Origin/Referer, e reautenticação para ações críticas.