o que é a prevenção de scripts entre sites?
Cross-site scripting prevention é o processo de detecção e correção de vulnerabilidades XSS em seus sites ou aplicativos da web antes de atingirem a produção. A detecção de vulnerabilidades XSS pode ser feita automaticamente, usando um scanner de vulnerabilidade automatizado ou manualmente realizando testes de penetração. Neste artigo, você aprenderá as melhores práticas para prevenção de scripts entre sites e como implementá-las imediatamente. No final do artigo, você também encontrará um link para um scanner de vulnerabilidade gratuito e focado no desenvolvedor, para que possa começar a detectar e corrigir vulnerabilidades de script entre sites com antecedência e com frequência, como parte de seus pipelines de desenvolvimento
neste artigo, você aprenderá:
- o que é Prevenção de scripts entre sites?
- como funciona o Cross-site scripting?
- quais são os tipos de ataques XSS?
- qual a importância da prevenção de scripts entre sites?
- Cross site scripting proteção
- Escape conteúdo dinâmico
- lista de permissões de valores
- Implementar um conteúdo-a política de segurança
- Limpar HTML
- HTTP Cookies somente
- XSS Prevenção com exemplos de código
- Cross-site scripting prevenção em Python (Django)
- Cross-site scripting prevenção em Ruby (Rails)
- Cross-site scripting prevenção em Java (Java Server Pages)
- Cross-site scripting prevenção em C# (ASP.NET)
- prevenção de scripts entre sites no nó
- bigode.js
- poeira.js
- Nunjucks
- Cross-site scripting prevenção em PHP
- Cross-site scripting prevenção em AngularJS
- Cross-site scripting prevenção em Reagir
- Como pode ferramentas automatizadas ajudar a evitar cross-site scripting?
como funciona o Cross-site scripting?
Cross-Site Scripting (XSS) ataques são uma forma de ataque de injeção, onde scripts maliciosos são injetados em aplicativos da web confiáveis.
um invasor pode usar o aplicativo da web para enviar código malicioso, normalmente na forma de um script do lado do navegador, para um usuário final diferente, resultando em um ataque XSS.As vulnerabilidades XSS são muito comuns, ocorrendo onde um aplicativo da web usa a entrada de um usuário válido contido na saída gerada, mas sem a validação ou codificação apropriada.
com o script malicioso enviado ao USUÁRIO, seu navegador não consegue saber categoricamente que o script não deve ser confiável e, posteriormente, executa o script. Este script pode então acessar uma infinidade de dados, incluindo quaisquer cookies, tokens de sessão ou, de fato, qualquer outra informação sensível que possa ser retida pelo navegador para esse site.
quais são os tipos de ataques XSS?
existem três tipos principais de ataques XSS:
- XSS refletido: script malicioso vem da solicitação HTTP atual
- XSS armazenado: script malicioso vem do banco de dados do site
- XSS baseado em DOM: onde a vulnerabilidade existe no código do lado do cliente, em vez de no código do lado do servidor.
qual a importância da prevenção de scripts entre sites?
o dano causado pela exploração de uma vulnerabilidade XSS depende da sensibilidade dos dados que seu site lida. Aqui estão alguns exemplos em que hackers exploraram aplicativos vulneráveis XSS:
- espalhando worms nas mídias sociais: Facebook, Twitter e YouTube foram todos atacados com sucesso dessa maneira.
- sequestro de sessão: JavaScript malicioso pode ser capaz de enviar o ID da sessão para um site remoto sob o controle do hacker, permitindo que o hacker se faça passar por esse usuário sequestrando uma sessão em andamento.Roubo de identidade: se o USUÁRIO inserir informações confidenciais, como números de cartão de crédito em um site comprometido, esses detalhes podem ser roubados usando JavaScript malicioso.
- ataques de negação de Serviço e vandalismo no site.
- roubo de dados confidenciais, como senhas.
- fraude financeira em sites bancários.
Cross-site scripting protection
Escape dynamic content
geralmente, quando uma página da web é renderizada, o conteúdo dinâmico é tecido em HTML. Se o conteúdo dinâmico for tratado incorretamente, um invasor pode usá-lo para construir um ataque XSS armazenado. O invasor abusaria de um campo editável inserindo algum código JavaScript malicioso, que é avaliado no navegador quando outro usuário visita essa página.
você pode não querer que seus usuários criem HTML bruto, a menos que seu site seja um sistema de gerenciamento de conteúdo. Fuja de todo o conteúdo dinâmico proveniente de um armazenamento de dados, para que o navegador saiba que ele deve ser tratado como o conteúdo das tags HTML, em oposição ao HTML bruto.
Escapar de conteúdo dinâmico, geralmente, consiste em substituir os personagens significantes com a entidade HTML codificação:
” "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
Como você verá nos exemplos de código abaixo, mais modernas estruturas de escape de conteúdo dinâmico por padrão.
ao escapar do conteúdo editável dessa maneira, o conteúdo nunca será tratado como código executável pelo navegador. Isso evitará a maioria dos ataques XSS.
Whitelist values
se um item de dados dinâmico só pode ter um punhado de valores válidos, restrinja os valores no armazenamento de dados. Além disso, certifique-se de que sua lógica de renderização permita apenas valores conhecidos e adequados.
um exemplo em que você pode querer usar essa abordagem é pedir a um usuário que selecione seu país em uma lista suspensa, em vez de digitá-lo manualmente.
implementar uma política de segurança de conteúdo
navegadores modernos suportam Políticas de segurança de conteúdo. As Políticas de segurança de conteúdo permitem que o autor de uma página da web controle de onde o JavaScript e outros recursos podem ser carregados e executados.
para que um ataque XSS seja possível, o invasor deve ser capaz de executar scripts maliciosos na página da web de um usuário – injetando inline <script> tags em algum lugar dentro da tag <html> de uma página ou enganando o navegador para carregar o JavaScript de um domínio malicioso de terceiros.
Definição de uma política de segurança de conteúdo no cabeçalho de resposta irá permitir que você para dizer ao browser para nunca executar JavaScript inline, e para escolher domínios que podem hospedar JavaScript de uma página:
Content-Security-Policy: script-src 'self' https://apis.google.com
Por essa característica que os URLs de scripts que pode ser carregado, você está implicitamente afirmando que na linha de JavaScript não é permitido.
você também pode colocar a Política de segurança de conteúdo em uma tag <meta> no elemento <head> de uma página:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
essa abordagem é muito eficaz na proteção de seus usuários, mas requer disciplina para preparar seu site para esse cabeçalho. Embora ter scripts embutidos seja considerado uma prática ruim no desenvolvimento da web moderno, eles são comuns em sites antigos e legados.
para migrar para longe de scripts embutidos de forma incremental, considere fazer uso de relatórios de violação CSP. Ao adicionar uma diretiva report-uri no cabeçalho da sua política, o navegador notificará você de quaisquer violações de política, em vez de impedir a execução de JavaScript embutido:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
isso lhe dará a garantia de que não há scripts inline persistentes, antes de bani-los imediatamente.
higienizar HTML
para alguns sites, há uma necessidade legítima de armazenar e renderizar HTML bruto. Se o seu site armazena e renderiza conteúdo rico, você precisa usar uma biblioteca de higienização de HTML para garantir que usuários mal-intencionados não possam injetar scripts em seus envios de HTML.
cookies somente HTTP
JavaScript malicioso pode ser usado para roubar um cookie contendo o ID da sessão do Usuário. Raramente há um bom motivo para ler ou manipular cookies em JavaScript do lado do cliente, portanto, considere marcar cookies como apenas HTTP, o que significa que os cookies serão recebidos, armazenados e enviados pelo navegador, mas não podem ser modificados ou lidos por JavaScript.
XSS Prevenção com exemplos de código
Cross-site scripting prevenção em Python (Django)
Modelos em Django escapar HTML por padrão, então qualquer coisa que se parece com o seguinte é geralmente seguro:
**{{ contents }}**
Você pode substituir escapar usando o | filtro de segurança. Muitas vezes, há boas razões para fazer isso, mas você precisará realizar revisões de código em qualquer coisa que use este comando:
**{{ contents | safe }}**
observe que HTML-escaping também pode ser ligado ou desligado com a tag {% autoescape %}.
prevenção de scripts entre sites em Ruby(Rails)
os modelos Rails escapam do HTML por padrão, portanto, qualquer coisa que se pareça com o seguinte geralmente é Segura:
<%= contents %>
você pode substituir escape usando a função raw ou usando o operador <%==. Há muitas boas razões para fazer isso, mas você vai precisar para realizar as revisões de código em tudo o que utiliza estas funções:
<% raw contents %>
<%== contents %>
Cross-site scripting prevenção em Java (Java Server Pages)
Use c:out tag para escapar com segurança HTML:
<c:out value="${contents}">
As seguintes maneiras de escrever para um modelo não escapar HTML, então você deve usá-los com cuidado:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-site scripting prevenção em C# (ASP.NET)
Use um dos seguintes funções de segurança escapar HTML (a <%: formulário foi introduzido em ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
A seguinte forma de escrita para um modelo não escapar HTML automaticamente, então você deve usá-los com cuidado:
<%= contents %>
Use HttpUtility.HtmlEncode(...) se você necessita de manualmente escapar HTML.
prevenção de scripts entre sites no nó
bigode.js
em bigode.js, quaisquer tags em bigodes duplos escapam automaticamente ao HTML:
{{ contents }}
lembre-se de que as tags em bigodes triplos não escapam ao HTML, portanto, use-as com cuidado:
{{{ contents }}}
pó.js
Chave tags automaticamente escapar HTML:
{ contents }
no Entanto, escapando pode ser desactivado com o |s operador, então use isso com cuidado
{ contents | s }
Nunjucks
Se auto-escaping é ligado no ambiente, Nunjucks será automaticamente escapar tags de segurança para a saída:
{{ contents }}
o Conteúdo marcado com o filtro de segurança não será escapou – use esta função com cuidado:
{{ contents | safe }}
Auto-escaping pode ser desativado por um modelo, caso em que marcas precisam ser digitada manualmente:
{{ contents | escape }}
Cross-site scripting prevenção em PHP
O comando echo do PHP, não escapa HTML por padrão, o que significa que qualquer código como o seguinte, que puxa os dados diretamente do pedido HTTP, é vulnerável a ataques de XSS:
<?php
Echo $_POST;
?>
Cross-site scripting prevenção em AngularJS
Qualquer conteúdo escrito entre chaves será automaticamente escapou, de modo que o seguinte é seguro:
<div>{{dynamicContent}}</div>
tenha em mente que qualquer código que liga conteúdo dinâmico para o atributo innerHTML não será automaticamente escapou:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Cross-site scripting prevenção em Reagir
Qualquer conteúdo dinâmico escritos entre chaves será automaticamente escapou em Reagir, então, o seguinte código é seguro:
render() {
return <div>{dynamicContent}</div>
}
Você também pode escrever HTML através da ligação de conteúdo para o dangerouslySetInnerHTML propriedade. O nome não é uma coincidência, então procure qualquer código que se pareça com o seguinte:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
como as ferramentas automatizadas podem ajudar a evitar scripts entre sites?
como mencionado acima, prevenir ataques de script entre sites pode ser fácil, com muitas estruturas escapando de conteúdo dinâmico por padrão. Mas essa conveniência pode levar à inadvertência e a alguns sérios pontos fracos de segurança para sua aplicação e sua empresa.Sempre certifique-se de verificar seus aplicativos em busca de vulnerabilidades antes de liberá-las para produção, idealmente como parte de seus pipelines de DevOps e CI/CD para detectar e corrigir vulnerabilidades de segurança mais cedo, em cada compilação / commit.
você pode começar a automatizar seus testes de segurança hoje com o Dynamic Application Security Testing scanner da NeuraLegion, Nexploit. Construído para desenvolvedores e sem falsos positivos, você pode integrá-lo em seus pipelines para mudar os testes de segurança para a esquerda e ser seguro por design.
Inscreva-se para sua conta gratuita aqui: https://nexploit.app/signup