[Resolvido] mysql_scape_string é seguro ?

[André Severino 3]

Boa noite pessoal, uma dúvida que me surgiu ao acaso, utilizar o mysql_scape_string(não sei se está escrito certo) nos campos dos formulários de cadastro e login é seguro?? Ou é melhor utilizar uma função de anti sql-injection?

Se alguém souber de outro metódo para proteger um sistema me avisem para eu poder pesquisar pelo termo.

 

obrigado e aguardo sugestões

 

^_^

[falcao544 11]

Ele é seguro sim, mas não é só ele que vai protejer seu sistema contra SQL Injection!

[Matheus Tavares 167]

De forma alguma.

Utilize uma função bem complementada de Anti SQL-Injection. Vou te passar a minha:

 

function noinject ($string,$usa_bd=true,$retira_html=true,$retira_espacos=true) {
	$blacklist = array('/[\'"]/');
	$whitelist = array('"');
	if ($usa_bd) {
		$blacklist[] = '/(drop|insert|select|database|from|where|table|DROP|INSERT|SELECT|DATABASE|FROM|WHERE|TABLE)/';
		$whitelist[] = '';
	}
	if ($retira_html) {
		$blacklist[] = '/<[^>]*>/';
		$whitelist[] = '';
	}
	$string = $retira_espacos ? trim($string) : $string;
	return preg_replace($blacklist,$whitelist,$string);
}

Porém existem muitas outras, como a do Igor Escobar:

 

function noinject($Target){
	    $sanitizeRules = array('OR','FROM','SELECT','INSERT','DELETE','WHERE','DROP TABLE','SHOW TABLES','*','--','=');
	    foreach($Target as $key => $value):
	        if(is_array($value)): $arraSanitized[$key] = _antiSqlInjection($value);
	        else:
	            $arraSanitized[$key] = (!get_magic_quotes_gpc()) ? addslashes(str_ireplace($sanitizeRules,"",$value)) : str_ireplace($sanitizeRules,"",$value);
	        endif;
	    endforeach;
	    return $arraSanitized;
}

Acho que tudo depende de onde está sendo aplicado.

 

Modo de uso de ambas:

 

<?php
echo noinject($string);
?>

Até mais

[Henrique Barcelos 290]

Ele é seguro sim, mas não é só ele que vai protejer seu sistema contra SQL Injection!

 

Devagar aí... proteje sim...

 

Esse método noinject apresentado aí é TOTALMENTE desnecessário com MySQL. Por quê?

 

Simplesmente porque o MySQL na versão atual não tem suporte a queries múltiplas, ou seja, se o cara tentar:

 

SELECT * FROM tabela WHERE campo = DELETE * FROM tabela

Não vai acontecer NADA, isso mesmo, NADA!

 

O SQL Injection possível com MySQL é o famoso e manjado 'OR 1=1'.

 

Você faz uma query +/- assim para um login:

 

SELECT * FROM users WHERE user = '$user' AND password = '$password'

Se o cara tentar o injection que falei, sua query ficaria assim:

SELECT * FROM users WHERE user = '' OR 1=1 '' AND password = '$password'

Ou seja, o cara vai acessar o sistema.

 

Para impedir isso, é só escapar aspas e outros caracteres, justamente a finalidade da função mysql_real_escape_string.

 

Dor de cabeça à toa se preocupar com isso aí viu...

[Matheus Tavares 167]

PHP: mysql_escape_string

"This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged."

 

Concordo com suas palavras, em partes. Por que não criar uma função que bloqueia todos os itens que POSSIVELMENTE causariam danos ao sistema? Nem sempre estamos falando de um servidor atualizado, com rotinas decentes de segurança, magic quotes, e outras prevenções.

 

Acredito também que há um grande tumulto em cima disso à toa, porém devemos nos precaver de possíveis falhas. A função anti Injection, independentemente de qual for, deve apresentar solução para possíveis explorações à variáveis originadas através de áreas de contato com o usuário final. Nela, podemos colocar quaisquer funções. Para retirar html, aspas, underline (apenas um exemplo), o que for para preservar a integridade do sistema. Estas funções eu dei apenas como exemplo, e ainda afirmei a presença de muitas outras.

 

Resumindo: Na minha opinião, anti-injection não é uma função específica, e sim uma rotina contra a exploração de diretrizes sensíveis do sistema, onde nela podemos bloquear não apenas dados para o SQL, mas para outras areas do mesmo.

 

Até mais.

[Henrique Barcelos 290]

Na verdade, eu uso a extenção MySQLi que também implementa essa função.

No modo procedural é:

mysqli_real_escape_string($string, $connector)

Mas na boa, eu acho totalmente desnecessário tanta preocupação.

No mais, o que você precisa é um strip_tags ou um html_special_chars pra impedir o cara de escrever um html no registro e zuar a página.

[André D. Molin 15]

mas não é só ele que vai protejer seu sistema contra SQL Injection!

Vai sim. É como o Mario disse uma vez aqui no fórum, "o importante é "evitar que a agulha penetre na veia". conseguindo isso não precisa se preocupar com o "conteúdo da seringa".".

*_real_escape_string() evita que a agulha entre na veia.

 

Utilize uma função bem complementada de Anti SQL-Injection. Vou te passar a minha:

O seu argumento vai de encontro com o que acabei de dizer. Impeça apenas que a agulha entre na veia, não importando o conteúdo da mesma. Se você remove palavras do texto do usuário só porque esse texto contém as keywords do mysql, ele poderá ficar sem nexo, sem sentido, justamente pelas palavras que removeu.

Já pensou se o iMasters usasse esse metodo? Ninguem poderia escrever DROP, DELETE...

 

Simplesmente porque o MySQL na versão atual não tem suporte a queries múltiplas, ou seja, se o cara tentar:

Suporta sim, você está confundindo. Quem NÃO SUPORTA multiplas consultas é o PHP (mysql_query()). Se você quer executar multiplas consultas do MySQL pelo PHP, use http://php.net/manual/en/mysqli.multi-query.php.

 

Para retirar html, aspas, underline (apenas um exemplo), o que for para preservar a integridade do sistema.

E a integridade do usuário, onde fica? Você NUNCA deve penalizar o usuário pela atitude de outros, mas isso não quer dizer que você deva CONFIAR neles.

 

----------------

 

Resumindo: impeça que a seringa chege a veia, *_real_escape_string() faz isso ao inserir dados ao banco, stripslashes() "reverte o efeito" de *_real_escape_string(), htmlentities() tranforma os devidos caracteres de uma string em sua entidade html, sendo renderizado o seu valor LITERAL pelo navegador.

[Matheus Tavares 167]

Boa resposta, concordo; porém dentre todas as citações que tu fizeste, deverias ter prestado atenção nesta: "A função anti Injection, independentemente de qual for, deve apresentar solução para possíveis explorações à variáveis originadas através de áreas de contato com o usuário final.".

 

O que eu quis dizer com isso é que, independentemente da solução final, uma UNICA função anti injection com todas as possiveis soluções, é o melhor. Como e onde você aplicará é o que muda o contexto por completo.

 

Por exemplo: Conhece alguém chamado DELETE? Pois eu não. Nesse caso, se a função anti injection apresenta bloqueio contra isso, ótimo, é uma prevenção.

 

Reumindo, concordo com suas palavras, porém não concordo em ficar usando várias funções diferentes para a mesma solução, se podemos agrupar todas em uma, mudando apenas seus parâmetros.

 

Até mais.

[Henrique Barcelos 290]

Já tentou fazer algo do tipo:

SELECT * FROM usuarios WHERE user_name = (SELECT * FROM usuarios_permitidos)

Nunca consegui fazer funcionar... E sim, eu sei que tem outro jeito de fazer.

 

Outro exemplo que não funciona é:

SELECT *, (SELECT * FROM mensagens m WHERE u.id_usuario = m.id_usuario) AS mensagens FROM usuarios u

Como a outra query retorna mais de uma linha, não é possível fazê-la.

Aí no caso tem que usar um JOIN, mas seria mais 'claro' se pudéssemos fazer desse jeito.

 

A função multi_query permite você executar várias queries em separado, separando-as com ';', mas não fazer como eu falei:

http://php.net/manua...multi-query.php

[Matheus Tavares 167]

Veja a Query que fiz ontem para um script simples de helpdesk.

 

SELECT
		`m`.`titulo` as `titulo`,
		`m`.`mensagem` as `mensagem`,
		`m`.`data` as `data`,
		`u`.`usuarios_nivel` as `nivel`,
		`u`.`usuarios_nome` as `nome`,
		`u`.`usuarios_email` as `email`
	FROM (SELECT `m`.`topico`,`titulo`,`m`.`mensagem`,`m`.`data`,`m`.`usuario` FROM `mensagens` as `m` ORDER BY data DESC) AS `m`
	INNER JOIN `usuarios` as `u` ON
		`u`.`usuarios_id` = `m`.`usuario`
	WHERE
		`m`.`usuario` = '.SESSIONID.' OR
		'.U_NIVEL.' > 1
	GROUP BY `m`.`topico`
	ORDER BY `m`.`data` DESC

É uma query comum (só para exemplificar).

[Henrique Barcelos 290]

Mas veja, isso é UMA query só, apesar de ser gigantesca.

[Matheus Tavares 167]

Isso é indiferente, e também existem métodos como UNION, que permitem a formação de união de querys.

Mas, acho que a dúvida do amigo lá de cima já pôde ser esclarecida e eu já dei minha opinião.

 

Até mais.

[André D. Molin 15]

A função multi_query permite você executar várias queries em separado, separando-as com ';', mas não fazer como eu falei:

Ahhhh bom, o que você estava tentando dizer se chama SUBQUERY, ou consulta dentro de uma consulta. Veja que na sua mensagem lá em cima você disse "queries múltiplas" e não subquery :).

 

http://dev.mysql.com/doc/refman/4.1/pt/subqueries.html

 

usando várias funções diferentes para a mesma solução, se podemos agrupar todas em uma, mudando apenas seus parâmetros

Poderia me mostrar onde eu disse "várias funções diferentes para a mesma solução"? Não me lembro disso rs.

[Matheus Tavares 167]

Resumindo: impeça que a seringa chege a veia, *_real_escape_string() faz isso ao inserir dados ao banco, stripslashes() "reverte o efeito" de *_real_escape_string(), htmlentities() tranforma os devidos caracteres de uma string em sua entidade html, sendo renderizado o seu valor LITERAL pelo navegador.

[André D. Molin 15]

Bom hehe, talvez tenha lido com pressa o que eu disse.

 

O que eu quis dizer é que existem diversas funções que te ajudam em diversas ETAPAS do projeto. real_escape_string() te ajuda na hora escapar uma string ANTES de joga-la numa consulta, seja ela INSERT, UPDATE, DELETE, ...

stripslashes(), como eu mesmo disse, reverte o efeito de real_escape_string(). Afinal nem você e nem o usuário vai querer ter um texto cheio de barras invertidas né.

E htmlentities te ajuda a mostrar o valor literal de um texto. O usuário pode colocar tags html, javascript, php no meio de seu texto. E htmlentities vai transformar isso tudo em algo que seja literal ao navegador.

 

Enfim, deu pra perceber que não estou citando "várias funções diferentes para a mesma solução"? Cada uma age no momento certo.

[André Severino 3]

Opa pessoal, obrigado pela ajuda, hahaaha ficou um pouco maior do que o esperado em relação ao tamanho do tópico então + tarde eu leio com calma

 

abraços e até mais