Salut a tous !
 
Je suis en train de sécuriser mon site en ajoutant différents contrôles au niveau des valeurs qui sont utilisées, soit pour afficher des pages, soit pour effectuer des opérations sur ma base, et ainsi prévenir les risques d'injection Mysql, ou autre détournement.
 
Pourriez vous me dire si les contrôles que j'utilise sont suffisant ?
 
Sur cette exemple, c'est j'envoie par la méthode GET "id", qui me sert à générer une page.
 
 

 
 
Je voudrai également savoir, si il faut faire d'une généralité l'utilisation de get_magic_quotes_gpc() et de sprintf() pour TOUTES les requêtes du site, ou uniquement sur les requêtes qui sont alimentées par dés valeurs récupérées en GET, POST
 
Merci

idéalement, pour sécuriser tes requêtes, tu devrais utiliser PDO et les requêtes préparées,et de la sorte,  tu t'affranchis de tous les stripslashes, mysql_real_escape_string et consorts.

Ca me parait suffisant. Je rajouterais néanmoins les remarques suivantes:
-il vaut mieux ne pas afficher les erreurs mySql mais les logguer
-même remarque pour les erreurs PHP
-si l'ID est bidon, autant renvoyer une erreur 404
-si la requête plante pour une raison x ou y, il faudrait idéalement renvoyer une erreur 500

+1 pour le coup de masquer les erreurs. Une pratique courante est d'avoir le site dev qui affiche les erreurs toussa toussa, et (ou puis) la prod ou rien n'est affiché si ce n'est un joli message bien formulé et bien généraliste.
 
M'enfin. Déjà, avec le code que tu présente la, tu te protège des trucs les plus basiques comme les injections SQL.
 
Enfin, pour te répondre, ce n'est pas la peine d'échapper TOUTES tes requêtes SQL, mais de manière générale, d'échapper TOUTES les valeurs qui viennent de l'extérieur (donc entre autre de GET/POST).

Pour les champs texte, utiliser aussi strip_tags() Ca évitera des injections de javascript...

 
En faisant quelles recherche j'étais tombé dessus, peut ont dire que c'est la solution "ultime" contre tous types d'attaques ? l'investissement en temps  de revoir l'ensemble d'un site vaut-il vraiment le coup  ?
 
Merci de ta réponse.
 

 
- Effectivement, c'est vrai que mysql_error renvoi/peut renvoyer des informations comme le nom d'un champs, d'une table ou autres. donc le mieux serais de créer une table qui enregistrerais toutes les erreurs mysql qui peuvent survenir sur le site. interessant !
- J'avais en tête de vérifier aussi l'existance de l'id, histoire d'être sur que les visiteurs ou "hacker" ne tombe pas sur une page foireuse. mais je n'ai pas encore trop réfléchi pour faire au plus simple sans avoir trop de redondance dans le code.
- utiliser l'erreur 500, si je comprend bien, permet au visiteur de comprendre qu'il s'agit d'une erreur interne au site, et non une erreur de chargement d'une page. Mais le visiteur lambda ferat-il la différence ?
 
Merci de ta réponse et de tes conseils
 

 
   
 
Promis, je cacherais mes erreurs Mysql , et les valeurs qui sont issue d'un formulaire ? mais pas un formulaire ou une saisi est possible, par exemple comme dans ma page ou il est composé de <select>, j'imagine qu'il pourrais être relativement simple de créer un site parallèle renvoyant sur mon url de validation de mon formulaire, avec des select maison bien crapuleux , donc je me répondrais oui, mais toi, qu'en pense tu ?
 
Je me demande aussi si c'est bien utile de vérifier si une valeurs est numérique 2 fois, comme je le fait la avec  
 

et

 
Dans la doc php de la fonction spintf(), il est indiqué que:

Merci pour le conseil !
 
Mais ou utiliser cette fonction ? faudrait-il substituer get_magic_quotes_gpc() par celle ci ou bien StripSlashes() ? ?

strip_tags() ne substitue pas à une autre fonction, elle vient en complément.
 
Tu peux très bien faire une truc du genre :

$Text = addSlashes(strip_tags($_POST['MonChampTexte']));

Salut ! Une fois que tu as verifié que l'ID est numérique, ça sert plus à rien de faire d'autres tests derrière.
En revanche prendre en compte tous les cas utilisateurs (entrée vide ? entrée non numérique ? => message d'erreur) me semble judicieux

Salut kontas
 
Tu as eu des réponses sur la sécurité technique. Mais n'oublie pas la sécurité applicative. Je ne connais pas ce qu'il y a en amont de ta page, mais peut être que l'utilisateur n'a pas le droit d'accéder à cet "ID" (et c'est tellement facile de modifier l'ID dans l'url...).  
 
Donc pour ma part, si les données de l'ID à afficher sont confidentielles ou réservées à certaines personnes, alors après le test d'existence de l'id, il conviendrait de rajouter un test "est ce que cet utilisateur a les droits sur cet ID".  
 
Mais si l'ID en question est pour tout le monde, alors oublie mon intervention. DOminique