Se protéger contre l'injection SQL

[Ekilio]

Je suis en train de rédiger un tutorial sur le casting et les types. Après, ta remarque est tout à fait juste ; mais elle présente une faille, c'est que indiquer qu'un point est problématique c'est donner un indice à un éventuel pirate.

C'est un cas précis où il faut comparer la sécurité et la performance ; mais si un pirate voit qu'il y a une erreur chaque fois qu'il tente de transformer un paramètre pour que ce ne soit plus un entier, il n'aura pas la même réaction que lorsqu'il ne note pas d'erreur (chaque erreur étant un indice lorsqu'on cherche à pirater un site web).

On pourra me répondre (avec raison) que c'est pousser la paranoïa un peu loin ; je l'admet et je l'assume totalement. C'est juste que j'ai l'habitude de raisonner d'abord au terme de minimorceau de sécurité avant de raisonner en terme de performance.

Pour la différence entre intval() et (int) $variable, je cherche depuis quelques temps un benchmark sur ça, et je pense que je vais finir par le faire moi-même ; en attendant, je préfere (mais là encore c'est vraiment quelque chose de personnel) intval() que je trouve plus naturel à écrire en php que (int). D'autant plus que certains éditeurs (comme la chose infame que j'utilisait il y a quelques années) ne supportent pas (int) en php. Mais comme je le disais, c'est vraiment personnel à ce niveau-là et (int) serait tout aussi, voir plus, adapté.

Edit : Je viens de faire un benchmark, et effectivement, (int) est presque deux fois plus rapide que intval() (Pour 10000 itérations, 0.0065 seconde pour intval contre 0.0036 pour (int)). Donc effectivement, (int) est plus interessant et plus adapté.

[Sephi-Chan]

Merci beaucoup pour cette contribution, Ekilio ! J'ai déplacé ton article dans Développement > Ressources. Le lien direct vers ce dernier : Le typage en PHP.


Sephi-Chan

[Anthor]

Je suis en train de rédiger un tutorial sur le casting et les types. Après, ta remarque est tout à fait juste ; mais elle présente une faille, c'est que indiquer qu'un point est problématique c'est donner un indice à un éventuel pirate.

C'est un cas précis où il faut comparer la sécurité et la performance ; mais si un pirate voit qu'il y a une erreur chaque fois qu'il tente de transformer un paramètre pour que ce ne soit plus un entier, il n'aura pas la même réaction que lorsqu'il ne note pas d'erreur (chaque erreur étant un indice lorsqu'on cherche à pirater un site web).

On pourra me répondre (avec raison) que c'est pousser la paranoïa un peu loin ; je l'admet et je l'assume totalement. C'est juste que j'ai l'habitude de raisonner d'abord au terme de minimorceau de sécurité avant de raisonner en terme de performance.

Lancer une erreur ne veut pas dire l'afficher. Les classes d'exception permettent facilement d'afficher une page d'erreur tout en mailant la vraie erreur pour l'administrateur.

Parce que typer une chaine donne souvent 0, il est inutile de lancer la requête sur l'id 0. Voir même avec une chaine en typant un entier, je peux modifier un identifiant aléatoire suivant la chaine, par exemple "3 chiens" donne "3"...

En gros :

Code PHP :

<?php 

$id = "3 petits chiens";

'SELECT * FROM table WHERE id = ' . (int) $id 

[Ekilio]

Pas d'accord. Le typage sert à la sécurité, et je redonne l'exemple cité plus haut et le tien :

Code PHP :

<?php 

$id = "0 OR 1 = 1";

'SELECT * FROM table WHERE id = ' . $id 

[Anthor]

Je répondais à l'exemple de Sephi, la vérification doit se faire avant l'envoi de la requête. Pas sur la requête.
Le typage seul ne suffit pas.

D'ailleurs il existe de très bon plugins pour tester tout ça
http://securitycompass.com/exploitme.shtml

Code PHP :

<?php 

$id = "0 OR 1 = 1";

'SELECT * FROM table WHERE id = ' . $id 

[pascal]

Personnellement, j'utilise un framework qui gère tout ça :
- chaque donnée posséde un validateur
- chaque donnée a une portée : peut-elle être modifiée par l'utilisateur ?
- chaque donnée est filtrée par le framework

Les frameworks ont ça de bon : permettre de se consacrer à des questions plus haut niveau (conception ...) par opposition à la réécriture systèmatique de classes techniques.

A+

Pascal

[Ekilio]

Certes, mais dans ce cas, un autre exemple des dangers du non-typage :

Code PHP :

<?php 

$id = '0; DROP TABLE table';

'SELECT * FROM table WHERE id = ' . $id; 

[Sephi-Chan]

Désolé d'être un peu sec, mais toutes ces considération n'ont même pas lieu d'être.

Les bonnes pratiques du développement et de la sécurité veulent qu'on valide d'abord les données puis qu'on les utilises une fois qu'elles sont garanties fiables. Ça règle le problème des trous de sécurité et c'est propre.

Tout comme Pascal, j'utilise un framework (Zend Framework en ce moment) qui fait ça pour moi, je n'ai donc à coder que mon application, pas à m'occuper de ces problèmes bassement techniques qui ont déjà été vu et revus par beaucoup des gens dont c'est le métier. C'est bien plus sécurisant que de tout faire soi-même.


Sephi-Chan

[Anthor]

Certes, mais dans ce cas, un autre exemple des dangers du non-typage :

Code PHP :

<?php 

$id = '0; DROP TABLE table';

'SELECT * FROM table WHERE id = ' . $id; 

[Plume]

Même sans framework, tu peux pas faire ça chez moi. J'aurai -comme tout le monde ici présent- plutôt tendance à faire ça :

Code PHP :

<?php

$id = '0; DROP TABLE table';



$intId = mysql_real_escape_string($id);

'SELECT * FROM table WHERE id = ' . $intId . ';';