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

[JackBeauregard]

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 ?

[Bidouille]

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

[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

[berceker united]

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.

[Fladnag]

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

[JackBeauregard]

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 ?

[Eusebius]

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.

[JackBeauregard]

Si je te suis :

Code :

WHERE $id='.$id.'

est incassable (avec mysql_real_escape_string() avant)

Alors que

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".

[Eusebius]

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.

[JackBeauregard]

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 ?

[JackBeauregard]

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é.

[Eusebius]

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.

[Fladnag]

Bon, revenons au debut :

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.

[JackBeauregard]

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.

[Fladnag]

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)

[JackBeauregard]

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

[lodan]

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.

[lodan]

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.

[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)

[berceker united]

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