Segurança e entrada do usuário

Os dados do usuário, que são qualquer tipo de entrada (dados de uma solicitação da Web ou URL, entrada para controles de um aplicativo Microsoft Windows Forms e assim por diante), podem influenciar negativamente o código porque muitas vezes esses dados são usados diretamente como parâmetros para chamar outro código. Esta situação é análoga ao código malicioso chamando o seu código com parâmetros estranhos, e as mesmas precauções devem ser tomadas. Entrada do utilizador é realmente mais difícil de tornar segura porque não há um frame de stack para rastrear a presença dos dados potencialmente não confiáveis.

Estes estão entre os bugs de segurança mais sutis e difíceis de encontrar porque, embora possam existir em código que aparentemente não está relacionado à segurança, eles são uma porta de entrada para passar dados ruins para outro código. Para procurar esses bugs, siga qualquer tipo de dados de entrada, imagine qual pode ser o intervalo de valores possíveis e considere se o código que vê esses dados pode lidar com todos esses casos. Você pode corrigir esses bugs através da verificação de intervalo e rejeitando qualquer entrada que o código não possa manipular.

Algumas considerações importantes que envolvem os dados do usuário incluem o seguinte:

• Todos os dados do usuário em uma resposta do servidor são executados no contexto do site do servidor no cliente. Se o seu servidor Web receber dados de utilizador e inseri-los na página Web devolvida, pode, por exemplo, incluir uma etiqueta <script> e executá-la como se estivesse a ser executada a partir do servidor.

• Lembre-se de que o cliente pode solicitar qualquer URL.

• Considere caminhos complicados ou inválidos:

  • .. \ , caminhos extremamente longos.

  • Utilização de caracteres coringa (*).

  • Expansão de token (%token%).

  • Estranhas formas de caminhos com significado especial.

  • Nomes alternativos de fluxo do sistema de arquivos, como filename::$DATA.

  • Versões curtas de nomes de arquivo, como longfi~1 para longfilename.

• Lembre-se que Eval (userdata) pode fazer qualquer coisa.

• Desconfie da vinculação tardia a um nome que inclua alguns dados do usuário.

• Se você estiver lidando com dados da Web, considere as várias formas de escapes que são permitidas, incluindo:

  • Escapes hexadecimais (%nn).

  • Escapes de Unicode (%nnn).

  • Sequências de escape UTF-8 excessivamente longas (%nn%nn).

  • Fugas duplas (%nn torna-se %mmnn, onde %mm é a fuga para '%').

• Desconfie de nomes de usuário que possam ter mais de um formato canônico. Por exemplo, muitas vezes você pode usar o formulário MYDOMAIN\username ou o formulário username@mydomain.example.com.

Ver também

• Diretrizes de codificação segura
• Segurança ASP.NET Core