Que tipo de entrada é menos vulnerável ao ataque?

Question

Que tipo de entrada é menos vulnerável a cross-site scripting (XSS) e SQL ataques de injeção.

PHP, HTML, BBCode, etc. Eu preciso saber de um fórum Estou ajudando um amigo configurado.

Answer 1

Precisamos saber mais sobre a sua situação. quão vulnerável? Algumas coisas que você deve sempre fazer:

• Fuga cordas antes de armazená-los em um banco de dados para proteger contra injeções de SQL
• HTML codificar cordas quando imprimi-los de volta para o usuário de uma fonte desconhecida, para evitar mal-intencionado html / javascript

Eu nunca iria executar php fornecido por um usuário. BBCode / UBBCode são bons, porque eles são convertidos para HTML semanticamente correta, embora você pode querer olhar para as vulnerabilidades XSS relacionados a tags de imagem malformados. Se você permitir a entrada HTML, você pode whitelist certos elementos, mas isso vai ser uma abordagem complicada que está propenso a erros. Assim, dado todo o anterior, eu diria que o uso de um bom off-the-shelf BBCode biblioteca seria sua melhor aposta.

Answer 2

(Eu só postou isso em um comentário, mas parece que algumas pessoas estão sob a impressão de que listas de seleção, botões de rádio, etc não precisa ser higienizado.)

Não conte com botões de rádio sendo seguro. Você ainda deve higienizar os dados no servidor. As pessoas podiam criar uma página HTML em sua máquina local, e fazer uma caixa de texto com o mesmo nome que o seu botão de rádio, e têm que os dados postados para trás.

Um usuário mais avançado poderia usar um proxy como WebScarab , e apenas ajustar os parâmetros de como eles são postados de volta para o servidor.

Uma boa regra de ouro é a sempre usar instruções SQL parametrizadas, e sempre de dados gerados por usuários de fuga antes de colocá-lo no HTML.

Answer 3

Nenhum deles é. Todos os dados que são esperados no servidor podem ser manipulados por aqueles com o conhecimento e motivação. O navegador e forma que você espera que as pessoas sejam usando é apenas uma das várias maneiras válidas para enviar dados ao seu servidor / script.

Por favor, se familiarizar com o tema de XSS e questões relacionadas

• http://shiflett.org/articles/input-filtering
• http://shiflett.org/blog/2007 / mar / permitindo-html-and-impedindo-XSS

Answer 4

Qualquer tipo de boolean.

Você pode até mesmo filtrar a entrada inválida com bastante facilidade.

; -)

Answer 5

Há muitos analisadores de código BB que limpar a entrada para HTML e assim por diante. Se não há um está disponível como um pacote, então você pode olhar para um dos pacotes de software de fórum de código aberto para orientação.

código BB faz sentido como é o "padrão" para fóruns.

Answer 6

A entrada que é o menos vulnerável ao ataque é o "não-entrada".

Você está pedindo a pergunta certa?

Answer 7

Por amor de Odin, por favor, não higienizar entradas. Não tenha medo de usuários de entrar o que quiserem em suas formas.

A entrada do usuário não é inerentemente inseguro. As respostas leads aceitou esses tipos de interfaces web como meus do banco, onde o Sr. O'Reilly não pode abrir uma conta, porque ele tem um caráter ilegal em seu nome. O que é seguro é sempre como você usa a entrada do usuário.

A maneira correta para evitar injeções SQL é usar declarações preparadas. Se a sua camada de abstração de banco de dados não permitem que você use os, use as funções escapando corretas rigorosamente (myslq_escape et al). A maneira correta para evitar ataques XSS não é algo como striptags (). Escapar tudo - em PHP, algo como htmlentities () é o que você está procurando, mas isso depende se você está outputing a string como parte de texto HTML, um atributo HTML, ou dentro de Javascript, etc. Use a ferramenta certa para o contexto certo. E nunca apenas imprimir a entrada do usuário diretamente para a página.

Finalmente, ter um olhar para as Top 10 vulnerabilidades das aplicações web, e fazer a coisa certa para impedi-los. http://www.applicure.com/blog/owasp-top-10-2010