Prefácio
No modelo de desenvolvimento de separação de front-end e back-end, a mudança mais óbvia em termos de funções e funções de desenvolvimento é: no passado, os alunos de front-end que eram responsáveis apenas pelo desenvolvimento no ambiente do navegador necessário para explorar o nível de extremidade do servidor e escrever o código do final do servidor. E uma pergunta básica diante de nós é como garantir a segurança da Web?
Este artigo propõe soluções para os problemas de segurança encontrados pelo modo de separação front-end e back-end no desenvolvimento da Web do front-end, além de contramedidas e precauções.
Defesa do ataque de scripts de sites cruzados (XSS)
Problemas e soluções
O script entre sites (XSS, script cruzado) é o método mais comum e básico de atacar sites da Web. Um invasor pode publicar dados contendo código ofensivo em uma página da web. Quando um navegador vê esta página da web, um script específico será executado como identidade e permissões do usuário do navegador. O XSS pode ser mais facilmente modificado, roubar dados do usuário, informações do usuário e causar outros tipos de ataques, como ataques de CSRF.
A maneira básica de prevenir ataques XSS é garantir que qualquer saída de dados para uma página HTML seja escapa no HTML (HTML Escape). Por exemplo, o seguinte código de modelo:
A cópia do código é a seguinte:
<textarea name = "Descrição"> $ Descrição </sexttarea>
A descrição $ neste código é uma variável do modelo (a sintaxe das variáveis definidas em diferentes modelos é diferente, aqui está apenas um diagrama). Os dados enviados pelo usuário podem inserir uma parte do código que contém "JavaScript" para fazer com que o resultado da instrução do modelo acima se torne o seguinte resultado:
A cópia do código é a seguinte:
<textarea name = "description">
</sexttarea> <cript> alert ('hello') '</script>
</sexttarea>
O código acima, renderizado no navegador, executará o código JavaScript e alerta o Hello na tela. Obviamente, esse código é inofensivo, mas um invasor pode criar um JavaScript para modificar as informações do usuário ou roubar dados de cookies.
A solução é muito simples, o que é para escapar do valor de $ Descrição. O código de saída após a fuga é o seguinte
A cópia do código é a seguinte:
<textarea name = "description">
</sexttarea> <cript> alerta (olá!) </script>
</sexttarea>
O código HTML escapado acima não é prejudicial.
Solução de Midway
Escape todos os dados de saída do usuário na página
Existem várias situações e métodos para escapar dados:
1. Escape usando o mecanismo fornecido dentro do modelo
O Midway usa o Kissy Xtemplate como a linguagem do modelo.
Na implementação do XTEMplate, os dados do modelo são sintaxes analisados usando dois colchetes ({{val}}). Por padrão, os dados são escapados em HTML, para que os desenvolvedores possam escrever modelos como este:
A cópia do código é a seguinte:
<texttarea name = "description"> {{description}} </sexttarea>
No XTemplate, se você não deseja que os dados de saída sejam escapes, precisará usar três colchetes ({{{val}}}).
2. Chamadas sem ambiguidade de funções de escape no meio
Os desenvolvedores podem chamar diretamente o método HTML Escape fornecido por meio do programa Node.js para escapar dos dados exibidos, como segue:
Método 1: Dados de escape html no programa Node.js
A cópia do código é a seguinte:
var segurança = requer ('meio de segurança');
// dados do servidor, por exemplo, {html: '</sexttarea>', outros: ""}
data.html = segurança.escapehtml (data.html);
xtpl = xtpl.render (dados);
Método 2: html escape html dados no modelo
A cópia do código é a seguinte:
<TextAne Name = "Descrição"> Security.escapehtml ({{{description}}}) </sexttarea>
Nota: Security.escapehtml é usado para escapar apenas quando os dados não são escapados dentro do modelo. Caso contrário, o modelo interno e o programa escaparão da sobreposição duas vezes, resultando em uma saída que não atende às expectativas.
Recomendado: Se você usar o XTemplate, é recomendável usar o {{}} do modelo interno para escapar diretamente; Se você usar outros modelos, é recomendável usar o Security.escapehtml para fuga.
Filtre a saída de texto rico dos usuários na página
Você pode pensar: "Na verdade, eu só quero produzir texto rico, como alguns quadros de mensagens e fóruns para fornecer aos usuários um tamanho simples de fonte, cor, fundo e outras funções. Então, como devo lidar com um texto tão rico para evitar XSs?"
1. Use a função RichText fornecida pela segurança no meio do caminho
O Midway fornece o método Richtext, que é usado especialmente para filtrar o texto rico e impedir vulnerabilidades como XSS, phishing e roubo de biscoitos.
Há um quadro de mensagens e o código do modelo pode ser o seguinte:
A cópia do código é a seguinte:
<div>
{{{mensagem}}}
</div>
Como a mensagem é os dados de entrada do usuário, o conteúdo de sua placa de mensagem contém informações de texto ricas, aqui três aparelhos são usados no XTemplate e as escapadas HTML não são executadas por padrão; Em seguida, os dados inseridos pelo usuário são os seguintes:
A cópia do código é a seguinte:
<script src = "http://eval.com/eval.js"> </script> <span style = "cor: vermelho; font-size: 20px; posição: corrigido;"> estou deixando uma mensagem </span>
Se os dados de texto ricos acima forem emitidos diretamente para a página, ele inevitavelmente levará à injeção de JS do site Eval.com na página atual, causando um ataque XSS. Para evitar essa vulnerabilidade, apenas chamamos o método de segurança.RichText no modelo ou programa para processar a entrada de texto rica pelo usuário.
O método de chamada é semelhante ao escapehtml, e há duas maneiras de
Método 1: Ligue diretamente no programa Node.js
A cópia do código é a seguinte:
mensagem = segurança.RichText (mensagem);
var html = xtpl.render (mensagem)
Método 2: Ligue para o modelo
A cópia do código é a seguinte:
<div>
Security.RichText ({{{message}}})
</div>
Depois de chamar o método de segurança RichText, a saída final é a seguinte:
A cópia do código é a seguinte:
<div>
<span style = "cor: vermelho; tamanho da fonte: 20px;"> Estou deixando uma mensagem </span>
</div>
Pode -se observar isso primeiro: a tag de script que causará ataques XSS será filtrada diretamente; Ao mesmo tempo, a posição do atributo CSS: fixo; O estilo na tag de estilo também é filtrado. Finalmente, o texto rico em HTML inofensivo é emitido
Aprenda sobre outras maneiras de potencialmente levar a ataques XSS
Além do possível ataque XSS no modelo de página, existem várias outras maneiras nos aplicativos da Web que também podem ser arriscados.
1. Vulnerabilidade na página de erro
Se uma página não puder ser encontrada, o sistema poderá relatar um erro 404 não encontrado, por exemplo: http: // localhost/page/não/encontrado
404 Notfound
Página/página/não/encontrado não exita
Obviamente: o invasor pode usar esta página para construir uma conexão como essa, http: // localhost/%3cscript%3Ealert%28%27hello%27%29%3c%2fscript%3e e atrair a vítima a clicar; Se a página de erro não escapar da variável de saída, o <sCript> alerta ('hello') </sCript> oculto na conexão será executado.
Em Express, o método de enviar uma página 404 é o seguinte
Res.send (404, 'Desculpe, não achamos isso!')
Aqui, os desenvolvedores precisam prestar atenção ao manuseio da página de erro (404 ou outro status de erro). Se o conteúdo de retorno da mensagem de erro contiver informações do caminho (de fato, para ser mais preciso, as informações de entrada do usuário), você deverá executar o EscapeHtml.
Posteriormente, o mecanismo de segurança de manuseio de erros será concluído no nível da estrutura do meio do caminho.
Notas adicionais para soluções Midway
Outros motores de modelo
O Midway suporta modelos XTEMPLATE por padrão, mas também pode suportar outros modelos no futuro: como jade, bigode, EJs, etc. Atualmente, em modelos principais, são fornecidos métodos de escrita de saída e não escapados, e os desenvolvedores precisam prestar atenção especial à sua segurança.
Outro apoio à fuga
Além da saída de dados normais e ricos de texto na página, alguns cenários também incluem outras situações que podem exigir escape. Midway fornece os seguintes métodos de fuga comumente usados para os desenvolvedores usarem:
Escapehtml filtra caracteres em HTML especificado para impedir vulnerabilidades XSS
JSENCODE JavaScript Escape de strings de entrada. UNICODE ESCAPE de chinês, citações únicas e citações duplas Escape
Escapejson não destrói a função de fuga da estrutura JSON e apenas executa o processamento Escapehtml em nome e vaule na estrutura JSON
Escapejsonforjsvar é compreensivelmente JSENCODE+ESCAPEJSON
Exemplos são os seguintes
A cópia do código é a seguinte:
var jSontext = "{/" <SCRIPT>/":/" <SCRIPT>/"}";
Console.log (SecurityUtil.escapejson (JSontext)); // {"<Script>": "<Script>"}}
var jSontext = "{/" hello/":/" <cript>/"}";
Console.log (SecurityUtil.escapejsonforjsvar (JSontext)); // {/"/u4f60/u597d/":/"<cript>/"}
var str = "alerta (/" hello/")";
console.log (SecurityUtil.jsencode (str)); // alerta (/"/u4f60/u597d/")
Prevenção do ataque de falsificação de solicitação entre sites (CSRF)
Problemas e soluções
Definição de Termos: Formulário: Refere -se geralmente ao formulário usado pelo navegador para enviar dados sobre o cliente; Incluindo uma tag, dados de envio de AJAX, dados de envio do formulário, etc., em vez das tags do formulário iguais a HTML.
A falsificação de solicitação entre sites (CSRF, falsificação de solicitação entre sites) é outro ataque comum. O invasor forjou uma solicitação através de vários métodos e imitou o comportamento do usuário de enviar formulários, alcançando assim o objetivo de modificar os dados do usuário ou executar tarefas específicas.
Para fingir ser um usuário, os ataques de CSRF são frequentemente combinados com ataques XSS, mas outros meios podem ser usados: por exemplo, para induzir os usuários a clicar em um link que contém o ataque.
A idéia de resolver ataques de CSRF é dividida em duas etapas.
1. Aumente a dificuldade do ataque. Obter solicitações são fáceis de criar. Os usuários podem iniciar solicitações de get-Type clicando em um link. As solicitações de postagem são relativamente difíceis. Os invasores geralmente precisam usar o JavaScript para implementá -los. Portanto, garantir que os formulários ou interfaces de servidor aceitem apenas solicitações de envio pós-tipo pode aumentar a segurança do sistema.
2. Autentique a solicitação para garantir que a solicitação tenha sido realmente preenchida o formulário ou iniciou a solicitação e enviada pelo usuário, em vez de forjada por terceiros.
O processo de um usuário normal de modificar as informações do site é o seguinte
Solicitações do usuário para modificar informações (1) -> O site exibe o formulário de informações modificadas do usuário (2) -> Modifys do usuário e envia (3) -> O site aceita os dados e salva modificados do usuário (4)
Um ataque de CSRF não seguirá essa rota, mas forjará diretamente as informações de envio do usuário na etapa 2.
Pule diretamente para a Etapa 2 (1) -> Forja as informações a serem modificadas e envie (2) -> O site aceita o invasor para modificar os dados do parâmetro e salvar (3)
Enquanto essas duas situações puderem ser distinguidas, os ataques de CSRF podem ser evitados. Então, como distingui -lo? É para verificar as informações enviadas na Etapa 2 para garantir que os dados venham do formulário na etapa 1. O processo de verificação específico é o seguinte:
Solicitações do usuário para modificar informações (1) -> O site exibe um formulário em branco usado para modificar as informações. O formulário contém um token especial e salva o token na sessão (2) -> o usuário modifica as informações e a envia e envia de volta as informações do token ao servidor (3) -> O site compara o token enviado de volta pelo usuário e pelo token na sessão. Deve ser consistente. Em seguida, os dados modificados pelo usuário são aceitos e salvos.
Dessa forma, se o invasor forjou as informações a serem modificadas e enviadas, ele não poderá acessar diretamente a sessão, para que não pudesse obter o valor real do token; Se a solicitação foi enviada ao servidor, quando o servidor executou a verificação de token, seria encontrado que era inconsistente e a solicitação foi rejeitada diretamente.
Midway Solutions
Desativar o formulário de envio
Se o servidor não aceitar os dados do formulário enviados pelo GET, ele causará grande dificuldade para o invasor; Porque é muito fácil construir um atributo href a-label ou um atributo SRC da IMG-Label na página para construir uma solicitação, mas se você deseja enviá-lo, deve usar um script para implementá-lo.
Verifique os pedidos com token CSRF
Como o Midway não envolve a lógica da sessão distribuída e da verificação de token do Taobao, na estrutura Midway, apenas os tokens são encaminhados entre o servidor e o cliente e não faz o trabalho de verificação real. O processo é o seguinte:
Posteriormente: em Midway, após a sessão distribuída de Node.js e Taobao estão conectados, você pode considerar o execução automaticamente de verificação de token na camada intermediária; Afinal, quanto mais cedo a verificação de segurança for realizada, menor o custo.
Sugestão: No meio do caminho, você pode determinar se há um valor de token na solicitação. Se uma operação de modificação não tiver um token, você poderá considerá -lo diretamente na camada intermediária como insegura e descartar a solicitação.
Outros problemas de segurança
Existem vários problemas comuns de segurança na Web. Aqui estão apenas algumas apresentações e continuarão sendo herdadas na estrutura do meio do caminho no futuro.
Segurança dos cabeçalhos HTTP
Os atacantes de injeção de CRLF encontram maneiras de injetar dois caracteres especiais da CRLF no cabeçalho da resposta, resultando em um formato de dados de resposta excepcional, injetando assim o script, etc.
O acesso negado ataca todas as solicitações porque os cookies são trazidos por padrão, e o servidor geralmente limita o tamanho dos cookies, o que leva a isso se os cookies dos clientes do usuário estiverem configurados para exceder um determinado limite, o usuário não poderá mais acessar o site.
Prevenção e controle de biscoitos, o roubo geral de biscoitos é obtido por meio de JavaScript (vulnerabilidade XSS); portanto, tente definir cookies apenas para HTTP e adicione o tempo de expiração do cookie
Em relação aos problemas de segurança dos cookies, a Webx já teve uma boa solução antes; Desta vez, a Midway não é responsável pela configuração e verificação dos cookies e é responsável apenas pelo encaminhamento para o nível Webx para verificar.
Sobre node.js
Vulnerabilidades injetivas como XSs são as mais fáceis de serem ignoradas entre todas as vulnerabilidades, representando mais de 70% do total de ataques da Internet; Ao escrever o código Node.js, os desenvolvedores devem sempre se lembrar e nunca confiarem nas entradas dos usuários.
Por exemplo, os seguintes exemplos.
var mod = fs.readfilesync ('caminho'); Se o caminho vier da entrada do usuário, assumindo que o usuário insira /etc /senha, conteúdo que não deve ser lido será lido, causando o risco de vazamento de senha
var resultado = avaliar (jsonval); Certifique -se de garantir que o JSONVAL seja JSON, não a entrada do usuário
... Em outros lugares que podem conter a entrada do usuário, certifique -se de confirmar que a entrada do usuário é o valor que esperamos.
Resumir
No modo de separação do front-end e back-end, os desenvolvedores de front-end tradicionais podem começar a escrever código de back-end. Embora a arquitetura seja responsável apenas pela camada de modelo, eles também serão expostos a uma grande quantidade de código de back-end; Portanto, a segurança é um grande desafio para o front-end.