Quando é melhor higienizar a entrada do usuário?

https://stackoverflow.com/questions/34896

09-06-2019
|

Pergunta

Usuário é igual a não confiável.Nunca confie em informações de usuários não confiáveis.Entendi.No entanto, estou me perguntando qual é o melhor momento para higienizar a entrada.Por exemplo, você armazena cegamente a entrada do usuário e depois a limpa sempre que é acessada/usada, ou você limpa a entrada imediatamente e depois armazena essa versão "limpa"?Talvez existam também outras abordagens que eu não tenha pensado além dessas.Estou mais inclinado para o primeiro método, porque quaisquer dados provenientes da entrada do usuário ainda devem ser abordados com cautela, onde os dados "limpos" ainda podem ser perigosos, inadvertidamente ou acidentalmente.De qualquer forma, que método as pessoas consideram melhor e por que razões?

Solução

Gosto de higienizá-lo o mais cedo possível, o que significa que a higienização acontece quando o usuário tenta inserir dados inválidos.Se houver um TextBox para a idade deles e eles digitarem qualquer coisa que não seja um número, não deixo o pressionamento da tecla da letra passar.

Então, o que quer que esteja lendo os dados (geralmente um servidor), eu faço uma verificação de integridade quando leio os dados, apenas para ter certeza de que nada escapa devido a um usuário mais determinado (como editar arquivos manualmente ou até mesmo modificar pacotes !)

Editar:No geral, higienize cedo e sempre que você perder os dados de vista, mesmo que por um segundo (por exemplo,Salvar arquivo -> Abrir arquivo)

Outras dicas

Infelizmente, quase nenhum dos participantes entende claramente do que estão falando.Literalmente.Apenas @Kibbee conseguiu esclarecer as coisas.

Este tópico é sobre higienização.Mas a verdade é que algo como a "higienização de uso geral" sobre a qual todos estão tão ansiosos para falar é simplesmente não existe.

Há um zilhão de mídias diferentes, cada um exige é uma formatação de dados própria e distinta. Além disso - mesmo uma única mídia requer formatação diferente para suas partes.Digamos que a formatação HTML é inútil para javascript incorporado na página HTML.Ou a formatação de string é inútil para os números na consulta SQL.

Na verdade, tal "higienização o mais cedo possível", como sugerido na maioria das respostas votadas, é apenas impossível.Como simplesmente não se pode dizer em que determinado meio ou parte do meio os dados serão utilizados.Digamos, estamos nos preparando para nos defender da "injeção de sql", escapando de tudo que se move.Mas opa!- alguns campos obrigatórios não foram preenchidos e temos que preencher os dados novamente no formulário em vez do banco de dados...com todas as barras adicionadas.

Por outro lado, escapamos diligentemente de todas as "entradas do usuário"...mas na consulta sql não temos aspas, pois é um número ou identificador.E nenhuma “higienização” jamais nos ajudou.

Por outro lado - tudo bem, fizemos o nosso melhor para higienizar a terrível, indigna de confiança e desdenhada "entrada do usuário"...mas em algum processo interno usamos esses mesmos dados sem qualquer formatação (como já fizemos o nosso melhor!) - e opa!obtivemos injeção de segunda ordem em toda a sua glória.

Então, do ponto de vista do uso na vida real, a única maneira adequada seria

formatação, não qualquer "higienização"
logo antes de usar
de acordo com certas regras médias
e até mesmo seguir sub-regras exigidas para as diferentes partes deste meio.

Eu higienizo meus dados de usuário como Radu...

O primeiro lado do cliente usando o regex e assumindo o controle sobre a entrada de caracteres permitidos em determinados campos de formulário usando JavaScript ou jQuery vinculado a eventos, como Onchange ou OnBlur, que remove qualquer entrada proibida antes que possa ser enviada.Perceba, no entanto, que isso realmente só tem o efeito de informar esses usuários, que os dados também serão verificados no lado do servidor.É mais um aviso do que qualquer proteção real.
Segundo, e raramente vejo isso feito hoje em dia, que a primeira verificação que está sendo feita ao lado do servidor é verificar a localização de onde o formulário está sendo enviado.Ao permitir apenas o envio do formulário de uma página que você designou como um local válido, você pode matar o script antes mesmo de ler em qualquer dado.É verdade que isso é insuficiente, pois um bom hacker com seu próprio servidor pode 'falsificar' o domínio e o endereço IP para que ele pareça ao seu script que ele vem de um local de formulário válido.
Em seguida, e eu nem deveria ter que dizer isso, mas sempre, e quero dizer SEMPRE, execute seus scripts no modo de mancha.Isso obriga você a não ficar preguiçoso e a ser diligente com a etapa número 4.
Higilize os dados do usuário o mais rápido possível, usando regexes bem formados apropriados aos dados esperados de um determinado campo no formulário.Não tome atalhos como os infames 'chifre mágico do unicórnio' para passar por suas verificações de contaminação...Ou você também pode desligar a verificação de mancais em primeiro lugar para todo o bem que fará com a sua segurança.É como dar a um psicopata uma faca afiada, carregando sua garganta e dizendo 'você realmente não vai me machucar com isso, vai ".

E aqui é onde eu diferei da maioria dos outros nesta quarta etapa, pois apenas higienizo os dados do usuário que realmente usarei de uma maneira que possa apresentar um risco de segurança, como qualquer sistema chama, atribuições para outras variáveis ou Qualquer redação para armazenar dados.Se estou usando apenas a entrada de dados de um usuário para fazer uma comparação com os dados que eu mesmo armazenei no sistema (portanto, sabendo que os dados meus são seguros), então não me preocupo em higienizar os dados do usuário, como eu Nunca vou para nós de uma maneira que se apresenta como um problema de segurança.Por exemplo, tome uma entrada de nome de usuário como exemplo.Eu uso a entrada de nome de usuário pelo usuário apenas para verificar -o em uma correspondência no meu banco de dados e, se verdadeiro, depois de usar os dados do banco de dados para executar todas e nunca mais use os dados dos usuários novamente depois disso.
Por fim, é filtrar todas as tentativas de submissão automaticamente por robôs hoje em dia, com um sistema de 'autenticação humana', como o Captcha.Hoje em dia, isso é importante para escrever meu próprio esquema de 'autenticação humana' que usa fotos e uma entrada para o 'humano' entrar no que eles vêem na imagem.Fiz isso porque descobri que os sistemas do tipo Captcha realmente incomodam os usuários (você pode dizer pelos olhos apertados de seus olhos de tentar decifrar as cartas distorcidas ...geralmente repetidamente).Isso é especialmente importante para os scripts que usam o Sendmail ou o SMTP para email, pois são favoritos para seus spam famintos.

Para resumir, vou explicar como faço para minha esposa...Seu servidor é como uma boate popular e quanto mais seguranças você tiver, menos problemas você provavelmente terá na boate.Eu tenho dois seguranças do lado de fora da porta (validação do lado do cliente e autenticação humana), um segurança bem dentro da porta (verificando o local válido de envio do formulário...'É realmente você nesse id') e vários outros seguranças nas proximidades da porta (executando o modo mancha e usando boas regexes para verificar os dados do usuário).

Eu sei que este é um post antigo, mas achei importante o suficiente para que qualquer um que o leia depois da minha visita aqui perceba que não é 'bala mágica' quando se trata de segurança, e é necessário que todos trabalhem em conjunto para tornar seguros os dados fornecidos pelo usuário.Usar apenas um ou dois desses métodos é praticamente inútil, pois seu poder só existe quando todos se unem.

Ou em resumo, como minha mãe costumava dizer...'Melhor prevenir do que remediar".

ATUALIZAR:

Mais uma coisa que estou fazendo atualmente é codificar em Base64 todos os meus dados e, em seguida, criptografar os dados em Base64 que residirão em meus bancos de dados SQL.São necessários cerca de um terço a mais de bytes para armazená-los dessa maneira, mas, na minha opinião, os benefícios de segurança superam o tamanho extra dos dados.

Depende do tipo de higienização que você está fazendo.

Para proteção contra injeção de SQL, não faça nada com os dados em si.Basta usar instruções preparadas e, dessa forma, você não precisa se preocupar em mexer nos dados que o usuário inseriu e afetar negativamente sua lógica.Você tem que higienizar um pouco, para garantir que números são números e datas são datas, já que tudo é uma string conforme vem da solicitação, mas não tente fazer nenhuma verificação para fazer coisas como bloquear palavras-chave ou qualquer coisa.

Para proteção contra ataques XSS, provavelmente seria mais fácil corrigir os dados antes de serem armazenados.No entanto, como outros mencionaram, às vezes é bom ter uma cópia original exatamente do que o usuário digitou, porque uma vez alterado, ele será perdido para sempre.É quase uma pena que não exista uma maneira infalível de garantir que seu aplicativo apenas exiba HTML limpo, da mesma forma que você pode garantir que não será pego pela injeção de SQL usando consultas preparadas.

O mais importante é ser sempre consistente na hora de escapar.A dupla higienização acidental é ruim e não higienizar é perigoso.

Para SQL, apenas certifique-se de que sua biblioteca de acesso ao banco de dados suporta variáveis de ligação que escapam automaticamente dos valores.Qualquer pessoa que concatene manualmente a entrada do usuário em strings SQL deve saber melhor.

Para HTML, prefiro escapar no último momento possível.Se você destruir a entrada do usuário, nunca poderá recuperá-la e, se ele cometer um erro, poderá editá-la e corrigi-la mais tarde.Se você destruir a entrada original, ela desaparecerá para sempre.

Cedo é bom, definitivamente antes de você tentar analisá-lo.Qualquer coisa que você irá gerar posteriormente, ou especialmente passar para outros componentes (ou seja, shell, SQL, etc.) deve ser higienizado.

Mas não exagere - por exemplo, as senhas são criptografadas antes de serem armazenadas (certo?).As funções hash podem aceitar dados binários arbitrários.E você nunca imprimirá uma senha (certo?).Portanto, não analise senhas – e não as desinfete.

Além disso, certifique-se de fazer a limpeza a partir de um processo confiável - JavaScript/qualquer coisa do lado do cliente é pior do que segurança/integridade inútil.(No entanto, pode proporcionar uma melhor experiência ao usuário falhar antecipadamente - basta fazer isso nos dois lugares.)

Perl tem uma opção taint que considera todas as entradas do usuário "contaminadas" até que sejam verificadas com uma expressão regular.Dados contaminados podem ser usados e repassados, mas contaminam todos os dados com os quais entram em contato até ficarem imaculados.Por exemplo, se a entrada do usuário for anexada a outra string, a nova string também será contaminada.Basicamente, qualquer expressão que contenha valores corrompidos produzirá um resultado corrompido.

Dados contaminados podem ser lançados à vontade (dados contaminados à medida que avançam), mas assim que são usados por um comando que tem efeito no mundo externo, o script perl falha.Portanto, se eu usar dados corrompidos para criar um arquivo, construir um comando shell, alterar o diretório de trabalho, etc., o Perl falhará com um erro de segurança.

Não conheço outra linguagem que tenha algo como "mácula", mas usá-la tem sido muito revelador.É incrível a rapidez com que os dados corrompidos se espalham se você não os limpar imediatamente.Coisas tão naturais e normais para um programador, como definir uma variável com base nos dados do usuário ou abrir um arquivo, parecem perigosas e arriscadas com a contaminação ativada.Portanto, a melhor estratégia para fazer as coisas é limpar assim que você obtiver alguns dados externos.

E suspeito que essa seja a melhor maneira também em outros idiomas:valide os dados do usuário imediatamente para que bugs e falhas de segurança não possam se propagar muito.Além disso, deveria ser mais fácil auditar o código em busca de falhas de segurança se as falhas potenciais estivessem em um só lugar.E você nunca pode prever quais dados serão usados para qual finalidade posteriormente.

Minha opinião é higienizar a entrada do usuário o mais rápido possível do lado do cliente e do servidor, estou fazendo assim

(Lado do cliente), permita que o usuário insira apenas teclas específicas no campo.
(Lado do cliente), quando o usuário vai para o próximo campo usando o OnBlur, teste a entrada que ele inseriu contra um regexp e observe o usuário se algo não for bom.
(Lado do servidor), teste a entrada novamente, se o campo deve ser inteiro, verifique se isso (no PHP, você pode usar is_numeric ()), se o campo tiver um formato bem conhecido, verifique -o contra um regexp, todos os outros (como comentários de texto), Apenas escape deles.Se algo for suspeito, interrompa a execução do script e retorne um aviso ao usuário de que os dados inseridos são inválidos.

Se algo realmente parecer um ataque possível, o script envia um e-mail e um SMS para mim, para que eu possa verificar e evitar o mais rápido possível, só preciso verificar o log onde estou registrando todas as entradas do usuário, e as etapas que o script realizou antes de aceitar ou rejeitar a entrada.

Limpe os dados antes de armazená-los.Geralmente você não deveria estar se apresentando QUALQUER Ações SQL sem primeiro limpar a entrada.Você não quer se submeter a um ataque de injeção de SQL.

Eu meio que sigo essas regras básicas.

Faça apenas modificações de ações SQL, como INSERT, UPDATE, DELETE por meio de POST.Nunca pega.
Fuja de tudo.
Se você espera que a entrada do usuário seja algo, certifique-se de verificar se é algo assim.Por exemplo, você está solicitando um número e certifique-se de que seja um número.Use validações.
Use filtros.Limpe caracteres indesejados.

Os usuários são maus!

Bem, talvez nem sempre, mas minha abordagem é sempre higienizar imediatamente para garantir que nada de arriscado chegue perto do meu back-end.

O benefício adicional é que você pode fornecer feedback ao usuário se higienizar no ponto de entrada.

Suponha que todos os usuários sejam mal-intencionados.Limpe todas as entradas o mais rápido possível.Ponto final.

Eu higienizo meus dados antes de fazer qualquer processamento neles.Talvez seja necessário pegar os campos Nome e Sobrenome e concatená-los em um terceiro campo que é inserido no banco de dados.Vou higienizar a entrada antes mesmo de fazer a concatenação para não receber nenhum tipo de erro de processamento ou inserção.Quanto antes melhor.Mesmo usar Javascript no front-end (em uma configuração web) é ideal porque, para começar, isso ocorrerá sem que nenhum dado vá para o servidor.

A parte assustadora é que você também pode querer começar a higienizar os dados que saem do seu banco de dados.A recente onda de ataques de injeção de SQL ASPRox que tem ocorrido é duplamente letal porque infectará todas as tabelas de banco de dados em um determinado banco de dados.Se o seu banco de dados estiver hospedado em algum lugar onde há várias contas hospedadas no mesmo banco de dados, seus dados serão corrompidos devido ao erro de outra pessoa, mas agora você se juntou à categoria de hospedagem de malware para seus visitantes sem nenhuma falha inicial sua. .

Claro que isso dá muito trabalho inicial, mas se os dados forem críticos, então é um investimento que vale a pena.

Acho que limpá-lo imediatamente tem duas vantagens.Primeiro, você pode validar e fornecer feedback ao usuário.Segundo, você não precisa se preocupar em consumir os dados em outros lugares.

A entrada do usuário deve sempre ser tratada como maliciosa antes de chegar às camadas inferiores do seu aplicativo.Sempre lide com a entrada de sanitização o mais rápido possível e não deve, por nenhum motivo, ser armazenada em seu banco de dados antes de verificar se há intenções maliciosas.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow