virg Posté 4 Janvier 2010 Posté 4 Janvier 2010 Donc le site http://www.artisan-ebeniste-createur.com est hacké pour la deuxième fois. La première c'était par une faille dans le formulaire de contact. J'ai donc ajouté un captcha et changé tous les mots de passe mais là, je ne vois pas d'où vient le problème, je ne suis pas spécialiste en piratage. pour info, il n'y a des attaques que sur la bdd, pas sur les fichiers html à priori. PS : qq connaitrait-il la personne qui a fait ce hack pour qu'il ou elle m'explique pourquoi il-elle a fait ça ? si encore il-elle m'avait fourni des infos sur les failles pour m'aider à améliorer le site, mais là, si ce n'est qu'une performance gratuite, je trouve cela petit ... par rapport à ce que j'ai lu dans un autre post : La sécurité ça se traite à plusieurs niveaux (tous, de préférence). Comme cela a été souligné, il faut vérifier que tous les composants sont à jour : os, serveur, php, db et cms. Les exploits sont aisément disponibles et la plupart des attaques utilisent des procédés publiés, en profitant de la paresse de mise à jour des webmaster et hébergeurs. Le mot de passe évidemment. => ils ont tous été changés et respectent plus de 6 caractères, des caractères spéciaux quand c'est possible, une casse changeante et pas de mots trop évidents. Les login: un minimum d'"ingénierie sociale" permet de trouver les login de beaucoup de sites (au hasard le prénom du webmaster); c'est déjà la moitié du boulot. => idem que les mdp Le paramétrage : le mode "debug" est bien utile en dev, mais il révèle des informations potentiellement intéressantes pour les petits malins en production. => je suis sur un serveur mutualisé, je ne pense donc pas avoir accès à cette info PHP ou autre, ça se configure: il est souvent possible d'ajuster la taille des fichiers uploadés, le temps max d'execution etc. Un petit script comme phpsecinfo permet de s'assurer de la sécurité de sa config. => idem que pour le mode debug, mais est-ce que sans toucher au serveur, il y a des choses, côté fichiers que je pourrais limiter ? à partir peut-être justement des infos fournies par cette commande phpsecinfo ? Le choix du cms: c'est un point crucial; un typolight qui se bloque pendant 5 minutes au bout de trois tentatives de connexion ratées, ça limite fortement la brute force. En consultant la fréquence de mise à jour, et les alertes sécu on a déjà une bonne idée de sa qualité sécuritaire. => le site est fait à la main de bout en bout à part une slimbox en javascript, aucun cms ou forum ou autre script php déjà fait. Htaccess : pour limiter les accès, voire mettre des filtres à l'ip (pour l'admin) Les nom de dossier ou url : on essaie d'éviter admin et compagnie => j'ai trouvé mon ip, reste à m'assurer qu'elle soit bien fixe et je teste ce filtre. "Google yourself" : vérifier que google n'indexe pas des trucs qu'on a pas envie de divulguer(comme tes pages d'erreurs).Au besoin on les désindexe avec gwt. => à tester Un petit coup de scanner de vulnérabilités, style wikto ou acunetix. => à tester La vraie vie : le post-it avec mdp sur le moniteur ça rend bien service... => mdp appris par coeur ou ranger dans un dossier à la maison, pas d'autres accès que le propriétaire du site et moi-même Enfin, est c'est là le plus important, un hacker doué arrivera toujours à passer et défacer un site. Il faut être capable de tout effacer (y compris la db) et de tout remettre en ligne en moins d'une heure. Pas bien compliqué, mais ça demande un peu d'organisation et des sauvegardes régulières(automatisables). => les sauvegardes sont faites à chaque modifs, mais c'est pour le principe, si encore il s'agissait d'un site commercialement important ou moralement limite ou qu'il y avait une quelconque idéologie dans cet acte, mais là, s'en prendre à un créateur de meubles et objet déco qui est artisan, seul à son compte .... bof ... Et puis, c'est pas comme si il regardait son site tous les jours, et je n'en ai pas le temps non plus. Ou alors je vois avec mon hébergeur pour mettre un script de scan de tout le site automatisé et quotidien qui m'avertirait en cas de modifs. Bon courage Si qqn a une autre idée, merci d'avance
Portekoi Posté 4 Janvier 2010 Posté 4 Janvier 2010 Bonjour, Déjà, il faudrait contrôler les erreurs 500 --http://www.artisan-ebeniste-createur.com/06-actu/actu.php?id='%22 Ensuite, mettre un .htacces sur l'admin et changer le nom du dossier afin d'éviter qu'il ne soit trop facilement accessible. Pour finir, mettre un type "password" pour le mot de passe qui est en clair. Si la personne à la saisie automatique sur IE d'activée, le mot de passe apparaitra en clair. Bon courage Portekoi
virg Posté 4 Janvier 2010 Auteur Posté 4 Janvier 2010 Bonjour, Déjà, il faudrait contrôler les erreurs 500 --http://www.artisan-ebeniste-createur.com/06-actu/actu.php?id='%22 Ensuite, mettre un .htacces sur l'admin et changer le nom du dossier afin d'éviter qu'il ne soit trop facilement accessible. Pour finir, mettre un type "password" pour le mot de passe qui est en clair. Si la personne à la saisie automatique sur IE d'activée, le mot de passe apparaitra en clair. Bon courage Portekoi déjà bonjour et merci ensuite, ok pour les premiers, mais le password de l'admin est déjà en type password ... comment se fait-il que vous le voyer en clair ? merci
Portekoi Posté 4 Janvier 2010 Posté 4 Janvier 2010 Autant pour moi, j'avais cru voir un type "text". Il faudrait aussi empêcher de lister le contenu des répertoires...
Portekoi Posté 4 Janvier 2010 Posté 4 Janvier 2010 Là où se trouve "hacked by", les pages touchées sont elles des pages gérables via l'admin? A t il supprimer des pages ou juste pris le contrôle de l'admin?
virg Posté 4 Janvier 2010 Auteur Posté 4 Janvier 2010 Là où se trouve "hacked by", les pages touchées sont elles des pages gérables via l'admin? A t il supprimer des pages ou juste pris le contrôle de l'admin? Seulement des pages modifiées via l'admin, il ne semble pas y avoir de fichier php modifiés. Le problème est qu'il semble qu'il ai surtout eu envie de se faire de la pub, donc le fait qu'il n'ai pas supprimé de pages n'est pas forcément la garantie que je n'ai pas de failles de ce côté là. Enfin, à mon avis. Mais je pense qu'avec toutes ces infos, je vais progresser sur pas mal de points.
Portekoi Posté 4 Janvier 2010 Posté 4 Janvier 2010 Re, Justement, quoi de mieux qu'une page intégralement remplie de mots cléfs avec des liens par exemple? Je pense donc qu'il n'a eu accès qu'à la console admin Portekoi
f_trt Posté 4 Janvier 2010 Posté 4 Janvier 2010 Tu dis : La première c'était par une faille dans le formulaire de contact. J'ai donc ajouté un captcha et changé tous les mots de passe Un formulaire n'est pas une faille en lui même c'est le traitement qui est fait derrière qui a surement une faille, le captcha n'apporte pas grand chose au niveau de la sécurisation si le hacker a reperé la faille dans le script qui traite le formulaire il y a un max de chance que l'adresse de ce script soit dans sa base voir même dans une base partagée entre hacker et il reviendra directement par là. Si tes connaissances ne sont pas suffisantes pour contrôler le script qui traite le résultat de l'envoi du formulaire desactive le. Pour ma part je vois que tu peux joindre un fichier par le formulaire si tu n'as pas de traitement rigoureu empechant entre autre de joindre un fichier php ta faille est surement de ce côté. A+
virg Posté 4 Janvier 2010 Auteur Posté 4 Janvier 2010 Tu dis : Un formulaire n'est pas une faille en lui même c'est le traitement qui est fait derrière qui a surement une faille, le captcha n'apporte pas grand chose au niveau de la sécurisation si le hacker a reperé la faille dans le script qui traite le formulaire il y a un max de chance que l'adresse de ce script soit dans sa base voir même dans une base partagée entre hacker et il reviendra directement par là. Si tes connaissances ne sont pas suffisantes pour contrôler le script qui traite le résultat de l'envoi du formulaire desactive le. Pour ma part je vois que tu peux joindre un fichier par le formulaire si tu n'as pas de traitement rigoureu empechant entre autre de joindre un fichier php ta faille est surement de ce côté. A+ c'est là le problème, j'ai bloqué la taille des pièces jointes en javascript et en php le traitement php des pièces jointes prend en compte l'extension et la vérifie les données ne sont jamais passées en claires tous les champs sont vérifiés par un script en php qui "nettoie" l'éventuel ajout d'url (http ou [url ou autres) et encode les balises html saisies pour qu'elles ne soient pas interprétables le captcha était parce que le premier hack venait d'un robot donc : je préfère améliorer mes connaissances que de me limiter à la suppression d'un éventuel problème je ne côtoie pas d'autres webmaster, je n'ai donc aucune idée de mon niveau j'aimerais bien savoir où l'on trouve ces "bases partagées" pour savoir ce qu'elles contiennent sur mon site est-ce que cela vous éclaire sur l'état des choses ? Tu as modifié les codes d'accès à l'admin ? oui, déjà plusieurs fois Re, Justement, quoi de mieux qu'une page intégralement remplie de mots cléfs avec des liens par exemple? Je pense donc qu'il n'a eu accès qu'à la console admin Portekoi merci encore, je m'attèle à tout ça pour faire le point
virg Posté 5 Janvier 2010 Auteur Posté 5 Janvier 2010 Je suis sur les tests J'avais déjà un compte de suivi des sites dans google avec ajout des sitemap etc., donc je connaissais ça côté référencement et vérification des index, liens morts etc. par contre, je ne comprends pas à quoi ce rapporte l'élément "Google yourself". quand je tape "Google yourself" dans google cela me renvoie à un site promotionnel LookupPage qui a l'air de ne faire que de la promo, rien à voir avec un vérificateur de google => est-ce que qqn en saurait plus ? merci
captain_torche Posté 5 Janvier 2010 Posté 5 Janvier 2010 Google yourself, ça veut simplement dire "vérifie que dans Google il n'y a aucune info qui n'y a pas sa place". Ca m'est arrivé de retrouver un fichier de travail (rien qu'une exportation d'une base de données d'inscrits, avec login, adresses mails et mots de passe en clair) indexé par google parce que j'avais merdé la protection du répertoire de travail ...
virg Posté 6 Janvier 2010 Auteur Posté 6 Janvier 2010 Ok merci de l'info par contre, est-ce que qqn a testé mon formulaire de contact ce matin ? qui aurait mis ff_AT_ff.org comme contact et aurait testé ' OR 1=' dans le champ sujet ? si oui, c'est sympa de tester pour moi, mais pourriez-vous m'expliquer ce que vous avez fait et ce que ça veut dire ? ou alors me dire où trouver plus d'infos sur ce genre de tests ? merci
Portekoi Posté 6 Janvier 2010 Posté 6 Janvier 2010 Bonjour, J'avais fais des tests de cette nature le jour même mais pas ce matin C'est de l'injection SQL. : http://fr.wikipedia.org/wiki/Injection_SQL Portekoi
virg Posté 7 Janvier 2010 Auteur Posté 7 Janvier 2010 (modifié) Merci je ne savais pas qu'il y avait des cours aussi explicites sur ce genre de choses, et c'est bien parce que ça explique ce que ça fait et ce que ça veut dire. C'est justement ce qui me permettra de vérifier que ce que je code n'est pas absurde et ça me donnera surement d'autres pistes en même temps. Merci beaucoup de l'info. Modifié 7 Janvier 2010 par captain_torche Inutile de citer le message précédent; on vient de le lire.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant