shinnokamui
Messages postés15Date d'inscriptionmardi 14 août 2007StatutMembreDernière intervention13 février 2010
-
4 juil. 2008 à 17:53
shinnokamui
Messages postés15Date d'inscriptionmardi 14 août 2007StatutMembreDernière intervention13 février 2010
-
5 juil. 2008 à 20:25
Bonjour,
J'ai un formulaire dans un site avec un champ où l'utilisateur peut entrer du texte, j'aimerai récupérer ce texte d'une manière sécurisé et l'écrire dans un fichier sur le serveur...
Je me demandais si il était possible d'injecter du code "malveillant" avec un simple appel à une fonction d'écriture sur fichier, je c'est que c'est possible avec une requête SQL ou à l'affichage d'une variable $_GET modifié, mais y a t'il un risque avec un simple fputs(), et il faudrait donc protéger l'entrée de l'utilisateur par un $entrée= mysql_real_escape_string(htmlspecialchars($entrée)0); avant de l'écrire sur le fichier ?
Aussi, j'en profite pour poser une question consernant ce genre d'injection, voici un petit code :
$p = $p + 1;
imaginons que la variable $p soit accessible par l'utilisateur (il s'agit d'un $_GET par exemple), est ce qu'il y a un risque d'injection si l'utilisateur modifie la variable $p par :
; echo $mot_de_passe_important;
Voila, j'ai toujours quelques problèmes de comprehension avec les injections apparament, si quelqu'un pourrait m'éclairer spv
A voir également:
[sécurité] injection possible avec une simple écriture sur fichier dans le serve
PlayerMania
Messages postés95Date d'inscriptionjeudi 22 avril 2004StatutMembreDernière intervention28 avril 2009 5 juil. 2008 à 20:10
$entrée = mysql_real_escape_string(htmlspecialchars($entrée);
Ces fonctions sont bien mais elle n'enlevent pas forcément tout ce que tu souhaiterais (éventuellement quelques danger pourrai subsister selon ton script), il y a aussi certaine chaine unicode qui sont dangereuses.
Bref, au final, toi tu es hors de danger de tout manière, vu que ton fichier log n'est jamais utilisé pour construire, calculer qqch dans ton site, donc tu es hors des risques meme si il contient que des caractères à tendance dangereuse, ils ne seront jamais interprétés.
Pour la config du serveur, ça va peu etre rude chez free, regarde du coté de la fonction iniset();
$var = intval($var);
En fesant cela, c'est bien, tu fait une sorte de controle pour t'asssurer que c'est bien un chiffre qui doit etre retourné, essaye de mettre du charabia et des caractères louche dans $var et 0 sera retourné.
"elle sera transformé en nombre" => si c'en est reelement un
Je te laisse ça, t'en aura surement besoin un jour lol :
$special_char = array(" ", "!", ":", "?", "/", "$", "&", "%", "'", ",", """, "#", "{", "}", "(", ")", "[", "]", "|", "\", "+", "=", "£", "€", "µ", "*", "?", "<", ">", ";", "§", "^", "../", "./", "..\", ".\", "%00", "`", "~", "…", "ˆ", "‰");
$var = str_replace($special_char,'',$var);
Enleve à ta guise ce que tu souhaites conserver et puis fait toi ta propre fonction specialchars.
PlayerMania
Messages postés95Date d'inscriptionjeudi 22 avril 2004StatutMembreDernière intervention28 avril 2009 5 juil. 2008 à 04:05
L'injection SQL est le fait de réussir a détourné une requete SQL de sa vrai fonction. Donc c'est très dangereux pour les bases de données.
Il y à également d'autres types d'injections sur d'autres supports.
Au final, pour les éviter, il faut que tu échappe tes variables avant de les envoyer dans ta base ou tes fichiers grace à la fonction addslashes(); qui va donc ajouter un slashes devant chaque caractère qui pourrai permettre une injection.
Et bien sure, c'est a toi aussi de faire du ménage dans les chaine, et voir les caractères que tu autorise ou non, fonctions strtr(); str_replace();
Après, lorsque tu affiche ces variables, tu leur applique un stripslashes(); qui va donc enlever les échappements.
Applique tjrs ce système, avec une config php register_globals à Off et tous les magic_quotes_... à Off, et tu n'auras jamais d'injection.
PlayerMania
Messages postés95Date d'inscriptionjeudi 22 avril 2004StatutMembreDernière intervention28 avril 2009 5 juil. 2008 à 04:19
mouais... je suis un peu parti à droite, à gauche, dsl...
$p = $p + 1;
Tant que $p sers à rien à part afficher le résultat d'un calcul specifique à la session de qqun, bin qui s'amuse le gonz à le changer lol...
Mais si $p est plus tard dans le script enregistré quelque part dans un fichier via fputs() comme tu dis, la applique lui des filtres pour ne pas autorisé des caractères à tendance baliseuse ou autre, addslashes le aussi, au cas ou tu réimporterai en sql, tu risque plus une faille xss dans ton cas (selon ce que tu fais de tes données stocké dans tes fichiers)
shinnokamui
Messages postés15Date d'inscriptionmardi 14 août 2007StatutMembreDernière intervention13 février 2010 5 juil. 2008 à 11:22
Merci ^^
Mais pour faire plus simple, est ce que appliquer les deux fonctions suivantes ne règle pas le problème d'injection ? (la première pour SQL, la deuxième pour le reste) vu que pour le faire en manuel (addslashes puis str_replace), il faudrait connaitre toutes les balises à éliminer, et ça me parait risqué si on s'y connait pas trop comme moi. Donc appliquer à toutes les entrées modifiables par l'utilisateur ceci ...
Pour le fichier serveur, il s'agit juste d'un log, que je téléchargerait ensuite en FTP, il n'est pas utilisé dans le site en PHP. Donc si j'ai bien compris je ne risque rien avec le fputs() ?
Et pour les register_globals/magic_quotes_..., comment je modifis ça exactement ? je suis hébérgé chez Free...
J'en profite pour une nouvelle petite question ; si j'ai une variable numérique modifiable par l'user, est ce que $var = intvar($var); est risqué ? vu que quelque soit l'entrée, elle sera transformé en nombre, or la variable normalent est un nombre, donc aucun problèmes non ? (si l'user à tenté une injection, elle sera transformé en nombre ...)
Vous n’avez pas trouvé la réponse que vous recherchez ?