O JavaScript pode ser usado como uma ferramenta para hackers atacarem sites. Injetar scripts maliciosos por JS (JavaScript) é um dos métodos. Então, vamos aprender a evitar ataques de injeção de JS? A seguir, é apresentada uma boa declaração, compartilhe com você:
O que é um ataque de injeção de JavaScript?
Sempre que você aceita a entrada de conteúdo de um usuário e o redisplay, o site é vulnerável a ataques de injeção de JavaScript. Vejamos um aplicativo específico vulnerável a ataques de injeção de JavaScript. Suponha que um site de feedback do cliente tenha sido criado. Os clientes podem visitar o site e inserir informações de feedback sobre o produto. Quando um cliente envia feedback, as informações de feedback são exibidas na página de feedback.
O site de feedback do cliente é um site simples. Infelizmente, este site é vulnerável a ataques de injeção de JavaScript.
Suponha que o texto a seguir esteja sendo inserido no formulário de feedback do cliente:
<cript> alerta ("boo!") </sCript>
Este texto representa um script JavaScript que exibe a caixa de mensagem de aviso. Depois que alguém enviar este script para o formulário de feedback do cliente, a mensagem Boo! mostrará um ataque quando alguém visitar o site de feedback do cliente no futuro. Você também pode pensar que outros não serão capazes de destruí -lo através de ataques de injeção de JavaScript.
Agora, sua primeira reação aos ataques de injeção de JavaScript pode ser ignorá -los. Você pode pensar que ataques de injeção de JavaScript nada mais são do que inofensivos e, infelizmente, os hackers sabotam injetando JavaScript em seus sites. Um ataque de injeção de JavaScript pode ser usado para realizar ataques de scripts cruzados (XSS). Em um ataque de script entre sites, as informações confidenciais do usuário podem ser roubadas e enviadas para outro site.
Por exemplo, os hackers podem usar ataques de injeção de JavaScript para roubar valores de cookies dos navegadores de outros usuários. Se informações confidenciais (como senhas, contas de cartão de crédito ou números de seguridade social) forem salvas em cookies do navegador, os hackers poderão roubá -los usando ataques de injeção de JavaScript. Como alternativa, se o usuário inserir informações confidenciais no campo do formulário da página e a página for comprometida por um ataque JavaScript, o hacker poderá usar o JavaScript injetado para obter os dados do formulário e enviá -los para outro site.
Por favor, preste muita atenção. Leve a sério os ataques de injeção de JavaScript e proteja as informações confidenciais dos usuários. Nas próximas duas seções, discutiremos duas técnicas para impedir que as aplicações do ASP.NET MVC sejam atacadas pela injeção de JavaScript.
Método 1: codificação HTML na vista
Uma maneira fácil de evitar ataques de injeção de JavaScript é codificar dados inseridos por qualquer usuário do site em HTML ao redisplaying dados na visualização.
Por exemplo: <%= html.encode (feedback.message)%>
Qual é o significado de usar HTML para codificar uma string? Ao usar o HTML para codificar strings, caracteres perigosos como <e> são substituídos por entidades HTML como <e>. Então, quando a string <Script> alert ("boo!") </sCript> for codificada usando html, ele será convertido em <cript> alert ("boo!") </sCript>. O navegador não executa mais scripts JavaScript quando a análise codificada codificou strings. Em vez disso, mostra páginas inofensivas
Método 2: codificação HTML antes de escrever para o banco de dados
Além de usar o HTML para codificar dados ao exibir dados em uma visualização, você também pode usar o HTML para codificar dados antes de enviá -los ao banco de dados. O segundo método é exatamente o caso do controlador na listagem 4 do programa.
como:
public ActionResult Create (String message) {// Adicione feedbackvar newfeedback = new feedback (); newfeedback.message = server.htmlencode (message); newfeedback.entrydate = dateTime.now; db.feedbacks.inserTonsubMit (newFeed); // redirectReTurn RedirectToAction ("índice");}Observe que o valor da mensagem é codificado em HTML na operação create () antes de enviar ao banco de dados. Quando uma mensagem é exibida na exibição, a mensagem é codificada HTML, para que nenhum JavaScript injetado na mensagem seja executado.
Resumir
Muitas vezes, as pessoas preferem usar o primeiro método discutido neste tutorial e não no segundo método. O problema com a segunda abordagem é que os dados codificados por HTML acabarão sendo retidos no banco de dados. Em outras palavras, os dados no banco de dados conterão caracteres estranhos. Qual é a desvantagem disso? Se você precisar exibir dados do banco de dados em um formulário que não seja uma página da web, você encontrará problemas. Por exemplo, os dados não podem ser exibidos facilmente nos aplicativos do Windows Forms.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.