[SQL] Quelles sont les requêtes SQL que l'on peut pirater ?

Bonjour,

Dans tous les exemples que j'ai lu sur le piratage par injection sql, c'était chaque fois des requêtes avec une clause WHERE qui étaient montrées en exemple.

Ne peut-on donc pirater que des requêtes SELECT ou UPDATE ?

As-tu lu les tutos du site sur la sécurité ?

Oui mais ce n'était pas ces points qui m'intéressaient à ce moment, donc je n'ai pas dû les retenir. Je vais les relire. Mais si quelqu'un a la réponse, qu'il ne se prive pas. Merci

Citation:

---

Envoyé par JackBeauregard

Oui mais ce n'était pas ces points qui m'intéressaient à ce moment, donc je n'ai pas dû les retenir. Je vais les relire. Mais si quelqu'un a la réponse, qu'il ne se prive pas. Merci

---

Il y a pas de requête plus sensible que d'autre pour le piratage c'est surtout ce qu'il est possible de faire. Un SELECT est sensible dans le sens ou il peut retourner des informations non prévus. Pour l'UPDATE, ou L'INSERT c'est l'inverse c'est à dire d'insérer des données non prévus qui va favorisé le pirate. Pour le DELETE c'est d'effacer des lignes qui n'était pas prévus au départ.

j'ajouterais que TOUTES les requetes sont potentiellement dangeureuses, mais le niveau de sécurité depend aussi des fonctionnalités offertes par la base de données.

Si tu as une base de données qui autorise le caractere ";" entre 2 requetes pour en executer plusieurs par exemple, n'importe qu'elle requete est TRES dangeureuse.

un exemple :
SELECT * FROM matable WHERE ID=$_GET['id']
je te laisse faire le remplacement si je m'amuse a mettre dans l'URL de la page :
?id=1;DROP TABLE matable

je t'invite fortement a lire les articles sur l'injection SQL disponibles ici

Merci pour vos réponses,

Bon alors j'ai lu cette page :
http://www.phpsecure.info/v2/article/InjSql.php

Moi je fais mes requêtes comme ça :

Code:

---

SELECT * FROM matable WHERE ID='.$id.'

---

Avant toute requête, si j'attend du numérique, je fais :

Code:

---

$id=intval($_GET['id'])

---

Donc là c'est incassable.

Par contre, si c'est une chaine de caractère, je ne vois pas quoi faire d'autre à part :

Code:

---

$chaine=mysql_real_escape_string($_GET['chaine])

---

En plus en général j'ajoute avant l'insertion un htmlspecialchars par dessus le mysql_real_escape_string (oui je sais c'est pas à faire avant, mais bon je fais comme ça jusqu'à la nuit des temps).

ce qui nous donne

Code:

---

$chaine= htmlspecialchars(mysql_real_escape_string($_GET['chaine'])

---

Et malgré tout je suis pas rassuré, je ne vois pas quoi faire d'autres, si ce n'est éventuellement détruire par un preg_match() certains mot comme 'WHERE' ou 'LIKE' ou '='.
Sans cela êtes vous certains que mysql_real_escape_string() est suffisant sur un champ texte pouvant contenir de tout ?

Citation:

---

Envoyé par JackBeauregard

Et malgré tout je suis pas rassuré, je ne vois pas quoi faire d'autres, si ce n'est éventuellement détruire par un preg_match() certains mot comme 'WHERE' ou 'LIKE' ou '='.

---

Pas besoin, vu que toutes les chaînes de caractères seront passées entre simple quotes, avec la certitude de ne pas avoir un quote qui traîne, grâce à mysql_real_escape_string. Tu peux avoir tous les WHERE que tu veux.

Si je te suis :

Code:

---

WHERE $id='.$id.'

---

est incassable (avec mysql_real_escape_string() avant)

Alors que

Citation:

---

WHERE $id=$id

---

est cassable même avant mysql_real_escape_string() avant.

On me l'a déjà dit, mais je n'ai toujours pas compris pourquoi une si petite différence permet de passer de l'insécurité à la sécurité "totale".

J'aime pas parler de sécurité totale... Je vais juste donner un exemple.

J'utilise la variable suivante :

Code:

---

$condition = 'test AND u=10';

---

avec simple quotes :

Code:

---

"SELECT t,u FROM table WHERE t='$condition'"

---

devient au passage à MySQL :

Code:

---

SELECT t,u FROM table WHERE t='test AND u=10'

---

MySQL recherchera les entrées où t vaut "test AND u=10"

sans simple quotes :

Code:

---

"SELECT t,u FROM table WHERE t=$condition"

---

devient au passage à MySQL :

Code:

---

SELECT t,u FROM table WHERE t=test AND u=10

---

MySQL recherchera les entrées où t vaut "test" et où u vaut "10". La requête a été modifiée.

c'est comme l'histoire des // pour passer la fin d'une requête comme commentaire ou un truc comme ça...

Bon alors les quotes plus le point autour de la variable passée en paramètre à la requête, le tout précédé par mysql_real_escape_string et on est tranquille pour tous les champs textarea, c'est ça ?

Bon faudrait accorder nos violons parce que sur ce post d'une discussion que j'avais ouverte (finalement presque identique, décidemment je suis pas rassuré), il n'est pas dit cela.
http://www.developpez.net/forums/sho...77&postcount=6

Donc je reprend.
Pour le moment je fais :

Code:

---

WHERE id='".$id."'

---

et Fladnag dans le post au dessus dis que comme ça c'est bon, mais qu'il faut surtout éviter :

Code:

---

WHERE id='.$id.'

---

Ce que je ne fais en fait pas, mais c'est de celà dont nous discutons ici.


Donc mettons nous d'accord, il en va de la survie de l'humanité.

Citation:

---

Envoyé par JackBeauregard

et Fladnag dans le post au dessus dis que comme ça c'est bon, mais qu'il faut surtout éviter :

Code:

---

WHERE id='.$id.'

---

Ce que je ne fais en fait pas, mais c'est de celà dont nous discutons ici.

---

Ben non. Faut lire attentivement.

Bon, revenons au debut :

Citation:

---

Envoyé par JackBeauregard

Dans tous les exemples que j'ai lu sur le piratage par injection sql, c'était chaque fois des requêtes avec une clause WHERE qui étaient montrées en exemple.

---

Non.

TOUTES les failles de sécurités en PHP (a part les bugs occasionnels de certaines fonctions, et encore) proviennent toutes d'une seule et meme source : LES ENTREES UTILISATEURS

Ton programme PHP peut etre assimilé a une boite avec des données en entrées et des choses produites en sorties.
Si ton programme n'a pas de bug, les choses produites en sorties seront toujours correctes (un traitement qui a échoué est considéré comme correct si l'erreur est tracée, eventuellement un administrateur prévenu, mais là je rentre déjà trop dans les détails)

Par contre, les données en entrées sont EXTREMEMENT SENSIBLES parce qu'elles arrivent a PHP sans aucun controle. C'est donc a toi de les controler et de faire en sorte qu'elles correspondent a ce que tu attends, qu'elles ne provoquent pas d'executions non voulues, etc...

tu parle de la clause WHERE ? ben c'est uniquement parce que *en général* c'est dans la clause WHERE qu'on trouve les $_GET et les $_POST. mais si tu t'amuse a faire un SHOW COLUMNS FROM $_GET['table'] c'est potentiellement aussi une faille de sécurité.

Voir meme, tant qu'on y est mysql_query($_GET['requete']); (mais là c'est flagrant que c'est dangeureux...)

C'est donc a toi de tester, verifier le type, convertir, échapper, et faire en sorte que toutes les entrées utilisateurs soit :
* Soit stoppées avant qu'elles ne provoquent un probleme
* Soit converties en données traitables normalement.

Apres, on entre trop dans les détails et c'est spécifique a chaque script PHP. addslashes, stripslashes, html_entities, mysql_real_escape_string, intval, oui, ces fonctions sont utiles... chaque fois que tu utilise une variable venant d'un utilisateur (et là je parle aussi bien de $_GET, $_POST, $_FILE que de $_COOKIE. $_SESSION est a part puisque sauf autre bug, l'utilisateur ne peux pas modifier directement les variables de session) demande toi ce qu'il se passe si il y a une apostrophe dedans, ou un guillemet, ou une balise html, ou un dollar (je pense a l'utilisation d'une fonction exec ou d'un preg_replace_callback), ou un slash (/) ou un antislash (\) et, dans CHAQUE cas, c'est a toi de trouver la fonction a utiliser pour rendre ton code sur. Il n'y a pas de fonction magique parce que la fonction a utiliser depend de ce que tu veux faire de ta variable ensuite (insertion dans une BDD, affichage, value d'un insert, etc...)

LE MOYEN LE PLUS SUR RESTE L'ANALYSE INTELLIGENTE DE TON CODE. C'est a dire reflechir a chaque utilisation sur les failles potentielles. Maintenant, personne est parfait, et on peut oublier des trucs. Si tu veux une formule magique, voici la mienne :

Code:

---

a'a"a/a\a<b>a</b>a<br>a$a

---

Utilise cette chaine dans TOUTES les entrées utilisateurs sur ton site (champs INPUT d'un formulaire, variable en GET dans l'url de la page, etc...)
Si tu n'a aucune erreur SQL qui remonte, aucun affichage QUE TU NE SOUHAITES PAS (si tu souhaite afficher le code html il est normal que <b> et <br> soit interprétés, sinon non) alors il y a des *chances* que ton site ne contienne pas de failles trop visibles.

D'autres questions ?

PS : la seule chose a savoir, c'est les risques possibles, si tu as lu les articles de phpsecure.info c'est deja un bon début, apres c'est a toi de te renseigner periodiquement sur la sécurité, car on peut, demain, trouver un type de faille inconnu jusqu'alors qui te demandera des controles supplémentaires sur ton site.

Bon, d'abord un grand merci pour cette réponse complète de Fladnag et l'attention d'Eusébius.

La question était en fait plus simple :

Pour sécuriser correctement une requête, on fait :

Code:

---

WHERE $id='".$id."'

---

ou

Code:

---

WHERE $id='.$id.'

---

Avec bien sûr dans les deux cas auparavant mysql_real_escape_string() .

Normalement c'est la première solution.

Citation:

---

Envoyé par Fladnag

LE MOYEN LE PLUS SUR RESTE L'ANALYSE INTELLIGENTE DE TON CODE. C'est a dire reflechir a chaque utilisation sur les failles potentielles. Maintenant, personne est parfait, et on peut oublier des trucs. Si tu veux une formule magique, voici la mienne :

Code:

---

a'a"a/a\a<b>a</b>a<br>a$a

---

---

Auto citation

Si tu n'est pas capable de répondre TOI MEME a ta question avec mon précédent message, je crois que tu devrais laisser la sécurité de ton site entre d'autres mains ;o)

Mais qui a donné 5 étoiles à ce sujet ?!

Bonjour,

J'ai testé sur certains de mes inputs de formulaire avec

Code:

---

a'a"a/a\a<b>a</b>a<br>a$a

---

et il me met une erreur de requête ce qui veut dire si j'ai bien compris ce poste , que je ne suis pas sécurisé et qu'il y a des failles.

Cela ne m'arrive que sur les formulaire de recherche de données, j'en ai peu heureusement.

Pour contrôlé, j'ai fait ceci :

Code:

---

1 2 3 4 5

$pattern ='`^[a-zA-Z0-9éèêùôçàâî°_\-\'\(\),\%: ]*$`'; if(!preg_match($pattern, $var_rec_nom)) { $echec=$echec."- Caractère(s) non conforme(s) dans votre saisie\\n"; }

---

Du coup, je n'ai plus de plantage.

Sur les écrans de saisie, j'ai bien un contrôle identique, mais sur cetains champs le retour est bizard, je vois sur le formulaire apparaître du code après la saisie de la phrase magique "a'a"a/a\a<b>a</b>a<br>a$a"

comme ceci :

Code:

---

a$a" size="50" onfocus="this.className='focus';" onblur="this.className='normal';" alt=" nom : Authorité de délivrance ; test : ; obligatoire:true">

---

J'ai bien l'alerte comme quoi j'ai des caractère invalide, mais le renvoi du formulaire par le serveur affiche cette ligne en plus.

c'est parce que tes attributs "value" des input ne sont pas entourés de "" ou de '' ou que tu n'applique pas htmlentities sur la valeur récupérée pour la réafficher.

Le meilleur moyen pour diagnostiquer ca est en effet de regarder le source HTML produit par PHP... le probleme devrait alors te sauter aux yeux (surtout si tu as un colorateur de source comme sous firefox)

pour tes erreurs SQL, c'est parce que tu ne fait pas mysql_real_escape_string sur la valeur sans doute.

Ou alors que tu ne fait aucune verification de taille par rapport aux champs de la base, dans tout les cas, y a des choses qui manquent en effet ;o)

Citation:

---

Envoyé par Fladnag

c'est parce que tes attributs "value" des input ne sont pas entourés de "" ou de '' ou que tu n'applique pas htmlentities sur la valeur récupérée pour la réafficher.

Le meilleur moyen pour diagnostiquer ca est en effet de regarder le source HTML produit par PHP... le probleme devrait alors te sauter aux yeux (surtout si tu as un colorateur de source comme sous firefox)

pour tes erreurs SQL, c'est parce que tu ne fait pas mysql_real_escape_string sur la valeur sans doute.

Ou alors que tu ne fait aucune verification de taille par rapport aux champs de la base, dans tout les cas, y a des choses qui manquent en effet ;o)

---

mysql_real_escape_string ok c'est bien pour Mysql mais pour SQLServer il y a quoi? et PostGreSQL ;)

heu... regle n°4 de ma signature peut etre ;o)

postgreSQL a également des fonctions qui vont bien, quand a MSSQL, y a pas de fonctions prédéfinies, mais on en trouve dans les commentaires utilisateurs du manuel.

Oui, c'est le "htmlentities" qui manque.

Il est à mettre sur tous les value des champ input en "text" ?

Citation:

---

Envoyé par Fladnag

heu... regle n°4 de ma signature peut etre ;o)

postgreSQL a également des fonctions qui vont bien, quand a MSSQL, y a pas de fonctions prédéfinies, mais on en trouve dans les commentaires utilisateurs du manuel.

---

Pour Mssql il y a rien mise à par remplacer les simple quote en double. Une faille que j'ai constaté c'est le double tiret qui lui est sensible
SELECT * from xxx WHERE yyy='ffdfd--' = plantage c'est un exemple le problème c'est que j'en suis sur qu'il y a en a d'autre.

"mysql_real_escape_string" si j'ai bien compris permet de garder intact le contenu du champ et donc mysql ne l'interprête pas.

Si c'est le cas es-ce que cela remplace une fonction de ce gence (en partie bien sûr) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

function endCodeField($field) { $field = trim($field); $field = strip_tags($field); // convertit le premier caractère d'une chaîne en majuscule $field = ucfirst($field); $field = str_replace('"','"',$field); $field = stripslashes($field); $field = addslashes($field); $field = utf8_decode($field); return $field; }

---

Citation:

---

Envoyé par lodan

"mysql_real_escape_string" si j'ai bien compris permet de garder intact le contenu du champ et donc mysql ne l'interprête pas.

Si c'est le cas es-ce que cela remplace une fonction de ce gence (en partie bien sûr) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

function endCodeField($field) { $field = trim($field); $field = strip_tags($field); // convertit le premier caractère d'une chaîne en majuscule $field = ucfirst($field); $field = str_replace('"','"',$field); $field = stripslashes($field); $field = addslashes($field); $field = utf8_decode($field); return $field; }

---

---

Non il y a des choses qui sont en double ou ne serve a rien.
$field = str_replace('"','&quot;',$field);
avec ça
$field = addslashes($field);
A premiere vu.
une simple quote doit être remplacé par une double quote.

Citation:

---

Envoyé par berceker united

SELECT * from xxx WHERE yyy='ffdfd--' = plantage c'est un exemple le problème c'est que j'en suis sur qu'il y a en a d'autre.

---

ca m'etonne ce que tu dis parce que ca voudrais dire que mssql ne peux JAMAIS avoir -- dans un champ de type VARCHAR (ou equivalent krosoft) ce qui me parait tres douteux...

par contre, je veux bien que

Code:

---

1 2	$valeur = "valeur--"; $sql="SELECT * FROM table WHERE champ=$valeur";

---

plante, mais ce n'est pas pareil parce qu'il n'y a pas d'apostrophe autour de la valeur... et ce type de syntaxe doit etre reservé aux champs (et aux valeurs) qui sont purement numerique (a filtrer avant donc)

Citation:

---

Envoyé par Fladnag

ca m'etonne ce que tu dis parce que ca voudrais dire que mssql ne peux JAMAIS avoir -- dans un champ de type VARCHAR (ou equivalent krosoft) ce qui me parait tres douteux...

par contre, je veux bien que

Code:

---

1 2	$valeur = "valeur--"; $sql="SELECT * FROM table WHERE champ=$valeur";

---

plante, mais ce n'est pas pareil parce qu'il n'y a pas d'apostrophe autour de la valeur... et ce type de syntaxe doit etre reservé aux champs (et aux valeurs) qui sont purement numerique (a filtrer avant donc)

---

Je t'assure sur les croquettes de mon chat, j'ai fais un test, j'ai remarqué le même problème en version asp.

Version php

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Function SearchFichier($Mot){ $i = 0; $data = array(); $rs = mssql_query("SELECT b.nom,b.idfichier,a.code,a.idline_code,a.line FROM tb_line_code AS a , tb_fichier_code AS b WHERE a.code LIKE '%".$Mot."%' AND b.idfichier=a.idfichier ORDER BY b.nom, a.line"); while($data = mssql_fetch_array($rs)){ $arrOut[$i] = $data; $i++; } return $arrOut; }

---

C'est un petit moteur de recherche bateau (pour une utilisation personnel). Lorsque dans le champs de formulaire je tape simplement :
word --
Requête refusé.

Citation:

---

Envoyé par JackBeauregard

Pour sécuriser correctement une requête, on fait :

Code:

---

WHERE $id='".$id."'

---

ou

Code:

---

WHERE $id='.$id.'

---

Avec bien sûr dans les deux cas auparavant mysql_real_escape_string() .

Normalement c'est la première solution.

---

Non ce sont deux cas différents... dans le premier id est une chaine de charactère car il est entre quotes dans ce cas tu fais

Code:

---

WHERE id='".mysql_real_escape_string($id)."'

---

Dans le second cas id est un int donc...

Code:

---

WHERE id='.(int)$id.'

---

ou

Code:

---

WHERE id='.intval($id).'

---

@ tchaOo°

Citation:

---

Envoyé par berceker united

Je t'assure sur les croquettes de mon chat, j'ai fais un test, j'ai remarqué le même problème en version asp.

C'est un petit moteur de recherche bateau (pour une utilisation personnel). Lorsque dans le champs de formulaire je tape simplement :
word --
Requête refusé.

---

Ben je te crois alors... j'ai pas de serveur krosoft a attaquer pour verifier... mais si c'est le cas c'est VRAIMENT la base la plus pourrie de la terre... mais c'est pas possible, ca doit etre une option a activer quelque part ;o)

Citation:

---

Envoyé par Fladnag

Ben je te crois alors... j'ai pas de serveur krosoft a attaquer pour verifier... mais si c'est le cas c'est VRAIMENT la base la plus pourrie de la terre... mais c'est pas possible, ca doit etre une option a activer quelque part ;o)

---

Oui peut être mais elle aurait dù être activé par défaut. pour info c'est SQLServer 2000 peut être que sur la version 2005 c'est arrangé.