SQL Injection

[fddsantos]

Boa tarde pessoal,

Gostava de fazer esta pergunta, Como posso combater os ataques de sql injection?

Obrigado pela atenção,

Fábio Santos

[Rui Carlos]

Penso que a solução mais eficaz passa por usar prepared statements: http://php.net/manual/en/book.pdo.php

Tens também algumas informações adicionais aqui: http://php.net/manual/en/security.database.sql-injection.php#security.database.avoiding

[mjamado]

Penso que a solução mais eficaz passa por usar prepared statements: http://php.net/manual/en/book.pdo.php

Não é a "mais eficaz", é a única que é eficaz (tirando não se usar SQL, de todo).

[MoshMage]

mysql_real_escape_string e mysqli_real_escape_string são as funções que tu procuras.

[FN9]

mysql_real_escape_string e mysqli_real_escape_string são as funções que tu procuras.

Aconselho a usar PDO. Estas funções não são 100% seguras

Edited July 24, 2012 by FN9

[MoshMage]

Aconselho a usar PDO. Estas funções não são 100% seguras

Erm.. é certo que fui vago; mas tu também podias elaborar x)

Tive agora no SO e aqui explica o "porque"; No entanto.. também existe um mysqli::prepare() portanto... qual é a grande diferença?

(é uma duvida legal, só agora é que li sobre PDO - ando a fazer a minha transação para OOP aos poucos)

[mjamado]

No entanto.. também existe um mysqli::prepare() portanto... qual é a grande diferença?

Desde que uses prepared statements, como o Rui Carlos disse lá atrás, é a mesma coisa; a única diferença é que PDO é multi-motor, enquanto do MySQLi é só para esse motor. Se tiveres a certeza absoluta que o motor de DB não vai mudar ao longo do ciclo de vida do projecto, podes usar a extensão específica do motor; senão, usa PDO, que é mais fácil mudar de motor mais tarde.

[MoshMage]

Desde que uses prepared statements, como o Rui Carlos disse lá atrás, é a mesma coisa; a única diferença é que PDO é multi-motor, enquanto do MySQLi é só para esse motor. Se tiveres a certeza absoluta que o motor de DB não vai mudar ao longo do ciclo de vida do projecto, podes usar a extensão específica do motor; senão, usa PDO, que é mais fácil mudar de motor mais tarde.

Ah! Por momentos temi pela minha protecção contra SQL Injection (se bem que ainda nao actualizei para o prepared statements)

Obrigado 🙂

[brunoais]

@mjamado

O uso do cast (int, float, etc... mas não string (n sei se há mais nesta categoria)) tb torna o dado completamente seguro para meter na DB.

Claro que estes que indiquei é limitado a números

Edited July 26, 2012 by brunoais

[mjamado]

Claro que estes que indiquei é limitado a números

Generalidades vs. especificidades.

[yoda]

Claro que estes que indiquei é limitado a números

Para quem precisar :

return (is_int($string) && $string >= 0) || ctype_digit($string);

Edited July 26, 2012 by yoda

[brunoais]

Para quem precisar :

return (is_int($string) && $string >= 0) || ctype_digit($string);

Pq a parte:

$string >= 0

?

De qq modo, eu n uso isso.

Se se trata de dados que eu estou à espera que seja exclusivamente números inteiros uso diretamente o cast.

Edited July 27, 2012 by brunoais

[yoda]

Pq a parte:

$string >= 0

?

De qq modo, eu n uso isso.

Se se trata de dados que eu estou à espera que seja exclusivamente números inteiros uso diretamente o cast.

Essa parte ficou a mais, não reparei. Uso-a porque é bastante comum usar essa condição para verificar ID's.

Quando trabalhas com comandos que são inseridos pelo utilizador é melhor filtrar bem o input e condicionar o uso da aplicação àquilo que é o seu propósito, caso contrário torna-se mais fácil sofrer um ataque no site.

[taviroquai]

Se o input for inválido (basta um parametro invalído), se possível, a aplicação nem devia chegar a efectuar a ligação à base de dados e devolver logo o erro, tentando efectuar o minimo de instruções, incluir o mínimo de ficheiros e consumir o minimo de recursos do sistema... mas nem sempre é possivel...