"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.
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.
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.
"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...
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.
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
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!
-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;
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.
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
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 !
- Messages postés
-
392
- Date d'inscription
- mercredi 28 octobre 2009
- Statut
- Membre
- Dernière intervention
- 23 mars 2012
45