Visão Geral de Scripts Maliciosos

Da perspectiva de um browser, uma pagina Web é uma simples cadeia longa de caracteres. O browser processa a String sequencialmente, exibindo alguns caracteres enquanto interpreta outros, como <b> e <script> de acordo com regras especificas. Se um usuário mal-intencionado pode inserir um desses caracteres especiais em uma página, o browser não sabe que estes caracteres não deveriam estar ali, e vai processá-lo como parte da página.

Um simples script de exploração(exploit) poderia funcionar da seguinte forma. Se um aplicativo permite aos usuários postar comentários sobre os filmes mais recentes para que outros usuários leiam, as etapas de exploração podem ser:

  1. O aplicativo exibe um formulário onde os usuários inserem comentários. O usuário mal-intencionado escreve um comentário que inclui um bloco <script> nele.

  2. O formulário é remetido e o comentário do usuário mal-intencionado é armazenado em um banco de dados.

  3. Outro usuário visita o site. Quando a página é construída, ela lê comentários do banco de dados e insere na página. O bloco mal-intencionado <script> é escrito na pagina como se fosse um texto do comentário.

  4. Quando o segundo navegador do usuário mostra a página, isso leva ao bloco script> e o executa.

Há outras maneiras que usuários mal-intencionados podem explorar scripts (exploits). A maioria das falhas de script exigem que a aplicação aceite a entrada maliciosa e injete-a (ou ecoa-la) em uma página onde será executado pelo navegador. Os danos potenciais de tal exploração dependem do script que é executado. Pode ser trivial, tal como uma mensagem irritante que aparece no navegador. Mas também pode causar sérios danos ao roubar cookies, roubar a entradas do usuário (como uma senha), e, se a segurança na Internet é fraca, executando código nativo no computador do usuário.

Para obter informações sobre como evitar explorações de script, consulte Como: Proteger contra exploits script em um aplicativo Web da Web, Applying HTML Encoding to Strings.

ObservaçãoObservação:

ASP.NET ajuda a proteger contra scripts maliciosos disfarçados sistema autônomo URLs, Verificando cadeias de caracteres potencialmente perigosas, sistema autônomo "<!","< /", e "<?".

Uma variação dos scripts de exploração(exploits) são aqueles que causam danos em rotinas SQL que serão executadas. Isso pode ocorrer se um aplicativo solicita aos usuários para obter informações e depois concatena a entrada do usuário em uma seqüência que representa a instrução SQL. Por exemplo, um aplicativo pode solicitar um nome de cliente com a intenção de executar uma instrução, como a seguinte:

"Select * From Customers where CustomerName = " & txtCustomerName.Value

Mas um usuário mal-intencionado que sabe algo sobre o banco de dados pode usar a caixa de texto para inserir uma instrução SQL incorporada com o nome do cliente, resultando em uma declaração como a seguinte:

Select * From Customers Where CustomerName = 'a' Delete From Customers Where CustomerName > ''

Quando a consulta é executada, o banco de dados está comprometido.

A principal defesa contra scripts maliciosos(exploits) é nunca confiar em informações vindas de usuários. Suponha que todos os dados postados para a sua aplicação a partir de um navegador pode conter script malicioso.

Da mesma forma, sempre que você escrever uma string em uma página, você deve assumir que a string pode conter script malicioso (a menos que você crie a string programaticamente). Por exemplo, quando você lê strings de um banco de dados, você deve assumir que eles podem conter scripts maliciosos. A maioria dos desenvolvedores preocupados com a segurança desconfiam até mesmo dos seus próprios bancos de dados, na teoria de que um usuário mal-intencionado pode ter encontrado uma maneira de mexer com o banco de dados.

ASP.NET lhe oferece várias maneiras para ajudar a proteger de script maliciosos:

  • ASP.NET executa validações de solicitação em QueryStrings e variáveis ​​de formulário, bem como valores de cookies. Por padrão, se o Request corrente contem elementos HTML-encoded ou certos caracteres(como &#151; para um traço), a pagina ASP.NET gera um erro.

  • Se você deseja exibir strings em sua aplicação, mas não confia nelas, aplique a codificação HTML quando as strings são escritas de volta como resposta. Por exemplo, com codificação, a tag <b> torna-se &lt;b&gt;. Você deve fazer isso se as strings que você está exibindo são de um banco de dados cujo conteúdo você não tem certeza de que pode confiar.

  • Se você precisa que seu aplicativo aceite HTML(por exemplo, algumas instruções de formatação dos usuários), você deve codificar o HTML no cliente antes de enviar para o servidor. Para mais informações, veja Como: proteger contra scripts maliciosos em um aplicativo da Web aplicando a codificação HTML a sequências de caracteres.

  • Para ajudar a proteger contra ataques de instrução SQL, nunca crie querys SQL utilizando concatenação. Em vez disso, use uma consulta parametrizada e atribua a entrada do usuário aos objetos de parâmetro. Para obter detalhes, consulte:Parâmetros em comandos do adaptador de dados.

  • Sempre valide o formulário de entrada através de um conjunto de valores esperados e strings de formatação e validação de tipos. Por exemplo, se uma variável formulário específica é esperada para ser um inteiro, use o Int32.TryParse método para verificar que realmente o valor é um número inteiro e usar a verificação de intervalo para ajudar a garantir que o valor está em um intervalo aceitável.

Contribuições da comunidade

ADICIONAR
Mostrar: