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 ?
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
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.Envoyé par JackBeauregard
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 :
Avant toute requête, si j'attend du numérique, je fais :
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT * FROM matable WHERE ID='.$id.'
Donc là c'est incassable.
Code : Sélectionner tout - Visualiser dans une fenêtre à part $id=intval($_GET['id'])
Par contre, si c'est une chaine de caractère, je ne vois pas quoi faire d'autre à part :
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).
Code : Sélectionner tout - Visualiser dans une fenêtre à part $chaine=mysql_real_escape_string($_GET['chaine])
ce qui nous donne
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 '='.
Code : Sélectionner tout - Visualiser dans une fenêtre à part $chaine= htmlspecialchars(mysql_real_escape_string($_GET['chaine'])
Sans cela êtes vous certains que mysql_real_escape_string() est suffisant sur un champ texte pouvant contenir de tout ?
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.Envoyé par JackBeauregard
Si je te suis :
est incassable (avec mysql_real_escape_string() avant)
Code : Sélectionner tout - Visualiser dans une fenêtre à part WHERE $id='.$id.'
Alors que
est cassable même avant mysql_real_escape_string() avant.WHERE $id=$id
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 :
avec simple quotes :
Code : Sélectionner tout - Visualiser dans une fenêtre à part $condition = 'test AND u=10';
devient au passage à MySQL :
Code : Sélectionner tout - Visualiser dans une fenêtre à part "SELECT t,u FROM table WHERE t='$condition'"
MySQL recherchera les entrées où t vaut "test AND u=10"
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT t,u FROM table WHERE t='test AND u=10'
sans simple quotes :
devient au passage à MySQL :
Code : Sélectionner tout - Visualiser dans une fenêtre à part "SELECT t,u FROM table WHERE t=$condition"
MySQL recherchera les entrées où t vaut "test" et où u vaut "10". La requête a été modifiée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT t,u FROM table WHERE t=test AND u=10
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 :
et Fladnag dans le post au dessus dis que comme ça c'est bon, mais qu'il faut surtout éviter :
Code : Sélectionner tout - Visualiser dans une fenêtre à part WHERE id='".$id."'
Ce que je ne fais en fait pas, mais c'est de celà dont nous discutons ici.
Code : Sélectionner tout - Visualiser dans une fenêtre à part WHERE id='.$id.'
Donc mettons nous d'accord, il en va de la survie de l'humanité.
Ben non. Faut lire attentivement.Envoyé par JackBeauregard
Bon, revenons au debut :
Non.Envoyé par JackBeauregard
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 :
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...)
Code : Sélectionner tout - Visualiser dans une fenêtre à part a'a"a/a\a<b>a</b>a<br>a$a
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 :
ou
Code : Sélectionner tout - Visualiser dans une fenêtre à part WHERE $id='".$id."'
Avec bien sûr dans les deux cas auparavant mysql_real_escape_string() .
Code : Sélectionner tout - Visualiser dans une fenêtre à part WHERE $id='.$id.'
Normalement c'est la première solution.
Auto citationEnvoyé par Fladnag
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)
Bonjour,
J'ai testé sur certains de mes inputs de formulaire avecet 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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part a'a"a/a\a<b>a</b>a<br>a$a
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 :
Du coup, je n'ai plus de plantage.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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"; }
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 :
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part a$a" size="50" onfocus="this.className='focus';" onblur="this.className='normal';" alt=" nom : Authorité de délivrance ; test : ; obligatoire:true">
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 PostGreSQLEnvoyé par Fladnag
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager