Aller au contenu

virg

Membre
  • Compteur de contenus

    8
  • Inscrit(e) le

  • Dernière visite

Messages postés par virg

  1. 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.

  2. 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

  3. 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

  4. 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

  5. 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.

  6. 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

  7. 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

×
×
  • Créer...