IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelle sont les meilleures pratiques de sécurité pour protéger un site des hackers ?

Le , par netwebzone
61 commentaires

1PARTAGES

0  0 
Bonjour,

Il y a quelques jours je vais un site que je visite régulièrement, et à ma grande surprise la page d'accueil a été remplacée par un hacker, plus rien ne fonctionnait. Aujourd'hui c'est rentré dans l'ordre mais je me dit que si ce site important est tombé sous l'assaut d'un hacker, mon site sera alors très facile à hacker parce que je ne m'y connait pas autant que le webmaster de ce site, qui est à priori un professionels dans ce domaine.
Je me demande juste alors comment se prémunir de ce genre d'attaque pour ne pas retrouver son site un beau matin totalement effacé, remplacé par une page d'un hackeur qui se vente de son acte !

Quels sont leurs techniques pour récupérer les identifiants ? Comment les protéger ? Comment tout simplement protéger son site des hackeurs ?

Merci
Au revoir
Bonne journée ++

Une erreur dans cette actualité ? Signalez-nous-la !

61 commentaires
Commenter Signaler un problème
Clorge
Avatar de Clorge
En attente de confirmation mail https://www.developpez.com
Le 26/03/2013 à 22:29
s'il vous plait....

Si vous désirez entrer dans le débat, utilisez les bons termes.

Hacker : bidouilleur, il cherche à comprendre le fonctionnement des systèmes, en soit il n'y a rien de mal à ça.

WhiteHat : hacker qui veut le bien dans le meilleur des mondes, il cherche des failles sur les sites sur lequels il est autorisé, bidouille son pc pour voir comment tous ça marche, et si il y a un problème, il en fait part aux dévellopeurs pour le corriger.

BlackHat : L'opposé du Whitehat, il veut du fric, du pouvoir, c'est LUI LE MECHANT!

ScriptKiddie : gamin de 12ans qui prétend savoir pirater les sites, mais qui n'utilise que des softs fait par d'autres, et lui est fier d'avoir HOIC d'installer vous pouvez rire de lui sans soucis

Cracker : hacker spécialisé dans les LOGICIELS.

Bon, désormais que les présentations soient faites :
Il est idiot de croire qu'un site même un blog de gamine soit inutile, AU CONTRAIRE, c'est une proie facile pour obtenir une machine supplémentaires, le blackhat (ou pirate) n'en n'as rien à faire de ses tweet, mais qu'il puisse envoyer du spam, ddos, etc, ça c'est intéressant.

Il faut s'intéresser à la sécurité informatique quand on programme!
Mais bon, un membre du staff as expliquer la position du forum pour les explications des failles et les corrections, j'en dirais rien alors Je connait pas tout, loin de là, mais mes conseils auraient pus en aider certain.

Internet est un réseau immense, ne croyez pas c'est parce que vous n'etes pas connu, qu'on scanneras pas votre serveur, vos ports, vos services et votre site web!

ps : les whitehat s'intéressent à tous les sites, et il m'arrive de tester une xss par ci par là (souvent sous la forme <span></span> afin de ne causer AUCUN tort) et si je trouve quelque chose, je préviens le webmaster, après il en fait ce qu'il veut C'est vraiment dans une optique d'AIDER, et pas causer des problèmes.
3  0 
Marc Lussac
Avatar de Marc Lussac
Rédacteur en Chef https://www.developpez.com
Le 30/11/2005 à 16:14
Personnellement je vois quelques petites choses, en majorité évidentes :

1) utiliser toujours les dernières versions du système et des scripts, et etre à l'écoute des messages d'alertes pour appliquer imédiatement les mise à jours ou patchs pour ces scripts ou ce système.

2) selectionner des scripts d'équipes sérieuses, et avec des équipes encore vivantes, qui peuvent mettre à jour rapidement leur soft en cas de découverte de failles

3) si la licence le permet, camoufler le nom et la version du script, pour éviter de faciliter le travail des hackers.

4) changer des choses dans le scripts, comme les noms de fichiers ou de répertoires, pour le rendre plus impérméable aux attaques de virus ou de hack en kit prets à l'emploi.

5) toujours installer tous les modules de sécurité en sus pour un script donné

6) sécuriser le serveur autant que possible, en mettant des protections partout ou c'est possible, par exemple pour Apache c'est des htaccess un peu partout. A cet égard il faut choisir un hébergement qui vous le permet, comme par exemple dédié, ou semis dédié, ou mutualisé pro à valeur ajoutée.

7) etre abonnés aux bulletins de sécurités concernant les systèmes, logiciels, ou scripts que vous utilisez pour réagir promprement en cas de nouvelles failles.

8 ) avoir toujours des sauvegardes à jours, et vérifier que ces sauvegegardes sont valables, en effet on ne peut jamais etre sur à 100%.

9) ne pas utiliser de pc ou de réseaux à usages collectifs (travail, cyber café, voir famille) ou vos identifiant peuvent etre aiséments retrouvés ou captés.

Autres choses ?
1  0 
kankrelune
Avatar de kankrelune
Membre éclairé https://www.developpez.com
Le 25/05/2006 à 19:14
Pour rappel concernant php... les fonctions, procédures suivantes sont à employer sans modération... .. .
  • addslashes et mysql_real_escape_string
  • (int)$maVar (par ex dans le cas d'un id)
  • htmlspecialchars, htmlentities voir même carement strip_tags
  • is_file ou file_exists (fameuse faille du include)
  • file_get_contents (pour des fichiers autre que php pas besoin d'include)
  • initialiser ses variables à vide en début de script ($maVar = ''; )
  • error_reporting(0); pour le site en production le mieux étant paralellement de loguer les erreurs php et de n'afficher le mode debug (pour les script qui en ont) qu'aux admin
  • chmod 444 pour tous les fichiers de config (le mieux étant de les mettre dans un répertoire à part protégé par un .htaccess en deny from all)
  • comme dit précédament donner des noms bizars à tous les fichiers (surtout éviter les admin.php) et répertoires qui n'ont pas à être accédé par les utilisateurs normaux (par exemple utiliser un préfix genre pwet_includes plop_admin)
  • évitez les options "connection automatique" et d'une manière générale ne faire que peu confiance aux cookies (sauf pour des options mineurs genre quel theme veut tu utiliser)
  • stocker une variable unique à l'utilisateur dans la sessions du membre (genre ip + useragent + language le tout hashé avec md5) et le comparer à chaque début de page pour lutter contre le session hijacking
  • comme dit précédament logger les actions des utilisateurs peut être plus qu'instructif
  • config php.ini : register_globals à off, allow_url_fopen à off et safe_mode à on c'est pas du luxe non plus
  • protéger les répertoires contenant les log avec un .htaccess et d'une manière générale tous les répertoire ou l'utilisateur n'est pas censé accéder via http
  • controler la provenance d'un formulaire soit avec la technique captcha (image contenant un code à saisir générée à la volée) ou alors avec la technique du ticket (champs caché du formulaire contenant une id unique générée à la volée)
  • concernant l'identification préférer une requete qui renvoie les infos par rapport au login et comparer ensuite le pass plutot que de juste regarder si le membre existe (WHERE login=$login AND pass=$pass)
  • hascher le pass avec un grain de sel généré à la volée lors de la soumission pour la connection peut être un plus non négligeable... ça donne du fil en plus à tordre au pseudo pirate...
  • temporiser la soumission des infos de connection (genre avec un sleep d'une seconde ou deux) pour eviter les boots et rendre difficil les attaque par brute force...
  • bannir la personnes genre une demi heure si elle se plante plus de trois fois de pass... .. .
Voila dans les grandes ligne... la liste est loin d'être exaustive mais, sauf oubli, le plus important est là... .. .

@ tchaOo°
1  0 
Etanne
Avatar de Etanne
Membre éclairé https://www.developpez.com
Le 26/03/2013 à 23:04
Citation Envoyé par Clorge Voir le message
Internet est un réseau immense, ne croyez pas c'est parce que vous n'etes pas connu, qu'on scanneras pas votre serveur, vos ports, vos services et votre site web!
J'ai eu plusieurs serveurs sur le net (linux & windows), pour chaque serveur je me suis fait scanner, ou tentative d'accès aux urls typiques de phpmyadmin ou de l'administration wordpress.

Sans compter le nombre de petits malin qui s'amusent à faire des attaques DOS sur Teamspeak... grr

Citation Envoyé par Clorge Voir le message
ps : les whitehat s'intéressent à tous les sites, et il m'arrive de tester une xss par ci par là (souvent sous la forme <span></span> afin de ne causer AUCUN tort) et si je trouve quelque chose, je préviens le webmaster, après il en fait ce qu'il veut C'est vraiment dans une optique d'AIDER, et pas causer des problèmes.
Idem, quand je vois qu'il y a une possibilité de valider un xss, je test mais je passe par zataz pour prévenir les administrateurs.
1  0 
ABCIWEB
Avatar de ABCIWEB
Expert éminent sénior https://www.developpez.com
Le 28/03/2013 à 19:55
Citation Envoyé par Clorge Voir le message
bref, c'est un token,
C'est pas simplement un token Cela fait aussi office de token mais c'est surtout une méthode qui permet de protéger son mot de passe sur le réseau !!! Sinon il transite en clair !

Citation Envoyé par Clorge Voir le message
de plus ta sécurité repose sur le fait d'avoir javascript d'activé, ce qui ne devrais *jamais* être le cas dans une application web.
Oui il faut avoir javascript activé pour pouvoir se connecter, mais non la sécurité ne dépend pas de javascript puisque sans javascript activé le formulaire ne sera simplement pas envoyé (et un message indique dans ce cas qu'il faut activer javascript).
En d'autres termes cela restreint l'authentification aux seuls visiteurs ayant javascript (activé ou pouvant être activé soit plus de 99.99% des cas). Mais l'utilisation de javascript ne pose pas ici de problème de sécurité en soi, c'est même exactement le contraire puisque cela permet de hasher le mot de passe + sel côté client avant de l'envoyer dans les tuyaux
1  0 
rodolphebrd
Avatar de rodolphebrd
Expert confirmé https://www.developpez.com
Le 30/03/2013 à 11:00
Bonjour,
Citation Envoyé par Clorge
Que pensez-vous d'un captcha qui compte sur les sentiments ? Par exemple
Tuer un homme c'est :
-utile
-horrible
-drole
-nécessaire
Je pense que c'est une plaisanterie.
Mais j'y répondrais sinon en disant qu'un captcha basé sur des sentiments induit :
-des dérives
-des réponses erronées
-la potentiel fuite d'internautes

Quant la question que vous posez : tuer un homme peut éveiller des sentiments différents selon l'angle sous lequel on se place.

Un captcha doit être incontestable avec une réponse et une seule : comme de quelle couleur est la neige avec un choix entre blanc et noir.
1  0 
ABCIWEB
Avatar de ABCIWEB
Expert éminent sénior https://www.developpez.com
Le 30/03/2013 à 20:59
Citation Envoyé par Clorge Voir le message

Je ne conçoit peut-etre|surement pas correctement le fonctionnement du système, mais je reste les membres explorer cette voie si ils le souhaitent.
Ce que tu devrais retenir de cet échange c'est que quand on ne comprend pas un script, soit on ne le commente pas, soit on demande des explications, mais en tous cas on évite d'en tirer des conclusions pour les affirmer haut et fort.

Parce qu'en faisant ainsi :

1/ Tu peux tromper des débutants par des affirmations fausses (et il y en a une collection remarquable dans tes réponses sur le sujet).

2/ Tu force ton interlocuteur à passer sur le mode contradictoire (plutôt que pédagogique) ce qui risque d'être désagréable à ton égard, et ce faisant pour ne pas perdre la face cela t'incite à faire des réponses approximatives qui t'enfoncent à chaque fois un peu plus.
Remarque que c'est exactement le processus de déroulement de tes réponses. Et pour te charrier un peu j'ai bien envie de te demander si vraiment tu n'es pas un boot, parce qu'avec un comportement aussi prévisible on pourrait s'interroger...

Cela dit suivant le caractère et l'age de chacun, j'ai bien conscience qu'on peut s'amuser à adopter ce comportement en pensant qu'on apprendra toujours quelque chose. Peut-être mais pas toujours et à quel prix et avec quelle perte de temps ? Au final dans cet exemple j'ai plutôt l'impression que le bilan est que tu n'as rien appris et qu'au passage tes réponses peuvent induire de l'incompréhension et des contre sens pour les débutants.

Car enfin que veux-tu dire avec
Citation Envoyé par Clorge Voir le message

...c'est même pas un mini-mini ssl. Les données circulent donc en clair sur le réseau, hashé ou non.
Si tu ne vois pas la différence entre un mot de passe qui circule hashé et salé par rapport à un mot de passe qui circule en clair, tu as un vrai gros problème, surtout pour quelqu'un qui s'intéresse à des problèmes de sécurité. Dans le premier cas, pour retrouver le mot de passe il faudra lancer des calculs avec un temps de résolution imprévisible, dans le second cas c'est un cadeau gratuit instantané. Tu ne vois vraiment toujours aucune différence ? Pour le sniffeur qui veut connaître ton mot de passe c'est la même différence qu'entre se retrouver devant un excellent blindage ou une porte ouverte.
1  0 
Oluha
Avatar de Oluha
Membre chevronné https://www.developpez.com
Le 30/11/2005 à 16:07
il y a des failles de sécurité connues à vérifier, notemment au niveau des include en PHP.
Sinon, mieux vaut encoder login et password en MD5.

Je me suis aussi fait pirater la semaine derniere par des abrutis (y'a pas d'autres mots, c'est débile de pirater un site perso) mais pas moyen de trouver comment ils ont fait
0  0 
yiannis
Avatar de yiannis
Membre émérite https://www.developpez.com
Le 30/11/2005 à 16:23
et je rajouterai, si c'est un site dynamique:
- Faire attention aux injections SQL
- Faire attention aux formulaires (surtout a ce que l'on recupere)

la liste peut etre longue.....
0  0 
Avatar de
https://www.developpez.com
Le 30/11/2005 à 16:40
Ce que je fais, c'est garder un log des 100 dernières actions de chaque uilisateur, c'est à dire le nom d'utilisateur si connecté, le timestamp, l'ip, le phpsessid, la page visitée, les POST et GET.
Comme ça, tu peux voir si c'est un membre qui a semé le trouble et éventuellement voir comment il a fait et détecter les floods.
0  0 
Commenter Signaler un problème