MULTIMAILER
cs_emilia123
Messages postés
122
Date d'inscription
mercredi 19 décembre 2001
Statut
Membre
Dernière intervention
5 janvier 2009
-
20 août 2012 à 09:28
aladec2007 Messages postés 27 Date d'inscription mercredi 27 juin 2007 Statut Membre Dernière intervention 19 février 2013 - 20 août 2012 à 18:08
aladec2007 Messages postés 27 Date d'inscription mercredi 27 juin 2007 Statut Membre Dernière intervention 19 février 2013 - 20 août 2012 à 18:08
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/54524-multimailer
https://codes-sources.commentcamarche.net/source/54524-multimailer
20 août 2012 à 18:08
20 août 2012 à 13:41
Il suffit par exemple de cibler l'attaque sur un utilisateur qui aurait l'habitude de se connecter à la page sécurisée pour que l'attaque passe.
ex : si un utilisateur (qui est connecté à l'administration) visite un lien spécialement préparé pour lui, alors l'attaquant peut faire executer du Javascript à cet utilisateur (faille XSS) ou lui faire executer des requetes specifiques (faille d'injection sql).
C'est vraiment un bon reflexe que de ne jamais utiliser directement (pour l'affichage ou dans les requetes) une variable utilisateur, quelque soit son origine.
20 août 2012 à 10:19
Pour la remarque 1, on peut effectivement se passer du if (session_start()!= true){session_start();} car redonbant. Pour les remarques concernant la sécurité, on peut effectivement améliorer afin d'éviter des problèmes mais il ne faut pas perdre de vue que ces scripts sont à placer dans un répertoire sécurisé uniquement accessible par un utilisateur authentifié. Je vais tenir compte de ce commentaire pour une prochaine mise à jour de la source.
20 août 2012 à 09:28
Plusieurs petites remarques :
1) les tests sur le session_start()
if (session_start()!= true){session_start();}
Je pense que ce test est inutile car redondant.
Le premier "session_start" lance le démarrage de la session.
Si elle ne renvoie pas "true", c'est qu'il y a eu un problème et cela ne devrait servir à rien de relancer "session_start" une seconde fois.
2) sécurité à l'affichage des données reçues.
Il faut faire attention à ne jamais utiliser les variables utilisateurs (récupérées de la variable $_GET ou $_POST) directement dans l'affichage retournée à l'internaute.
Le minimum est d'utiliser "htmlspecialchars(...)" pour éviter une attaque (XSS) qui consisterait à passer du javascript par l'une de ces variables par exemple.
3) sécurité dans les requetes SQL des données reçues.
Il faut faire attention à ne jamais utiliser les variables utilisateurs (récupérées de la variable $_GET ou $_POST) directement dans les requetes SQL.
Le minimum est d'utiliser "mysql_real_escape_string(...)" pour éviter une attaque (SQL Injection) qui consisterait à passer du SQL par l'une de ces variables par exemple, et qui se retrouverait directement interprété par le moteur SQL.
Bonne continuation.
EM.