Sécurisation du code

Version imprimable

Voir 40 message(s) de cette discussion en une page

20/04/2009, 09h42
keaton7

Bonjour, merci pour ta réponse.

Citation:

une page avec
des valeurs POST valides récupérables et donc injectables dans une base de donnée.

Admettons qu'on puisse par ce biais ajouter des infos en POST dans le formulaire, elles ne seront de toute façon pas exploitées cote serveur. Et si les caractères sont échappés, c'est pas différent de rentrer des symboles spéciaux dans les champs du formulaire initial. Ptet pour les listes et compagnie qu'on vérifie pas toujours ...

Je ne comprend pas bien en fait en quoi consisteraient tes injections.

Ensuite, pour la copie de form, ça me parait bizarre. Selon ton exemple, que l'on ai renseigne la propriété action ou pas, ce serait bien la même chose non ? Dans ton exemple, la page a qui on envoi les infos ne change pas !

Le serveur n'ouvre pas a ma connaissance de session a chaque requête, d'autant plus quand il ne s'agit que d'afficher un bout de html ... Je ne comprend pas bien l'histoire de la session non plus ^^

Bref, c'est quand même pas clair cette histoire ^^.

Citation:

L'ennuie quand on parle de sécurité , c'est ce coté prétentieux, "je sais tu sais pas, mais je ne peut t' en dire plus" c 'est pour cela que j'interviens trés rarement sur la sécuritée.

Merci d'avoir tente d'expliquer mais il va falloir oser aller un peu plus loin pour comprendre ;)

Citation:

"je sais tu sais pas, mais je ne peut t' en dire plus"

Tu seras notre indic', on le dira a personne :D
20/04/2009, 09h52
sharrascript

Salut FoxLeRenard,

Pour ma part, j'avoue que je ne suis pas plus avancé, même encore plus dans le flou suite à tes explications^^

Si tu pouvais laisser un exemple complet ce serais peut être plus parlant, je pense.

Mais je doute qu'une faille existe dans un form sans action définie. A savoir, que je préfère toujours indiquer où mène ma page, et c'est rare que je fasse un traitement sur la même page. Mais ce n'est pas pour des raisons de sécurité, mais pour des raisons de relecture et d'organisation.

Même si tu fais :

Code:

<form method='post' action='user_registre.php' >

Rien ne m'empêche de l'envoyer depuis mon ordi local, avec par exemple :

Code:

<form method='post' action='http://www.site.com/user_registre.php' >

A savoir, que je n'essaies pas de te décrédibiliser, mais essais de comprendre ta démarche.

Citation:

Envoyé par sharrascript

Salut FoxLeRenard,
A savoir, que je n'essaies pas de te décrédibiliser, mais essais de comprendre ta démarche.

Salut l' Ami , aucun doute a ton sujet ,si-non j'aurait coupé court depuis longtemps :D

On va tout de même en rester la concernant ce code.

Mais notes que si nous voulion tout les deux donner une régle absolue de ce que doit'étre une saisie sécurisée et sa relecture a 100% il faudrait écrire un livre, et des livres sur le sujet il en existe ... tu comprends donc qu'il existe des failles en pagaille

Je me dis et j'ais écris ici;

Apliquons des régles simples et systématiques a toutes nos saisies, nous enraillerons 99.9 % des risques sachant que les grands ,vrais, hakeurs (estimés a 900 dans le monde) n'ont pas de temps a perdre avec nos sites web et leurs forums :P

Alors j' attendais ce qui avait été annoncé ici depuis plusieurs mois , un Tuto sur PHP MYSQL et la sécuritée, mais je sais que c'est un travail énorme, en attendant essayons de faire la liste du minimum vital ... alors je commence ...

1) assurer au maximum qu'un moteur ne fais pas des miliers de tests d'ataques.

Pour cela , pour ma part j'injecte dans le form un input hiden , donc en fait visible OUI mais qui ne sera pas utilisable ... ceci va empécher toute saisie par le PHP robot dont je parlais hier .
donc un
Code:

1 2 3 <input name='secur' type='hidden' value='1234568974225984lksmlk_mk'>
en se rappelant que toutes les valeurs

PHP d'ou vient le visiteur
URL de ce PHP
cookies
sont falsifiable tout les livres l'expliquent dont celui
chez Eyrolles de Damien Seguy et Philippe Gamache.
SECURITE PHP5 et MYSQL

Comment est fait cette valeur, c' est une concatenation de la date (heure)
et d 'une valeur aleatoire obtenue par ce code par exemple.Plus un texte
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 <?PHP session_start(); function cle() { $key=""; $taille = 5; $chiffre = "123456789"; srand(time()); for ($i=0;$i<$taille;$i++) { $key.=substr($chiffre,(rand()%(strlen($chiffre))),1); } return($key); } if( $code =="") { $code=cle(); $_SESSION['code']=$code; } ?>
donc lorsque nous recevons la saisie il nous suffit de suprimer le texte, et la valeur aléatoire il ne reste plus que le time, on calcul alors qu'il est inférieur a 3 minutes ... (par exemple)

Houla crois moi ça en retire d'un seul coup des petits trous :D

2) ne lire qu'une seule fois et de suite tout les _POST et les convertir en variables.

Comme ceci , car la aussi attention aux erreurs dues a empty etc ...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <?PHP session_start(); if (isset($_POST["xxx"])) $xxx=htmlentities(trim($_POST["xxx"])); else $xxx="xxx"; // pas vide !! // == ensuite on utilise que $xxx plus _POST ===== // == et on contrôle que ========== if ( $xxx!="xxx" ) //CtoutBon else { // ==== pas du javascript bien sur header('Location: http://www.monsite.com/index.php'); exit; } //alors on contrôle notre saisie code cache ! ?>
3) pour l'enchassement.

désolé mais je suis mal informé de la disparition de
get_magic_quotes_gpc et donc de la nouvelle syntaxe pour stripslashes
du POST

Bon je m'arrétes la, mais il est sur qu' avec cette méthode (a compléter ??)
j'aimerais bien :D

plus d'utilisation du genre
Code:

1 2 3 $passwold = mysql_real_escape_string($_POST['passold']);

20/04/2009, 11h50
grunk

Citation:

plus d'utilisation du genre
$passwold = mysql_real_escape_string($_POST['passold']);

htmlspecialchars ne remplace pas mysql_real_escape_string ! J'ai même plutot t'endance à l'utiliser à l'affichage , pour garder les data brutes en bdd

Par exemple

Code:

if (isset($_POST["xxx"])) $xxx=htmlentities(trim($_POST["xxx"]));

si $_POST['xxx'] vaut \x00 par exemple , il passe tout debout sans que sa gène personne.
Mysql_real_escape_string est une excellente solution pour échapper les caractère dangereux pour mysql , mais il faut en effet ne pas se reposer que sur lui.

Code:

addcslashes($string,'%_')

Est par exemple indispensable.

Et d'autre part un simple intval() suffit sur les valeur que l'on sais entière :)

En revanche je suis tout à fait d'accord avec toi sur l'utilisation d'un token dans un formulaire afin de vérifier son intégrité. On est ainsi certains que le formulaire à été poster depuis le site et non depuis le pc d'un vilain hacker.
20/04/2009, 16h17
keaton7

Merci pour ces précisions, il y a pleins de choses que j'ignorais ^^.

Le truc du nom de formulaire, j'y avais jamais pense, c'est sympa. Je me pose une question pour finir.

Si le htmlspecialchars (avec l'option quotes) converti les caractères spéciaux, pourquoi utiliser mysql_escape_string derrière ? Il n'y a priori plus de caractères spéciaux dans la chaine ?

(Je note une pointe d'agacement dans le ton du topic, l'idée n'est pas d'apprendre de chacun ? ;))
20/04/2009, 16h29
grunk

Citation:

Si le htmlspecialchars (avec l'option quotes) converti les caractères spéciaux, pourquoi utiliser mysql_escape_string derrière ? Il n'y a priori plus de caractères spéciaux dans la chaine ?

Car :

Code:

htmlspecialchars('<',ENT_QUOTES);

Va te donner < par exemple mais

Code:

htmlspecialchars('\x00',ENT_QUOTES);

Va te donner \x00 , du coup tu peux rentrer n'importe quel caractère dans la requete de cette façon.
Or comme le dis la doc mysql_real_escap_string échappe les caractère dangereux pour mysql soit : NULL, \x00, \n, \r, \, ', " et \x1a.
De plus addslashes n'échappe quand à elle que Null, ' et "" ;)

Donc mysql_real_escape_string te protège des injection sql (modification de la requete en live) et htmlspecialchars lui va te protéger contre le XSS (cross site scripting) par exemple.
Note qu'il semblerait que mysql_real_escape_string ne soit pas parfait puisque dans certains cas particulier avec un encodage bien précis de la base , il serait possible de contourner la protection via l'injection de chr(). Mais ca commence déjà à être hardcore ^_^

La vrai solution de sécurisation reste tout de même les requetes préparées ;)

Citation:

Le truc du nom de formulaire, j'y avais jamais pense, c'est sympa

C'est notemment très important avec les appel Ajax , pour ne pas être victime de CSRF (cross site request forgery).

Citation:

Je note une pointe d'agacement dans le ton du topic, l'idée n'est pas d'apprendre de chacun ?

Méa culpa si mon post précédent donnais cet impression :)
20/04/2009, 18h05
keaton7

Merci pour les infos, je ne savais pas du tout en fait l'histoire des NULL, \x00, \n, \r, \, ', " et \x1a en sql. Va falloir que j'ajoute cette fonction dans mon code j'ai l'impression ;-).

Citation:

Méa culpa si mon post précédent donnais cet impression

Je parlais globalement ;)

Si ce sujet ne sert pas a celui qui l'a crée, il n'en est pas perdu pour autant ...
20/04/2009, 18h56
sabotage

Citation:

Apliquons des régles simples et systématiques a toutes nos saisies

Je ne suis pas d'accord : je fais des choses si elles ont un sens.
Je n'utilise pas une fonction "parce que c'est plus sur", j'utilise une fonction parce qu'elle fait tel et tel choses qui empechent qu'un utilisateur malveillant puisse faire tel ou tel chose.

Parler de sécurité en restant très vague est contreproductif : on ne sait pas de quoi on se protege et donc on le fait mal.

Ce message a été écrit depuis une page enregistrée localement.
elle avait pour action="newreply.php" que j'ai du modifier en "http://www.developpez.net/forums/newreply.php" car sinon evidemment mon navigateur essaie de trouver un fichier newreply.php sur mon disque dur.
De la meme facon si je mets action="", mon navigateur envoi le formulaire sur la page de mon disque dur, et non pas sur le serveur dont la page vient.
Il n'y a pas de probleme de session puisque mon navigateur a utilisé l'id qu'il a dans son cookie pour le site.

Considérer de toute facon que le fonctionnement des navigateurs est un axe de sécurité est de toute facon une erreur : on peut valider des données de formulaires sans utiliser de navigateur.

Citation:

Envoyé par sabotage

Je ne suis pas d'accord : je fais des choses si elles ont un sens.
Je n'utilise pas une fonction "parce que c'est plus sur", j'utilise une fonction parce qu'elle fait tel et tel choses qui empechent qu'un utilisateur malveillant puisse faire tel ou tel chose.

Cela m'embétes non pas que tu ne sois pas oK avec moi, mais que tu as l'air faché :oops:

Dans ce que nous venons de définir, nous avons mis ce qui devrait' étre sur tout retour de saisie, il n' y a pas d'exeptions, c' est cela , l'intéret a mon sens, de ce fil, par contre :

Pour chaque POST je rajoute SON contôle a savoir , est-ce un nombre ou une date ou un mail etc ...

maiss la base devrait étre la même !! (énoncée ici) mais écrite dans tout les livres comme minimum !

Je sais qu ' a ce sujet beaucoup négligent le contrôlr strict des input hidden, s' estiments protégés 8O

Pour terminer je voudrais aussi aborder le rôle du serveur,
quand je vois que je peux télécharger la protection d' un repertoire de l'Ami grunk, c 'est que son serveur est mal paramétré alors qu'ici c'est impossible !

tiens je te donnes ce PHP tu peux le tester en local même pour appeler une URL ...

essais avec
http://www.developpez.net/forums/newreply.php
puis avec
http://www.widgamer.com/struct/color/
de grunk
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 <?PHP if (isset($_POST["IndexWeb"])) $IndexWeb=trim($_POST["IndexWeb"]); else $IndexWeb=""; if($IndexWeb !="") { header("content-type: application/octet-stream"); header("Content-Disposition: attachment; filename=".$IndexWeb); header("content-type: text/plain"); flush(); readfile($IndexWeb); // telechargement force } else { ?> <html> <body> <p align=center> <form action="0_secuweb01.php" method="POST" > <input name='IndexWeb' type='text' size='50' value=""> <input type="submit" name="Submit" value=" GO "> </form> </p> </body> </html> <?PHP } ?>

20/04/2009, 20h32
keaton7

Citation:

Je ne suis pas d'accord : je fais des choses si elles ont un sens.
Je n'utilise pas une fonction "parce que c'est plus sur", j'utilise une fonction parce qu'elle fait tel et tel choses qui empechent qu'un utilisateur malveillant puisse faire tel ou tel chose.

Parler de sécurité en restant très vague est contreproductif : on ne sait pas de quoi on se protege et donc on le fait mal.

Je suis d'accord et pas d'accord avec toi en même temps. Il est évident qu'il est necessaire de comprendre non pas uniquement LA fonction qu'on utilise pour une raison de sécurité mais le contexte dans son ensemble, et de façon plus globale, développer sans comprendre n'est jamais bon. D'un autre cote, ce n'est pas parce que on ne comprend pas tout tout de suite qu'il faut passer a cote de ces fonctions. Je me rappelle avoir commence le php en trifouillant un phpbb, et je n'y comprenait rien. c'est tout en progressant que le code de phpbb s'est "eclaire". J'etait quand meme bien content que le script ai évolué plus vite que mes capacités ... Je comprend bien ou tu veux en venir, mais je me permet d'ajouter qu'une fonction renforçant la sécurité, si elle a un sens, DOIT être utilisée si elle est vérifiée, sure et adaptée. L'utilisateur aura tout le temps de comprendre par la suite pourquoi elle existe mais il ne doit pas rester "en danger" pendant ce laps de temps (et bien sur pas inactif, il doit chercher de son cote ^^).

Citation:

Pour terminer je voudrais aussi aborder le rôle du serveur,
quand je vois que je peux télécharger la protection d' un répertoire de l'Ami grunk, c 'est que son serveur est mal paramétré alors qu'ici c'est impossible !

Publier des failles de sites d'autres membres sur le net, c'est pas très fairplay ^^ sans la démonstration, ça aurait été aussi clair ;)
20/04/2009, 22h14
FoxLeRenard

Citation:

Envoyé par keaton2000

Publier des failles de sites d'autres membres sur le net, c'est pas très fairplay ^^ sans la démonstration, ça aurait été aussi clair ;)

Non s' il y avait un risque quelqu'il soit je ne l'aurais pas montré, par contre cet outil peut servir a toutes et tous :D

grunk n' est pas le patron de son serveur , il aurait mal écrit un script je lui aurais dit en MP bien sur , la au contraire je lui montre ce qu'il doit exiger de son hébergeur ! ;) en plus je vous donne un bel outil ...
20/04/2009, 22h16
keaton7

Ok autant pour moi ;)
21/04/2009, 08h42
grunk

Citation:

Envoyé par FoxLeRenard

tiens je te donnes ce PHP tu peux le tester en local même pour appeler une URL ...
essais avec
http://www.developpez.net/forums/newreply.php
puis avec
http://www.widgamer.com/struct/color/
de grunk

C'est en effet pas très grave car tu récupère la page que te fournit le serveur , donc de l'html :)
Par contre si tu sais quoi faire pour avoir le même comportement que l'url dvp je suis preneur ;)
21/04/2009, 12h13
FoxLeRenard

Citation:

Envoyé par grunk

C'est en effet pas très grave car tu récupère la page que te fournit le serveur , donc de l'html :)
Par contre si tu sais quoi faire pour avoir le même comportement que l'url dvp je suis preneur ;)

Oui le HTML, mais étant rerouté de suite ton indexd.html est plu facile a capter avec cet outil, bref ta question j'avoue ne pas l'avoir posée aux technitiens des serveurs de POL Provence on Line ... :oops:

J' ais regardé dans la doc, et le fichier INI et CONF de mon Apache mais je ne suis pas assez sur de moi pour te répondre. Je leur demande et te tiens au courant.

Ce dont je suis sur c'est qu'il sagit d'un paramétre trés bloquant, puisqu'il empéche même le PHPINFO !! 8O

Je réédite car ça c' est pas mal,
http://www.ac-creteil.fr/reseaux/sys...ig-apache.html

Citation:
Envoyé par FoxLeRenard
tiens je te donnes ce PHP tu peux le tester en local même pour appeler une URL ...

essais avec
http://www.developpez.net/forums/newreply.php
puis avec
http://www.widgamer.com/struct/color/
de grunk
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 <?PHP if (isset($_POST["IndexWeb"])) $IndexWeb=trim($_POST["IndexWeb"]); else $IndexWeb=""; if($IndexWeb !="") { header("content-type: application/octet-stream"); header("Content-Disposition: attachment; filename=".$IndexWeb); header("content-type: text/plain"); flush(); readfile($IndexWeb); // telechargement force } else { ?> <html> <body> <p align=center> <form action="0_secuweb01.php" method="POST" > <input name='IndexWeb' type='text' size='50' value=""> <input type="submit" name="Submit" value=" GO "> </form> </p> </body> </html> <?PHP } ?>
Au risque de paraître idiot, je ne comprends absolument pas l'intérêt de ce code. C'est un retour normal, tout code côté serveur est exécuté, il n'y donc aucune faille, c'est simplement de la modification de formulaire et de la récupération d'une page executée.
J'ai l'impression que ce topic dérive complètement dans l'absurdité, sans vouloir offenser qui que ce soit. (D'ailleurs, c'est peut être simplement moi qui ne comprends pas bien ce qu'il se passe, dans tel cas, je paraîtrai idiot aussi, mais j'en prends le risque ^^)
Et donc pour retourner au vif du sujet, la fonction mysql_real_escape_string(); suffit à elle seule la protection du code dans le cas présent de siccagm.
Et il serait plus constructif, pour ceux qui démentent mon affirmation, de nous prouver d'un exemple concret comment contourner cette fonction, toujours dans le même cas de code fournit par siccagm bien sur!!

PS: Je tiens à re-signaler que je ne veux absolument pas offenser qui que ce soit (notamment FoxLeRenard :-P) dans mes propos et que je dis ça d'une manière totalement anodine, malgré la possibilité d'apparence agressive que peut avoir ma réponse.

21/04/2009, 15h37
FoxLeRenard

Citation:

Envoyé par adidas40

Au risque de paraître idiot,
etc...

Comme je te l'ais dit on en reste la, juste ce code mets en évidence l'ouverture ou la fermeture d'une des porte des serveurs, si tout simplement tu l'a mis en PHP sur ton micro, et testé sur les deux URL indiquées, tu vois si il y a accés en lecture (ou execution) ligne par ligne, pas question de lire le pHP c' est pas le but ! voila ça sert uniquement a ça ...

Citation:

Et donc pour retourner au vif du sujet, la fonction mysql_real_escape_string(); suffit à elle seule la protection du code dans le cas présent de siccagm.
.

Tu lis comme nous la doc, il n' y a rien de caché ... pas de secret ou de choses a savoir,

mysql_real_escape_string ne sert qu'a mettre un anti slashe sur certains caractéres cette fonction est plus que recommandée (elle est obligatoire si on veut protéger toute action MYSQL.
cette fonction ne peut- étre utilisée si mYSQL n'a pas été ouvert !

Alors tu comprends que derriére un <FORM, quand on récupére une valeur elle peut trés souvent servir a autre chose que d'aller dans une base de données, c' est pourquoi il faut empécher le passage de javascript, et les balises html

voila pourquoi, l'un n'empéchant pas l'autre,
htmlentities et trim ont largement leur rôle a jouer , je penses que nous pourrions étre d'accord sur ce point 8O
21/04/2009, 16h14
adidas40

Je pense que htmlentities n'est pas a utiliser pour protéger les données dans une base de données, sauf peut être cas spécifique. Par contre, il est important de l'utiliser pour l'affichage des données.
Alors après chacun peut faire son choix. Soit protéger directement les données au risque de perdre des caractères transmit.
Puisque si une table est bien conçue, par exemple disons la table 'commentaires', avec un champ 'titre' de type VARCHAR(30). Si l'utilisateur remplit entièrement ses 30 caractères disponibles, mais qu'il y met des caractères spéciaux, comme des accents etc.., lors de l'ajout dans la base de données ces caractères seront transformés (par exemple un simple 'é' deviendra '&execute;' et ca transforme 1 caractère en 9 !!) Les 9 derniers caractères ne seront donc pas ajoutés dans la base de données.
Je conseil par conséquent d'utiliser htmlentities seulement lors de l'affichage des données.

Par contre effectivement, utiliser trim ne peut être qu'un plus dans le traitement des données ;-)
21/04/2009, 16h32
grunk

Citation:

Envoyé par adidas40

Et donc pour retourner au vif du sujet, la fonction mysql_real_escape_string(); suffit à elle seule la protection du code dans le cas présent de siccagm.

Alors , oui elle suffit à se prémunir des injections MAIS il semblerait qu'il existe une faille avec des encodage exotique tels que GBK ou Big5 cf : http://blog.juliencrouzet.fr/2009/03...tes-preparees/
21/04/2009, 16h46
keaton7

Citation:

Envoyé par adidas40

Puisque si une table est bien conçue, par exemple disons la table 'commentaires', avec un champ 'titre' de type VARCHAR(30). Si l'utilisateur remplit entièrement ses 30 caractères disponibles, mais qu'il y met des caractères spéciaux, comme des accents etc.., lors de l'ajout dans la base de données ces caractères seront transformés (par exemple un simple 'é' deviendra '&execute;' et ca transforme 1 caractère en 9 !!) Les 9 derniers caractères ne seront donc pas ajoutés dans la base de données.
Je conseil par conséquent d'utiliser htmlentities seulement lors de l'affichage des données.

Apres c'est faire le choix de l'espace disque contre l'économie de ressources a l'affichage. A savoir si tu préfères augmenter ta taille de `titre` et éviter un traitement derrière ou économiser de l'espace et généraliser un traitement.

Pour chipoter, l'accent, c'est é.

Le probleme pour revenir au sujet principal est que l'on est pas sur que la faille soit dans ce code, qui ne parait pas si mal ... Et les discussions sur des fonctions de sécurité sont souvent enrichissantes, peu importe ce qu'elles inspirent, et c'est je trouve le cas de celle-ci ;)
21/04/2009, 16h46
sharrascript

Sympa l'article.

A savoir que PDO change la vie... ;)

Ho que oui... Je n'utilise plus que ça... Et je conseillerais de s'y pencher...

Voir 40 message(s) de cette discussion en une page