Mot-clé - sécurité

Fil des billets

mardi, 1 décembre 2015

Contrer les robots spammeurs

 

captha.gifDès lors que votre site est référencé sur le web et comporte un formulaire (destiné à envoyer un mail, à commenter un article, à s'inscrire sur un site...), il s'offre telle une proie aux vautours que sont les spambots. Les robots spammeurs prennent en effet d'assaut de nombreux sites en complétant frénétiquement les champs de saisie qui se présentent devant eux. Ici, vous trouverez une liste de solutions en vue de contrer ce phénomène.

  • Ne pas écrire son adresse mail en clair sur un site ! Voici des solutions pour cacher un e-mail.
  • Placer un champ invisible dans le formulaire (display:none ou visibility:hidden en CSS) : les spambots tentent de tous les remplir. Si ce champ est rempli, vous êtes à peu près sûr de ne pas avoir affaire à un humain ((Attention, les lecteurs d'écran des malvoyants peuvent parcourir ce genre de champ. À vous de mettre en garde les utilisateurs pour qu'ils ne le remplissent.)). Toutefois, veillez à ce que le champ ait l'air le plus normal possible pour que les robots ne l'ignorent pas (évitez les name='leaveBlank', 'detectSpam' ou 'honeypot').
  • Vérifier l'email : l'envoi d'un lien pour confirmer la transaction est une option pertinente dans le cadre de l'inscription sur un site. Elle est plus rébarbative s'il s'agit simplement de publier un commentaire sur un blog.
  • Permettre aux utilisateurs de s'inscrire par l'intermédiaire des réseaux sociaux (Oauth) est aussi une solution pour ne pas se confronter aux robots. Mais il serait déplaisant de n'offrir que cette solution aux utilisateurs, car nombre d'entre eux préfèrent une inscription classique.
  • Poser une question telle que "Quatre plus six ?" ou "Quelle est la couleur de l'herbe ?" : il s'agit d'une solution accessible pour vérifier si vous avez affaire à un robot. Toutefois, elle est souvent dissuasive pour les utilisateurs qui n'en saisissent pas l'utilité.
  • Imposer un CAPTCHA visuel (image résistant aux dispositifs OCR) est une possibilité. Mais les CAPTCHAs sont rébarbatifs pour les utilisateurs et surtout non accessibles aux personnes souffrant de troubles visuels sévères ((Les aveugles et malvoyants ne sont capables de prendre connaissance du contenu d'une image que par l'attribut "alt" de l'élément HTML "img". En l'occurrence, les CAPTCHAS ne renseignent pas ce genre d'attribut, sous peine de prêter main forte aux robots spammeurs.)), donc à éviter dans la mesure du possible.
  • Imposer un CAPTCHA audio est une option intéressante, mais pas meilleure que la précédente. Le problème de l'accessibilité se pose en effet non seulement pour les sourds et malentendants, mais aussi pour les utilisateurs dont la carte son serait dysfonctionnelle...
  • Imposer un reCAPTCHA (Google) semble une option partiellement fonctionnelle en termes d'accessibilité. Certains lecteurs d'écran sont en mesure d'y accéder, d'autres non. Dans ce cas-ci, Google analyse si l'utilisateur est un robot ou non sur base des mouvements de la souris et de la manière dont les réponses sont saisies. Toutefois, cet outil est controversé, parce qu'il semble au passage se saisir des données privées de l'utilisateur à des fins publicitaires.
  • Vérifier si l'IP n'appartient pas à une liste noire via des outils tels que Project HoneyPot, Stop forum spam ou Botscout.
  • Bloquer les IP selon le lieu d'origine de "l'utilisateur" : la plupart des robots spammeurs émanent de Chine, Inde, Indonésie, Pakistan, Russie et Ukraine. Si votre site n'est pas destiné à un public international, envisagez de bloquer ce type d'IP d'emblée.
  • Bloquer une liste de mots-clés : si les contenus postés comprennent des termes inappropriés ou que, par exemple, 5 consonnes se suivent dans une chaîne de caractères, bloquez l'IP.
  • Dénombrer le nombre de tentatives d'écriture/d'inscription émanant d'une même adresse IP et prévenir le flood ou les attaques en rejetant l'IP pour une durée établie au bout de X essais.
  • Détecter la rapidité de complétion : les robots remplissent un formulaire en une maigre poignée de secondes après l'ouverture de la page. Des outils jQuery sont en mesure de calculer ce genre de délai, à vous de bloquer les faux-utilisateurs potentiels qui prennent moins de 5 secondes pour compléter et valider un formulaire.
  • Demander aux utilisateurs de fournir leurs motivations pour rejoindre le site et soumettre les réponses à l'appréciation d'un modérateur pour l'activation des comptes. C'est ultra ingrat et fastidieux tant pour les utilisateurs que pour les gestionnaires du site, mais c'est très sûr...
  • [CMS] Utiliser des solutions anti-spams telles qu'Akismet sous Wordpress ou Mollom sous Drupal.

Malgré toutes ces solutions, aucune ne garantit à 100% que vous soyez à l'abri d'attaques qui portent leurs fruits. L'évolution des robots est grandissante, il convient de veiller sans cesse pour adapter la sécurité de son site en conséquence.


Informations complémentaires

Sources

Enregistrer

dimanche, 22 novembre 2015

Renforcer la sécurité d’un site ou une appli web

alt="StickOfCelery (Deviantart) - SQL Wifejection"

Ci-après, les développeurs web et webmestres trouveront une liste sélective et concise ((Pour plus d'informations, consulter les sources au bas de l'article.)) de pratiques et recommandations permettant de renforcer la sécurité des sites et applications web. Le respect de ces principes ne suffit pas (un hackeur vaillant obtient souvent ce qu'il convoite), mais permet à tout le moins de ne pas laisser la porte grand ouverte...

CMS, forums, frameworks et autres outils "prêts à l'emploi"

  • Mise à jour constante de l'outil et de ses plugins / librairies.
  • Éviter de préfixer les tables avec leurs abréviations habituelles (wp_ pour Wordpress, jml_ pour Joomla, etc.).
  • Cacher autant que possible l'outil utilisé, en particulier dans la barre d'adresse.

.htaccess

Attention, le .htaccess est sensible ! Il convient de faire des sauvegardes du fichier au préalable, de tester une modification à la fois, et de veiller au fonctionnement de l'intégralité du système après avoir opéré chaque changement. L'altération du .htaccess mène vite à une "Internal server error" (500).

  • Register_globals à 0 / OFF / False pour empêcher l'accès aux superglobales telles que $_POST, $_GET, etc.
  • Interdiction de lister le contenu des dossiers et d'accéder à des fichiers spécifiques (éviter impérativement de faire ceci dans le fichier robots.txt qui passe plus volontiers en clair !)
  • Utilisation de la dernière version de PHP.

Fichiers et dossiers

  • CHMOD : Attribution de permissions d'accès restrictives aux dossiers (705/755) et fichiers (604/644) présents sur le FTP, dans la mesure du possible. Accès encore plus restrictif aux fichiers principaux tels que l'index du site et le style CSS (404/444).
  • Emploi de noms surprenants ((Cela va un peu à contre-sens des préceptes liés au code "propre" et aux lois du référencement, mais les robots spammeurs seraient paramétrés pour visiter des adresses comprenant certains termes.)) en particulier pour les pages qui comprennent des formulaires : éviter login, admin, contact, etc. (cela vaut également pour les attribut "name" des inputs : éviter name, (e)mail, subject, etc.).

Mots de passe

  • Les bons mots de passe comprennent au minimum 8 caractères, et présentent des lettres, des chiffres ainsi que des caractères spéciaux.
  • Scrupuleusement veiller à utiliser des mots de passe différents pour le FTP, la base de données, l'administration du site, l'authentification, etc.

Identifiants

  • Les CMS proposent souvent "admin" ou "administrateur" en guise d'identifiant. À éviter.
  • Éviter l'ID 1 pour l'administrateur.

Base de données et requêtes SQL

Cryptage

Pour un hashage sûr – de mots de passe en particulier –, préférer password_hash() et crypt() à MD5, SHA1 et SHA256.

  • Crypter le fichier de configuration ((Sécurité supplémentaire par rapport au CHMOD, au .htaccess qui en réduit l'accès et à l'extension .php qui ne permet pas d'afficher le fichier en texte brut.)).
  • Crypter les mots de passe.
  • Crypter les adresses e-mail.

Sessions

Plusieurs techniques permettent de prévenir les détournements de sessions :

  • Lier une adresse IP à une session peut-être une bonne pratique, à condition que les utilisateurs n'utilisent pas un logiciel comme Tor pour préserver leur anonymat :
$ IP = getenv ("REMOTE_ADDR");
  • Invalider l'ID de session après connexion de l'utilisateur (ou même après chaque demande) avec session_regenerate_id ().
  • Attribuer des tokens lors de la complétion des formulaires (ne jamais stocker les tokens dans des cookies !)

Vérification et validation

⚠ Principe fondamental : NE JAMAIS faire confiance aux données saisies par l'utilisateur ((Retenez que les fichiers, valeurs de session, données des cookies et données provenant de services tiers sont aussi des entrées étrangères !)).

  • Vérifier l'origine (émetteur) pour les envois de messages.
  • Vérifier le typage de ce qui est envoyé (is_string, is_int, is_bool, is_array...).
  • Vérifier si le contenu est autorisé (in_array).
  • Pour les comparaisons, recourir à l'identité (===) et non à l'égalité (==).
  • Limiter le nombre de caractères des données envoyées (varchar (x) et validation).
  • Échapper les contenus pour éviter les balises – <script> et <iframe> en particulier –, ainsi que ces signes ((Pour ce faire, abuser des fonctions PHP htmlentities, htmlspecialchars, strip_tags, addslashes et dérivées et/ou utiliser des RegExp. Attention, la fonction mysql_real_escape_string n'est visiblement pas sûre !)) :
< > : ; " ' & $ ! ? ~ ^ | @ # ( ) [ ] { }  _ - / \

php.ini

Moult paramètres peuvent être modifiés de manière à rendre le site plus opaque et plus sécure :

display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On
disable_functions

Toutefois, certains hébergements ne permettent pas de modifier ce fichier. Le .htaccess peut y subvenir en tout ou partie.

Surveillance

Les logs permettent de retracer les événements qui ont eu lieu sur le site ou l'application en ligne. Il peut s'avérer nécessaire de les analyser de temps en temps. Il est primordial d'y revenir après un désastre.

Tester la vulnérabilité de vos sites


Sources