SQL Injection

[cdfree 3]

Como evitar SQL Injection em minha aplicação, se tiver um exemplo de função para validar a consulta seria melhor.

[Maykel-ctba 233]

http://lmgtfy.com/?q=prevenir+sql+injection

[ESerra 744]

Simples: prepared statements

[Fabio Carpi 6]

Use a função mysql_real_escape_string

[ESerra 744]

 

Use a função mysql_real_escape_string

 

Nem todo sql injetction usa ' ou ", além do que as funções mysql_* já foram depreciadas, ou seja, vão sumir no futuro...

[Keven Jesus_164006 39]

depende amigo você ta recebendo um id direto ?

 

usa intval($_GET['id']);

 

e para evitar xss também mete use um strip_Tags

[Maykel-ctba 233]

Simples: prepared statements

 

 

Interessante isso! Dei uma lida sobre, fiquei curioso.

 

Estou sériamente pensando em como aplicar isso a um framework que estou desenvolvendo. Basicamente o que entendi é que a consulta terá um "template padrão" e apenas as variáveis que entrarão no banco de dados são indicadas. Procede? :innocent:

[ESerra 744]

Interessante isso! Dei uma lida sobre, fiquei curioso.

 

Estou sériamente pensando em como aplicar isso a um framework que estou desenvolvendo. Basicamente o que entendi é que a consulta terá um "template padrão" e apenas as variáveis que entrarão no banco de dados são indicadas. Procede? :innocent:

Vou explicar isso de uma forma "semi didática" (semi, porque não é exatamente assim na realidade). Quando você faz um sql injection você joga na query um comando qualquer. Quando isso chega no MySQL, primeiro ele pega o que você mandou e analisa se a sintaxe está correta, se estiver ele começa a ver exatamente o que você quer na query (select, insert, updata, where...etc). Quando você manda um prepared statement o que for jogado na query não será analisado pelo MySQL, se entrar um drop table lá pelo meio ele não vai "processar" o drop table, ele vai ignorar isto enquanto comando existente no sistema.

 

Uma analogia simples seria a seguinte:

 

<?php
$variavel = 'iMasters';
 
echo '$variavel'; //Imprime: $variavel -> Isso seria o equivalente ao prepared statements
 
echo $variavel; //Imprime: iMasters
?>

 

Como eu disse, na realidade não é assim internamente, mas apenas para exemplificar acho que quebra um galho.

[Enrico Pereira 299]

mysql_real_escape_string não é eficiente e não usem mysql_*, a partir do PHP 5.5 elas já lançam erro.

 

PDO + Prepared Statements e não tem erro:

<?php
$pdo = new PDO(/* dados de conexão*/);

$stmt = $pdo->prepare("INSERT INTO users (name, email, age) VALUES (:name, :email, :age)");
$stmt->bindParam(':name', $_POST['name'], PDO::PARAM_STR);
$stmt->bindParam(':email', $_POST['email'], PDO::PARAM_STR);
$stmt->bindParam(':age', $_POST['age'], PDO::PARAM_INT);
$stmt->execute();

 

É evidente que isso só protege SQL injection, ainda é necessário validar e proteger-se contra XSS e outros tipos de ataque.

[Raul Silva 41]

PDO manda bem...

Contra XSS e alguns outros tipos de ataques tem um FW bom para isso, o PHPIDS (http://phpids.org/), ele tem plugins para diversos frameworks (drupal, symfony, zend, etc).

[Enrico Pereira 299]

A melhor forma de fazer segurança é manualmente, não com essas ferramentas mágicas que no fim falham.

[Emanuel Douglas 0]

O BOM E SIMPLES E EFICIENTE É USAR UM MÉTODO DE PROIBIÇÃO DE ALGUNS CARACTERES ESPECIAIS E EXTENSÕES VIA GET E POST COMO

 

( ) - [ ] * ' " .TXT .HTACCESS ... ENTRE OUTROS.

 

UM BOM PROGRAMADOR DESCONFIA DE TUDO E DE TODOS EM SEU CÓDIGO PONHA REGRAS RÍGIDAS QUANTO A CONEXÃO

SERVER USUÁRIO , TENHA UM BOM TRABALHO :)

[ESerra 744]

O BOM E SIMPLES E EFICIENTE É USAR UM MÉTODO DE PROIBIÇÃO DE ALGUNS CARACTERES ESPECIAIS E EXTENSÕES VIA GET E POST COMO

 

( ) - [ ] * ' " .TXT .HTACCESS ... ENTRE OUTROS.

 

UM BOM PROGRAMADOR DESCONFIA DE TUDO E DE TODOS EM SEU CÓDIGO PONHA REGRAS RÍGIDAS QUANTO A CONEXÃO

SERVER USUÁRIO , TENHA UM BOM TRABALHO :)

 

Um bom programador com certeza não faz essa gambiarras ai...

[Enrico Pereira 299]

Proibição de caracteres é totalmente errado e atrapalha o usuário. Imagine que eu vá fazer um sistema para usuários postarem código e eu, visando evitar injeção de JavaScript, proibo a tag script, mas o usuário então não poderia postar a tag script no HTML que ele enviasse para ser publicado... FAIL.

 

O correto é escapar os caracteres para que não sejam interpretados pelo browser => htmlspecialchars.

[Raul Silva 41]

A melhor forma de fazer segurança é manualmente, não com essas ferramentas mágicas que no fim falham.

 

A ferramenta está lá para ser usada, eu posso não ter o conhecimento necessário para fazer algo desse nivel, essa ferramenta esta no mercado a vários anos. Porque eu não deveria usa-la?