Htmlentities vs addslashes vs mysqli_real_escape_string

Question

Eu tenho feito algumas leituras sobre segurança de aplicações PHP, e parece-me que mysqli_real_escape_string é a função correta para usar quando inserir dados em tabelas MySQL porque addslashes pode causar algumas coisas estranhas aconteçam para um atacante inteligente. Certo?

No entanto, há uma coisa que está me confundindo. Eu me lembro a ser aconselhados addslashes é melhor do que htmlentities quando ecoando dados inseridos pelo usuário de volta para os usuários para proteger seus dados, mas parece que addslashes é o único com a vulnerabilidade. Isso é verdade, ou eu estou lembrando de forma incorrecta?

Answer 1

Existem diferentes contextos para seus dados. O contexto de inserção de dados sobre as necessidades de banco de dados a ser escapou de forma diferente do que o contexto de renderização de HTML / xml ou mesmo uma mensagem de email.

Escaping dados indo para um db deve ser preterido em todos os novos códigos em favor de declarações preparadas. Qualquer um que diga o contrário está fazendo um grande desserviço.

Escapando dados que vão para o navegador precisa ser escapou em uma série de maneiras diferentes, dependendo do alvo. Às vezes htmlspecialchars é suficiente, às vezes você precisa usar htmlentities. Às vezes você precisa entidades numéricas. É um assunto que você deve fazer alguma pesquisa para saber todas as nuances.

A regra geral, vivo-é validate (não filtro, rejeitar se incorreta) de entrada e saída de escape (com base no contexto).

Answer 2

Eles são ferramentas diferentes para diferentes fins.

mysqli_real_escape_string marcas de dados seguros para inserir no MySQL (mas consultas parametrizadas são melhores).

htmlentities torna segura de dados para a saída em um documento HTML

addslashes torna segura de dados para algumas outras situações, mas é insuficiente para MySQL

Answer 3

Você também pode usar o DOP libs que faz a maioria do escape para você, caso você pode usar PHP5 nos servidores.

Em ecoando Eu pessoalmente prefiro htmlspecialchars, mas pode me corrigir

Answer 4

Sim, use o mysqli_real_escape_string ou uma biblioteca como DOP em todos os entrada do usuário. Quando ecoando de volta, eu usar htmlentities com ENT_QUOTES como o segundo parâmetro, pois ele escapa todos os caracteres aplicáveis ??às suas entidades html, incluindo citações.

Answer 5

Nota: A utilização htmlentities () em um documento codificado UTF-8 deve ser evitado. Veja:

• interface com sistemas usando outros Charsets
• Áreas problema comum com UTF-8

Preste atenção (citou phpwact.org ):

Com os navegadores modernos e widespead suporte para UTF-8, você não precisa htmlentities porque todos estes caracteres pode ser representada directamente em UTF-8. Mais importante, em geral, apenas navegadores de suporte HTML caracteres especiais - um texto normal editor, por exemplo, não tem conhecimento de entidades HTML. Dependendo do que você está fazendo, usando htmlentities pode reduzir a capacidade de outros sistemas para “Consumir” o seu conteúdo.

Além disso (não confirmado, mas sons razoável - de comentário Anon aqui), entidades de caracteres (coisas assim »ou -) não funcionam quando um documento é servido como application / xml + xhtml (a menos que você defini-los). Você ainda pode sair com a forma numérica embora.

Answer 6

Outra solução interessante para PHP 5.2 e acima é usar a extensão do filtro: http://www.php.net/manual/en/book.filter.php

Ele permite que você para validar e entradas do usuário sanitize. Há muitos built-in filtros disponíveis e podem ser combinadas com as bandeiras de ajustar seu comportamento. Além disso filtros stas também pode ser usado para validar / higienizar ints, carros alegóricos, e-mails, expressões regulares específicos.

Eu, pessoalmente, ter começado a usá-los em meus projetos para formas validar e aos dados inseridos pelo usuário de saída, e estou muito feliz que eu fiz. Embora, quando eu inserir valores em um banco de dados MySQL, eu uso consultas preparadas para maior segurança. Estas soluções em conjunto pode ajudar a evitar a maioria das injeções de SQL e ataques XSS do tipo.

Answer 7

Você não pode ter um "escape" função e esperar que ele funcione o tempo todo. Existem diferentes ataques que requerem rotinas de saneamento específicos. A única maneira de entender esse conceito é escrever algum código vulnerável e, em seguida, explorá-la. Escrevendo código de exploração é vital para a compreensão de qualquer sistema de segurança.

Por exemplo esta consulta é vulnerável a injeção de SQL:

$host=htmlspecialchars($_GET[host],ENT_QUOTES);
$name=htmlspecialchars($_GET[name],ENT_QUOTES);
mysql_query("select * from user where Host='$host' and Name='$name' ");

Exploit: http:? //localhost/sqli_test.php host = \ & name =% 20sleep (20) - -% 201

A melhor função de escape para MySQL é mysqli_real_escape_string (), mas isso pode falhar:

mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id]));

explorar: http:? //localhost/sqli_test.php id = 1% 20or% 20sleep (20)

Na verdade, a melhor maneira de cuidar de injeção de SQL não está chamando uma função de escape, Seus usando quires parametrizadas de ADODB para injeção de SQL. Use htmlspecialcahrs ($ var, ENT_QUTOES) para XSS. Leia a OWASP top 10 porque há muito mais do que pode dar errado com web segurança do aplicativo.