J'espère que comme moi vous avez passé un bon réveillon, qu'il ait été entre amis, en famille ou en galante compagnie.

Pour ceux d'entre vous qui disposent d'un compte sur le site, vous avez reçu un email-carte de voeux. Puisse cet email en HTML5/ SVG/ CSS3 animé vous avoir plu.

Pour tous les autres, je vous souhaite une bonne année 2012 et mes meilleurs voeux

C'est une problématique à laquelle est confronté chaque webmaster.
Il y a plusieurs niveaux de vulnérabilité; nous considérerons que l'hébergeur auquel vous louez votre espace web fait son travail correctement et s'assure de la sécurité des logiciels qu'il met à votre disposition. Il convient donc à votre tour d'être regardant sur ce que vous mettez en place. Notamment si vous utilisez des scripts ou logiciels tiers (forum, ...), mettez-les à jour; le fait qu'ils soient très répandus attise l'intérêt des pirates qui peuvent exploiter une même faille sur un grand nombre de sites.

Intéressons-nous maintenant à vos propres pages web.

Il existe de nombreuses manières de se préserver des attaques; elles répondent généralement, à une grande règle : ne jamais faire confiance à l'utilisateur.

Une règle qui peut se comprendre sous différents angles, dont les principaux :
- ne pas fournir d'information qui puisse être une base d'attaque pour un pirate
- ne pas faire confiance au contenu soumis par un utilisateur ni à l'utilisation qu'il à de votre site web

Ne pas fournir d'information qui puisse être une base d'attaque pour un pirate

Une liste exhaustive serait un peu longue, mais cela se résume généralement à :
- ne pas afficher les erreurs que pourraient produire des scripts (mais les écrire sur le disque pour consultation et traitement ultérieur). Cela évite d'afficher des chemins vers des cripts et des versions logicielles, voire des informations sur l'erreur elle même qui pourrait être exploitée.
- restreindre l'accès aux différents répertoires; un utilisateur n'est pas supposé voir l'architecture de votre site internet (cela peut être fait via la mise en place de fichiers index, pour empêcher l'indexation d'un répertoire, ou mieux, via htaccess).

Ne pas faire confiance au contenu soumis par un utilisateur ni à son utilisation

Les formulaires
- on pense tout de suite aux formulaires, dont il faut se prémunir du contenu actif (html, javascript, sql); votre langage de prédilection possède sans nul doute des fonctions natives qui peuvent assurer ce travail.
- mais la vérification passe aussi par celle du contenu lui-même, en particulier sur la forme (emails, par exemple, vérifiables par des expressions régulières) et le type (entiers, souvent).
- il est très aisé d'utiliser son propre formulaire; il faut donc s'assurer que les valeurs soumises correspondent à un état attendu et penser aux effets de bord (ce n'est pas parce que vous recevez un formulaire bien construit pour insérer un commentaire pour la news n°455, que cette news existe). Si votre base de données prend de l'ampleur sans que rien de particulier n'appraisse sur votre site, ce peut être ce genre d'attaques.
- le reload fou... Cela ne vous est-il jamais arrivé de voir un poste en double sur un site internet ? Cela arrive généralement quand un rechargement (volontaire ou non) est fait par l'utilisateur postant un formulaire. C'est l'une des peurs lors de l'utilisation des sites de e-commerce. Qui aurait envie de voir son compte débité 2 fois pour un même achat ? En revanche c'est une attaque très simple pour du spam, puisqu'il suffit d'avoir mis en défaut les sécurités du site une fois pour poster le même spam indéfiniment. La solution est simple, donner une validité unique au formulaire, via un jeton. Ce jeton valide dans une unique session, expire après sa première utilisation.


Les URLs

Elles ont beaucoup de points communs avec les formulaires, d'ailleurs la méthode GET des formulaire permet de de les soumettre ainsi. Ainsi quelque chose valable pour un formulaire, l'est souvent pour une adresse.
- il faut s'assurer d'ôter le contenu actif et vérifier le typage des variables, qui naturellement sont initialement des variables sous forme de chaînes de caractères.
- il faut s'assurer que les paramètres non-attendus n'aient pas des effets indésirables (identifiants nuls, négatifs, au-delà de la plage de valeurs attendues...). L'identifiant "0", "a", ou "-1" pour un utilisateur ou une news a-t-il un sens ? Et si ce n'est pas le cas, comment réagit votre système ?
- il faut impérativement, que toute url aboutissant à une modification/ suppression de donnée soit couplée d'un jeton unique, lié a une session, afin de ne pas être piégé par une faille de type csrf.
- une des failles les plus souvent commises par les débutant est la mauvaise utilisation de l'inclusion à partir de paramètres de l'adresse. Un "include" (ou "require" et assimilés) doit toujours faire référence à un fichier interne au site et correspondant à un certain schéma, ie, n'importe quel fichier du site ne doit pas pour autant pouvoir être inclus, sous prétexte qu'il est spécifié par l'url et qu'il est dans l'arborescence du site. À cela, et comme dans tous les cas de restrictions d'accès, se présentent deux solutions, qui bien que conceptuellement opposées, aboutisse aux exigences espérées :
- refuser tout accès, puis autoriser nominativement certains accès. C'est la version la plus sûre, mais la moins dynamique. Puisque le besoin d'un nouvel accès nécéssite la modification des autorisations. L'exemple typique est le switch-case qui teste si la variable en paramètre est bien dans la liste des cas attendus. Chaque fois que vous ajoutez une page, il faut ajouter un cas.
- autoriser tout accès, puis refuser nominativement certains accès. Il faut être vigilant à ce qu'aucune page interdite ne soit oubliée; mais l'ajout d'une page (sauf si elle est interdite) ne nécessite aucune modification des autorisations. L'implémentation resulte souvent en un test pour s'assurer qu'il ne s'agit pas d'une des pages interdites. Puis que le fichier existe.


Le client

Si l'on comprend assez facilement que seul le serveur peut être considéré comme sûr (relativemeent), on trouve encore trop de mécanismes de sécurité côté client. Cependant, aucune protection ne doit être implémentée du côté client :
- le javascript a pour vocation l'enrichissement de l'expérience utilisateur, et est facilement désactivé, voire non-interprété par les robots. Une protection côté client étant surmontable sans difficulté, elle nécessite une redondance côté serveur.
- les cookies (à moins de chiffrer leur contenu) qui sont éditables ne doivent pas contenir d'informations essentielles.


Sécurité complète, sécurité partielle

Je vais maintenant introduire une notion pour distinguer 2 types de sécurités :
- il y a la sécurité que je qualifierais de "complète". En elle-même elle suffit (si elle est bien mise en place) à s'assurer qu'un type d'attaques ne peut plus s'effectuer. Nous prendrons par exemple le fait de transcrire tout caractère reconnu comme appartenant au html en entité html. Il n'est plus possible de subir une attaque visant à utiliser du html si le contenu n'est plus actif.
- il y a aussi une manière de sécuriser un site que je qualifierais de "partielle", car elle est liée (de près ou de loin) à une notion de complexité. Les exemples sont nombreux, mais sont en grande partie implémentés pour la lutte anti-spam (l'utilisation d'un captcha par exemple). Toute mise en place de ce type de sécurité est par nature vouée à l'échec et n'assure qu'une relative sécurité (néanmoins, généralement suffisante pour écarter l'essentiel des attaques). S'il s'agit d'écarter les attaques d'un robot généraliste, cela fonctionne assez bien, en revanche, un tel système sera mis en échec par une attaque ciblée.


La lutte anti-spams

Elle peut être apréhendée selon différents critères, spécialement l'automatisme.
- modération à priori : dans le cas, où l'on désire s'assurer que chaque message dispose d'un contenu qui convient, les messages sont validés par un modérateur. Cependant, cette méthode nuit au dynamisme.
- modération à posteriori : c'est-à-dire, corriger le mal une fois fait. C'est une solution insuffisante, mais qui doit cependant toujours être proposée au cas où toutes les autres sécurités aient été mises en défaut. S'offre alors la possibilité de supprimer l'information ou de la cacher (un champ booléen de visibilité en base de données).
- la limite de posts. Tout est imaginable quant à l'algorithme. Nombre de posts limité pour un utilisateur, pour un temps donné, temps entre 2 posts successifs, nombre de posts intermédiaires...
- le captcha : la solution la plus communément utilisée. Et pourtant leur sécurité est sérieusement mise à mal. Néanmoins, les robots les moins sophistiqués sont pris au piège. Quels sont les conseils à prendre en compte et les pièges à éviter si vous utiliser un captcha ?
- créez-le vous même, si vous utilisez un captcha répandu, vous prenez le risque qu'il soit cassé facilement.
- l'utilisation de minuscules et majuscules est parfois à l'origine de confusions pour l'utilisateur, néanmoins soyez conscients que plus votre captcha aura de symboles, et plus il sera complexe.
- faîtes varier le nombre de caractères, mais ne fournissez pas d'information sur votre captcha. Un captcha a une taille fixe, et non dépandante des données qu'il contient. Si l'attaquant est capable, par la taille du captcha, de déterminer le nombre de symboles à décoder, vous lui simplifiez la tâche.
- ne gardez pas un espacement fixe, sans quoi votre captcha peut être découpé pour traiter chaque symbole.
- ne placez pas vos symboles sur une même ligne horizontale, mais faîtes varier les coordonnées verticales. La détection d'un caractère ne doit pas donner d'indication sur la place du suivant.
- changez le fond, en formes, en couleurs et en contrastes. Si cela peut rendre difficile la lecture de votre captcha, proposez d'utiliser un autre captcha.
- en plus du fond, faîtes varier (aléatoirement) les couleurs des éléments. Un captcha est généralement attaqué après transformation en noir et blanc ou bichromatique; si vous utilisez des couleurs particulières, vous affaiblissez ses capacités.
- si vous le pouvez, déformez les éléments, faîtes varier leur taille, leur orientation. La détection d'un symbole se fait par ressemblance avec un autre. Plus la différence est importante, plus grande est la complexité pour retrouver le symbole initial. Utiliser une police que vous aurez vous même développée complique très fortement la reconnaissance des caractères pour un robot généraliste.
Adopter un captcha qui répond à toutes ces exigences ne vous assure pas qu'il sera incassable, mais, plus votre captcha aura d'entorses à ces règles et plus son efficacité sera remise en cause.
- détection des robots via un pot de miel. C'est-à-dire, un champ qui à pour vocation de recevoir une adresse email, mais qui est caché par javascript/ css. S'il est rempli, considérez qu'il s'agit d'un robot, et que la validation du formulaire peut être oubliée.
- validation d'un post par un email envoyé à votre utilisateur et contenant un lien avec une clé d'activation. Cette méthode est assez efficace.
- utilisation de black-lists d'IPs. On trouve sur le web des listes d'ip appartenant aux robots spammers. Une confrontation de l'IP de votre utilisateur avec cette liste (qui se doit d'être mise à jour) peut vous donner des indications sur la suite de votre validation. Vous pouvez par ailleurs alimenter cette black-list des IPs d'attaquants.
- analyse du message. Cette solution qui peut être plus ou moins complexe à mettre en place consiste à analyser le contenu d'un message. Ce message peut être confronté à une liste de mots associés à ce que peut contenir un spam (les termes sont souvent les mêmes); le nombre de liens externes, ou encore la langue utilisée, peuvent aboutir à une notation du message qui, selon sa valeur, ne sera pas conservé, sera mis en attente de modération, ou sera validé.
- la lutte anti-spams consiste souvent en le cumul de différentes solutions, ou leur hybridation.


Conclusion

Il s'agit ici des attaques les plus courantes, et de quelques solutions pour s'en préserver, mais quelles que soient les solutions que vous aurez mises en places pour assurer la sécurité de votre site web et des données qu'il contient, pensez à régulièrement faire des sauvegardes de vos bases de données. Un problème côté serveur, ou une faille qui vous aurait échappée ne doit pas mettre en péril la pérennité de votre site web.
Il n'y a pas de secret, plus que tout, le meilleur moyen de se prémunir d'une attaque, c'est de savoir comment l'orchestrer.


Pourquoi cet article ?

Une personne de mon entourage (avec laquelle je suis en froid) a eu l'ingénieuse idée de m'accuser de poster quelque chose comme une dizaine de spams sur son site. Si l'idée même qu'elle puisse penser que je serais capable de m'abaisser à cela me déçoit, j'aimerais lui rappeler que je lui ai fait part d'un grand nombre de failles et de soucis de sécurité sur son site, allant même jusqu'à lui montrer que son captcha était cassable sans effort et que le complexifier lui éviterait des ennuis sur le long terme. Heureusement, certaines de mes remarques ont été prises en compte à l'époque, mais pas toutes; peut-être parce que cette personne peut vous dire de manière hautaine qu'elle a "plus d'XP" et qu'elle n'a rien à apprendre de vous ? Je lui retorquerais à présent que si elle a un diplôme que je n'ai pas, en ce qui concerne l'expérience (en nombre de lignes de code, en nombre de projets), il en est bien autrement.
Des attaques sur mon site, comme tout site qui est référencé par suffisamment de moteurs de recherche ou d'autres sites, il y en a; plus d'une vingtaine (du moins pour celles qui sont suffisamment élaborées pour que j'en garde des traces) ce mois-ci, dont l'essentiel cette dernière semaine, pour autant, je ne crie pas au loup, je n'accuse personne, je mets juste en place des mécanismes pour me permettre d'identifer les attaques, si possibles les attaquants, et m'assurer qu'ils ne feront rien qui ne me soit préjudiciable. Je n'ai pas pour habitude de faire aux autres ce que je n'aimerais pas que l'on me fasse, et en l'occurence, je n'aimerais pas retrouver mon site détérioré d'une manière ou d'une autre. Éprouver une faille ou un mécanisme de sécurité et passer outre, c'est un défi qui peut être intéressant, l'exploiter, non.

Si HTML5 apporte au web une dimension sémantique accrue, il cache aussi des petits trésors plein de promesses. Je pense notamment à la balise <input> qui se dote d'un attribut type dont l'ensemble des valeurs est fortement enrichi.

Intéressons-nous à la valeur email, cette dernière, explicite, définit un champ texte prêt à accueillir un email. Si vous fournissez une valeur invalide et que votre navigateur a implémenté le type email, une notification apparaîtra, pour vous inviter à saisir une nouvelle valeur.
(Évidemment, cela ne veut pas dire que sous prétexte d'avoir codé en HTML5, on peut se passer de vérifier la valeur du côté serveur.)

Le type email : une arme anti-spam

Pour au moins deux raisons. La première est que les robots spammeurs sont peu nombreux à connaître ce type et que l'on réduit donc de fait le nombre de robots qui pourraient être une menace.

Cela n'est cependant qu'une question de temps avant que le HTML5 ne se démocratise suffisamment pour que les robots soient rendus compatibles. Mais alors, les champs de type email seront tout de suite identifiés ? Contre toute attente, c'est bien ce que l'on recherche.
Une des manières de se prémunir des attaques de robots est de mettre en place un pot de miel; c'est à dire une zone que seuls les robots remplieront.
Il suffit alors de créer 2 champs de type email, l'un sera validé, l'autre caché par css ou javascript et invisible à un visiteur "humain". Si à un moment le champ pot de miel est rempli, nul besoin de traiter le formulaire, il s'agit d'une attaque.

Retour au design précédent celui d'Halloween, enfin presque, puisqu'il s'agit d'une variante plus sombre du premier.

Le site se revêt des couleurs d'Hallowe'en.