Como eu protejo contra ataques XSS em atributos como src?

9

Por isso, tenho construído um sanitizer C # html usando agilidade em html com uma lista branca. Funciona bem, exceto em casos como estes:

<img src="javascript:alert('BadStuff');" />
<img src="jav&#x09;ascript:alert('BadStuff');"> 

Eu quero permitir o atributo src, não apenas coisas maliciosas dentro dele, obviamente. Todas as coisas que pesquisei recomendaram uma lista de permissões para tags e seus atributos. Como você lidaria com algo assim? Eu sei que isso não funcionará em nenhum navegador mais recente, mas eu não estou muito familiarizado com a segurança e tenho certeza de que há outras coisas inteligentes que os invasores podem fazer.

    
por user1652427 07.03.2013 в 21:54
fonte

3 respostas

5

Os ataques de cross-site scripting (XSS) exploram vulnerabilidades na validação de páginas da Web, injetando código de script do lado do cliente. Vulnerabilidades comuns que tornam seus aplicativos Web suscetíveis a ataques de script entre sites incluem a falha em validar a entrada corretamente, falhar em codificar a saída e confiar nos dados recuperados de um banco de dados compartilhado. Para proteger seu aplicativo contra ataques de script entre sites, suponha que todas as entradas sejam mal-intencionadas. Restringir e validar todas as entradas. Codifique todas as saídas que possam, potencialmente, incluir caracteres HTML. Isso inclui dados lidos de arquivos e bancos de dados.

Um dos exemplos mais sérios de um ataque de script entre sites ocorre quando um invasor grava um script para recuperar o cookie de autenticação que fornece acesso a um site confiável e depois o publica em um endereço da Web conhecido pelo invasor. Isso permite que o invasor falsifique a identidade do usuário legítimo e obtenha acesso ilícito ao site.

Vulnerabilidades comuns que tornam seu aplicativo Web suscetível a ataques de script entre sites incluem:

  • Falha ao restringir e validar entrada.
  • Falha ao codificar a saída.
  • Confiar nos dados recuperados de um banco de dados compartilhado.

Diretrizes

As duas contramedidas mais importantes para impedir ataques de script entre sites são:

  • Restringir entrada.
  • Codifique a saída.

Resumo das etapas

Para evitar o script entre sites, execute as seguintes etapas:

Etapa 1. Verifique se a validação da solicitação do ASP.NET está ativada.

Etapa 2. Analise o código do ASP.NET que gera a saída HTML.

Etapa 3. Determine se a saída HTML inclui parâmetros de entrada.

Etapa 4 . Analise tags e atributos HTML potencialmente perigosos.

Etapa 5 . Avalie as contramedidas.

Para detalhes, consulte a segunda referência.

Referências:

Explicação de scripts entre sites : Como evitar ataques XSS

Como: Impedir scripts entre sites no ASP.NET

    
por Abdur Rahman 18.03.2013 / 11:43
fonte
0

Algo como "deve ser Uri válido, relativo ou absoluto, com esquema http / https" é um bom ponto de partida.

    
por Alexei Levenkov 07.03.2013 / 22:01
fonte
0

Você pode permitir com segurança o atributo src, desde que você limpe e manipule a entrada corretamente. Para fazer isso, você deve primeiro higienizá-lo através de uma lista de permissões de caracteres de URL válidos, canonicalize e, em seguida, verifique se aponta para uma imagem válida.

A lista branca que você mencionou é o primeiro passo (e importante). Para implementar a lista de permissões, retire todos os caracteres que não sejam válidos para um URL. Além disso, verifique se o URL está formado corretamente, o que significa que ele aponta para um recurso válido que o usuário deve poder acessar. Por exemplo, o usuário não deveria estar acessando um arquivo local no servidor passando file://sensitive.txt ou algo assim. Se http ou https forem os únicos protocolos que devem ser usados, verifique se o URL começa com eles. Se você é paranóico extra você pode rejeitar o pedido completamente desde que é óbvio que foi adulterado. A lista de permissões é importante, mas a lista de permissões apenas não mantém o recurso seguro.

A canonização é importante porque muitos ataques dependem do envio de URLs que eventualmente o levam a um determinado local, mas podem abusar da falta de raciocínio inato do computador para fazer o que não deveria. Isso também ajudará a eliminar caminhos duplicados para o mesmo recurso, o que pode melhorar o desempenho (ou pelo menos permitir que você melhore o desempenho, não verificando novamente um arquivo conhecido que não foi alterado desde a última vez que você o verificou. É possível falsificar uma data da última modificação para que um invasor possa trocar um arquivo mal-intencionado depois que você já tiver "verificado e confiá-lo".

Para verificar se você está apontando para uma imagem válida, abra o arquivo e leia nos primeiros bytes. Do não simplesmente confie na extensão do arquivo, mas verifique primeiro antes de abrir o arquivo (para desempenho e segurança). Todo formato de imagem tem um certo padrão de bytes que você pode verificar. Um bom para olhar em primeiro lugar é JPEG . Pode ainda ser possível para um usuário mal-intencionado colocar o shellcode ou outro código de ataque em um arquivo de imagem que contém os cabeçalhos adequados, mas é muito mais difícil de fazer. Esse será um gargalo de desempenho, portanto, planeje apropriadamente se você implementar isso.

    
por Freedom_Ben 12.03.2013 / 20:27
fonte