$objet = new Looper($contenu_recuperer_duTemplate, $articles);
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 18 févr. 2011 à 20:19
comment ?? donne moi un exemple STP..
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 18 févr. 2011 à 15:08
"mais pour lister les valeurs je dois ajouter du html c'est oblige"
Si tu entends par là les fameuses boucles while()'entre autres' pour faire un listing...pas du tout !! La séparation est possible.
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 17 févr. 2011 à 17:49
OK je vois mais pour lister les valeurs je dois ajouter du html c'est oblige mais une separation des fichier rend le code plus clair en effet meme si ca depend du codeur.
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 17 févr. 2011 à 16:23
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 17 févr. 2011 à 13:19
ok merci maintenant mon propre code me degoute mdr
mais comment fait ton pour separer le php du html??
cool l'idee de session a l'epoque j'en savais rien du tout desole
par controle sur les donnees d'entree vous voulez evoquer le risque d'injection? parce-qu'au fond le but du code meme c'est des injection je crois non?? oubien on peut y remedier?? je saisi pas bien le probleme.
cs_hornetbzz
Messages postés59Date d'inscriptionlundi 1 décembre 2008StatutMembreDernière intervention 3 janvier 2011 14 févr. 2011 à 10:16
"Initié", hum oui c'est cela Thérèse, comme dirait l'autre. D'initié, il n'y a que le titre, ou alors le délit car c'en est un !
phpmyadmin n'est déjà pas un modèle de sécurité, mais alors là... c'est 100 fois pire.
Et on en est à PHP5 pour info, donc une petite classe et des requêtes préparées, c'est le minimum syndical et ce n'est quand même pas la mer à boire.
A la volée :
- short tags à bannir, tout le monde n'a pas accès au php.ini pour les paramétrer,
- code illisible,
- mélange html/php,
- sécurité cookies => utiliser des variables de session, plus simple et plus sécurisées,
- aucun contrôle des données d'entrée !! Pour ça, il te manque juste 200 lignes de code entre les lignes 87 et 88 : c'est le plus gros défaut de ce code,
- peu inutile, car il faudrait avoir accès au port de la base distante si c'est le but. En l'état, la seule base accessible est celle présente sur le serveur hébergeant ce beau script. Donc l'intérêt est limité puisque PMA fait ça très bien. A la limite pour l'intranet d'une école maternelle :-)
- un peu d'ajax aurait été sympa pour écrire une appli un peu plus "riche"
- tel que c'est écrit, j'imagine que c'est uniquement pour les admin et pas pour une population "large". Or l'utilisateur capable de lancer une requête sql n'a pas besoin de ce source bâclé,
En conclusion, c'est inutile et très mal écrit mais surtout, c'est HYPER dangereux...
A fuir en courant !
cs_emilia123
Messages postés122Date d'inscriptionmercredi 19 décembre 2001StatutMembreDernière intervention 5 janvier 2009 14 févr. 2011 à 08:05
bonjour,
Je dirais qu'enregistrer ce genre d'information en cookies (fichier lisible sur l'ordinateur de l'internaute) est dangereux.
Au moins, il serait conseillé de passer par des variables de session.Le contenu est stocké sur le serveur, donc non lisible depuis l'ordinateur de l'internaute.
Quelqu'un qui teste ton script laisse les coordonnées de sa base dans un fichier sur l'ordinateur.. c'est pas top.
EM.
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 11 févr. 2011 à 21:55
alors en gros je devrais cripter ces donnees avant de les ecrire dans le cookie?? je comprend mais en fait c'etait juste un test sur les cookies alors j'ai pas mise sur la securite mais je vais penser a ameliorer le code avec un algo de criptage
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 10 févr. 2011 à 16:46
Remarque : Ce n'était qu'un exemple. Car dans le cas de ton code si la connexion échoue il sera arretêr par le die(), et il échouera forcément car la valeur entrée(<script>alert('Badaboumm')</script>) dans host ne correspondrais à rien! Mais, la faille s'appliquerait surtout si un utilisateur(non avertie ou par inadvertance) de ton code aurait la mauvaise idée d'afficher le contenu de ton cookie à l'extérieur de l'intruction.
C'est surtout la lisibilité en claire des cookies qui est le plus gros problème!
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 10 févr. 2011 à 16:33
merci mec j'avais pas fait attention je vais bosser sur le code et publier une autre version.
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 10 févr. 2011 à 00:01
C'est phpAnonyme pas phpAnoByme xD,
-Les balises courtes ou shorts tags, c'est ce qu'à repris COD57 c'est-à-dire : <?php ?> et non <? ?>.
- "Failles formulaires", bon c'est un abus de dire ça, mais tu remarquera que j'ai ajouter "et l'attribution des variables". Tu ne teste pas les valeurs entrées dans le formulaire et ce que tu y attend comme valeurs. En l'état, tu teste juste l'existence des valeurs. La faille, réside sous la forme xss.
Pas convaincu ??
Prenons par exemple le champs "HOST" de ton formulaire :
Si on lui donne comme valeur : <script>alert('Badaboumm')</script>
A tous les coups, il y aura une alerte javascript qui s'affichera à l'écran, puis tu enregistre, utilise le cookie host sans le formater et surtout tu affiche son contenu, natamment dans cette ligne :
print 'Vous etes connecte sur le serveur '.$host1.' en tant que '.$user1.' a la base de donnee '.$db1;
enokbyreal
Messages postés15Date d'inscriptionmercredi 21 janvier 2009StatutMembreDernière intervention14 septembre 2010 9 févr. 2011 à 17:48
COO57: En effet c'est le premier script que j'ecris avec des cookies et j'ai une erreur moi aussi au premier lancement e script qui me dit que des variables du meme nom que les cookies ne sont pas definies Comment pourrais-je y remedier??
PHPANOBYME: entierement daccord avec ton point de vue sur les failles beantes de securite et le gaspillage de cookies qui sont pourtant limites en nombre.
Cependant je ne comprend pas bien quand tu parle "d'utilisation de balises courtes" ou encore de "failles sur les formulaires" ca serait cool que tu m'eclaire un peu.
cod57
Messages postés1653Date d'inscriptiondimanche 7 septembre 2008StatutMembreDernière intervention11 septembre 201319 9 févr. 2011 à 13:51
bonjour
la gestion des cookies est mauvaise ... des erreurs
des variables non definies !
j'ai du supprimer la gestion pour pouvoir faire tourner le script !
<? mais <?php serait souhaitable
pas de note comme phpanonyme, même si l'idée du script est séduisante
a++
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 8 févr. 2011 à 16:58
Bonjour,
Ce code est dangereux et ne respecte pas certaines règles minimales de PHP.
- Utilisation des balises courtes
- Les tests sur l'existence des variables est hasardeuse
- Problème avec OR et AND (si j'ai bien compris le pourquoi de l'utilisation)
- Failles plus que flagrante sur les formulaires et l'attribution des variables
- 4 cookies pour enregistrés des simples petites valeurs($_COOKIE accepte la forme tableau)
- Failles sur l'accessibilité des cookies. Hoooo! Il s'agit de données d'accès à la BDD
Comment peut-tu mettre en cookie des données d'accès à la BDD sans même crypter au moins ces valeurs ??
Bref, il doit surement avoir d'autres trucs mais je vais en rester là.
Je ne donne pas de note, je te laisse le soin de revoir tous ça !
19 févr. 2011 à 19:33
19 févr. 2011 à 17:09
19 févr. 2011 à 11:14
19 févr. 2011 à 11:12
18 févr. 2011 à 21:12
$articles = array(
array('id'=> 1, 'nom'=> 'art 1', 'date'=>'11-01-1111'),
array('id'=> 2, 'nom'=> 'art 2', 'date'=>'12-02-2222'),
array('id'=> 3, 'nom'=> 'art 3', 'date'=>'13-03-3333')
);
$contenu_recuperer_duTemplate = "
<!-- boucle -->
----
{id},
{nom},
{date},
<!-- fin boucle -->
";
class Looper
{
public function __construct($gabarit, $vars)
{
$begin = stripos($gabarit, '<!-- boucle -->');
$end = stripos($gabarit, '<!-- fin boucle -->');
$tempStock='';
foreach($vars as $k1 => $v1) {
$tempGabarit = substr($gabarit, $begin, ($end-$begin));
foreach($v1 as $k2 => $v2) {
$tempGabarit = preg_replace('/\{'.$k2.'\}/', $v2, $tempGabarit);
}
$tempStock .= $tempGabarit;
}
echo substr_replace($gabarit, $tempStock, $begin, ($end-$begin));
}
}
$objet = new Looper($contenu_recuperer_duTemplate, $articles);
18 févr. 2011 à 20:19
18 févr. 2011 à 15:08
Si tu entends par là les fameuses boucles while()'entre autres' pour faire un listing...pas du tout !! La séparation est possible.
17 févr. 2011 à 17:49
17 févr. 2011 à 16:23
Un exemple : http://www.phpcs.com/tutoriaux/POO-EXEMPLE-ALTERNATIVE-CAPTCHA_1202.aspx
17 févr. 2011 à 13:19
mais comment fait ton pour separer le php du html??
cool l'idee de session a l'epoque j'en savais rien du tout desole
par controle sur les donnees d'entree vous voulez evoquer le risque d'injection? parce-qu'au fond le but du code meme c'est des injection je crois non?? oubien on peut y remedier?? je saisi pas bien le probleme.
14 févr. 2011 à 10:16
phpmyadmin n'est déjà pas un modèle de sécurité, mais alors là... c'est 100 fois pire.
Et on en est à PHP5 pour info, donc une petite classe et des requêtes préparées, c'est le minimum syndical et ce n'est quand même pas la mer à boire.
A la volée :
- short tags à bannir, tout le monde n'a pas accès au php.ini pour les paramétrer,
- code illisible,
- mélange html/php,
- sécurité cookies => utiliser des variables de session, plus simple et plus sécurisées,
- aucun contrôle des données d'entrée !! Pour ça, il te manque juste 200 lignes de code entre les lignes 87 et 88 : c'est le plus gros défaut de ce code,
- peu inutile, car il faudrait avoir accès au port de la base distante si c'est le but. En l'état, la seule base accessible est celle présente sur le serveur hébergeant ce beau script. Donc l'intérêt est limité puisque PMA fait ça très bien. A la limite pour l'intranet d'une école maternelle :-)
- un peu d'ajax aurait été sympa pour écrire une appli un peu plus "riche"
- tel que c'est écrit, j'imagine que c'est uniquement pour les admin et pas pour une population "large". Or l'utilisateur capable de lancer une requête sql n'a pas besoin de ce source bâclé,
En conclusion, c'est inutile et très mal écrit mais surtout, c'est HYPER dangereux...
A fuir en courant !
14 févr. 2011 à 08:05
Je dirais qu'enregistrer ce genre d'information en cookies (fichier lisible sur l'ordinateur de l'internaute) est dangereux.
Au moins, il serait conseillé de passer par des variables de session.Le contenu est stocké sur le serveur, donc non lisible depuis l'ordinateur de l'internaute.
Quelqu'un qui teste ton script laisse les coordonnées de sa base dans un fichier sur l'ordinateur.. c'est pas top.
EM.
11 févr. 2011 à 21:55
10 févr. 2011 à 16:46
C'est surtout la lisibilité en claire des cookies qui est le plus gros problème!
10 févr. 2011 à 16:33
10 févr. 2011 à 00:01
-Les balises courtes ou shorts tags, c'est ce qu'à repris COD57 c'est-à-dire : <?php ?> et non <? ?>.
- "Failles formulaires", bon c'est un abus de dire ça, mais tu remarquera que j'ai ajouter "et l'attribution des variables". Tu ne teste pas les valeurs entrées dans le formulaire et ce que tu y attend comme valeurs. En l'état, tu teste juste l'existence des valeurs. La faille, réside sous la forme xss.
Pas convaincu ??
Prenons par exemple le champs "HOST" de ton formulaire :
Si on lui donne comme valeur : <script>alert('Badaboumm')</script>
A tous les coups, il y aura une alerte javascript qui s'affichera à l'écran, puis tu enregistre, utilise le cookie host sans le formater et surtout tu affiche son contenu, natamment dans cette ligne :
print 'Vous etes connecte sur le serveur '.$host1.' en tant que '.$user1.' a la base de donnee '.$db1;
9 févr. 2011 à 17:48
PHPANOBYME: entierement daccord avec ton point de vue sur les failles beantes de securite et le gaspillage de cookies qui sont pourtant limites en nombre.
Cependant je ne comprend pas bien quand tu parle "d'utilisation de balises courtes" ou encore de "failles sur les formulaires" ca serait cool que tu m'eclaire un peu.
9 févr. 2011 à 13:51
la gestion des cookies est mauvaise ... des erreurs
des variables non definies !
j'ai du supprimer la gestion pour pouvoir faire tourner le script !
<? mais <?php serait souhaitable
pas de note comme phpanonyme, même si l'idée du script est séduisante
a++
8 févr. 2011 à 16:58
Ce code est dangereux et ne respecte pas certaines règles minimales de PHP.
- Utilisation des balises courtes
- Les tests sur l'existence des variables est hasardeuse
- Problème avec OR et AND (si j'ai bien compris le pourquoi de l'utilisation)
- Failles plus que flagrante sur les formulaires et l'attribution des variables
- 4 cookies pour enregistrés des simples petites valeurs($_COOKIE accepte la forme tableau)
- Failles sur l'accessibilité des cookies. Hoooo! Il s'agit de données d'accès à la BDD
Comment peut-tu mettre en cookie des données d'accès à la BDD sans même crypter au moins ces valeurs ??
Bref, il doit surement avoir d'autres trucs mais je vais en rester là.
Je ne donne pas de note, je te laisse le soin de revoir tous ça !