Comprendre les failles de sécurité

Sujet épineux, déjà pas mal de lectures en la matière, je vais expliquer les failles car ce n’est pas le plus simple à comprendre.

Si vous préférez la vidéo, j’ai publié un tutoriel dans la section premium. Je vais tenter ici une explication généraliste la plus simple possible.

🔗 Disclaimer

Il ne s’agit pas de la sécurité en général, beaucoup trop de notions à voir ! Pour celles et ceux qui aiment les maths c’est +∞.

Celles et ceux qui bashent WordPress notamment à cause du dernier Giant leak et qui s’appeliorio Panama Papers oui y avait potentiellement du WordPress impliqué mais encore une fois à cause d’un plugin et on va pas refaire le sempiternel débat ici.

Je vous renvoie vers les concepts de Give and Take, Open Source, etc.

Enfin on ne sera même pas exhaustif sur les failles, on verra les principales, celles qu’il faut connaître absolument.

🔗 Par où prendre le problème ?

Bien souvent en matière de code c’est la philosophie du dév qui va expliquer ses choix.

Il y a presque toujours plusieurs façons de faire. Certains vous expliqueront qu’ils ont Free et qu’ils ont tout compris, ce qui n’est pas forcément [entièrement] faux mais ayons ici une approche pragmatique.

Un critère pour hiérarchiser les solutions peut être celui du plus court chemin, simplicité et efficacité, Terminé Bonsoir (dédicace à mon CTO ^^).

J’ai vu d’autres approches axées sur la menace, à savoir « qui aurait intérêt à » mais alors je vous dis tout de suite je la trouve tout à fait incomplète celle-là. Je dirais même plus : potentiellement mauvaise et si je caricature j’ai comme l’impression d’entrendre « oh ça risque rien ».

🔗 Bullet proof

On aimerait bien mais ça n’existera pratiquement jamais. Néanmoins, si je reprends la dernière approche évoquée sans la caricaturer on peut se dire qu’à partir d’un certain degré de sécurité, si on se fait pirater on aura d’autres problèmes plus important car le ou les attaquant(s) auront de fait du matos, du skill, etc.

Cela n’est pas du tout contredit par le fait que certains gamins arrivent à cracker des systèmes costauds, en général ces mômes sont assez doués.

Donc les techniques de sécurisation dans nos plugins ne garantissent en aucune manière un risque 0 mais bel et bien un risque réduit. C’est comme mettre un antivol à sa bicyclette, on se doute bien que ça peut être cassé mais c’est toujours mieux que de laisser en libre service en faisant confiance aux badauds.

Dernier point avant de passer aux failles en elles-mêmes : la sécurité du web c’est très ingrat, par définition, à la moindre faille, tout peut péter. Une faille peut se loger sur le serveur, sur le terminal de l’internaute, dans des plugins, dans des services tiers, etc.

On va juste essayer de ne pas faire des trous supplémentaires dans la passoire avec nos codes.

🔗 XSS et CRSF

🔗 XSS

La XSS est courante. Pour cross-site scripting mais on a mis un X pour éviter de confondre avec CSS. La notion est très large, il y a plusieurs types de XSS qui plus est.

Pour le dire simplement, la XSS de base, qu’on appelle réfléchie, c’est la possibilité d’injecter des balises HTML et des scripts sur une page web parce que le développeur n’a pas pris soin d’échapper et de nettoyer les données qu’il aura par exemple récupéré d’un formulaire avant des les afficher sur la dite page.

Ici, typiquement, on cherche à voler des informations personnelles et sensibles. Cela devient encore plus funky lorsqu’une base de données est impliquée, par exemple avec WordPress, car là la faille XSS peut devenir permanente ou stockée, et on cherchera par exemple à voler du cookie.


Un cookie en matière de code c’est comme un petit fichier .txt dans lequel on viendrait écrire des informations. C’est stocké sur le terminal de l’internaute et ça sert par exemple à vous identifier automatiquement sur votre site WordPress ( la fameuse popup « enregistrer le mot de passe » de votre navigateur).


Quiconque possède ce cookie dispose d’informations souvent sensibles comme un login/mot de passe sur un site WordPress :

Sésame, ouvre-toi

🔗 CRSF

La Cross-Site Request Forgery. Se combine très bien à la précédente et consiste à usurper une identité. Concrètement, je vais pouvoir perpétrer des actions sans pour autant disposer du rôle et des permissions nécessaires.

Hein ? Alors, il m’est déjà arrivé de voir des intranets construits à la main par des étudiants où l’on peut directement lancer ce type d’attaque, genre je me rends sur http://monsite.com/admin/posts?action=delete_all et on fait tourner les serviettes.

Mais ici on va parler sérieusement, a priori je ne peux pas faire ce genre d’action si le code est fiable, ce qui est relativement le cas de base pour les rôles WP. Je ne peux pas, certes, mais un administrateur enregistré lui le peut. Ma cible est donc repérée et je vais profiter de son compte et de ses privilèges d’administrateur pour foutre le bazar.

Comment ? par exemple en lui envoyant un lien cracké, scripté, ce que vous voulez, et qui va lui faire réaliser, à son insu et surtout en son nom, certaines actions.

🔗 Injection SQL

Comme son nom l’indique, on va aller injecter du code malicieux dans une requête en base qui n’a pas ou qui a mal été préparée. Toute requête peut être déviée de son but initial, ça reste du langage. Les hackers aiment bien passer par des biais tels que 1=1 ou des liaisons entre tables.

Pour faire simple, j’utilise 1=1 car cette condition est toujours vraie. Quiconque connaît le langage peut le détourner. Donc pour parler vrai, car les Français veulent savoir, et je les comprends, j’ai un formulaire qui fait une requête en fonction d’un login – mot de passe. Je vais faire un SELECT sur ma table users avec un WHERE login = ‘machin’ et un password=’truc’. Ici « machin » et « truc » me sont transmis par des variables lors de la soumission du formulaire.

Sauf que moi je vais lui envoyer « ‘OR 1=1# » en tant que login donc une condition toujours vraie et je vais commenter la suite du code de la requête avec mon dièse. La requête va devenir « sélectionne-moi tous les utilisateurs ». C’est chaud ! J’étais parti sur les infos d’un utilisateur authentifié et je récupère les infos de toute la table.

🔗 Ok, c’est chaud, comment se protéger ?

Encore une fois, ici on sécurise nos dévs un minimum, on ne se lance pas dans la sécurisation complète d’un site, il y aurait beaucoup d’actions supplémentaires à faire dans ce cas.

On est opensource, on élimine nos failles, ça n’empêchera pas les sites de se faire hacker, à cause d’autres plugins mal codés ou de failles côté serveur, mais ça réduira les risques et on évitera de figurer dans la prestigieuse liste des maillons faibles.

🔗 Vaincre la XSS la CRSF ?

Commencer par ne pas faire confiance à l’utilisateur c’est la base. Ensuite, utiliser les APIs WordPress dédiées :

Pour la CRSF ne pas se reposer sur vos lauriers. Les rôles et permissions WP c’est une chose mais ce n’est pas suffisant. Dans le cadre de vos formulaires, pensez bien aux nonces qui permettent de s’assurer que c’est bien l’utilisateur en cours de session qui initie l’action et non un vil manant qui imite sa signature ^^.

🔗 Buzzkill à l’injection SQL

Dans vos dévs WP vous passez par la classe WPDB, n’oubliez pas la méthode prepare() qui va faire pour vous le SQL escape. WP facilite les choses avec cette méthode qui vous permettra de vous assurer que la variable que vous passez dans la requête est bien une chaîne de caractères ou un entier et s’occupera des caractères spéciaux.

🔗 La veille

Le sujet est en constante évolution, les hackers ont toujours quelques métros d’avance, tenez-vous au courant, suivez par exemple ces spécialistes :

🔗 Conclusion

Fermez la porte, ne laissez pas n’importe qui entrer, ne faites confiance à personne ^^. Cela ressemble à un début de paranoïa mais en matière de sécurité, ce n’est pas le plus terrible des défauts.

Vous seriez surpris des motifs et surtout des profils et des intentions des hackers qui crackent vos codes. On est loin des caricatures hollywoodiennes, le motif pouvant se résumer à « parce que je peux le faire » dans certains cas donc n’allez pas penser que parce que vos plugins n’incluent pas de systèmes de paiement ou ne traitent pas de données « trop sensibles », ou encore ne sont pas installés sur des sites majeurs à fort trafic, vous seriez exemptés de ce travail de sécurisation.

Seule l’expérience et la connaissance approfondie des langages de programmation et du C.M.S. que vous utilisez pourront vous guider pour faire les bons choix.

Débutant(e)s, intermédiaires, confirmé(e)s, séniors, tout le monde est concerné. C’est la raison pour laquelle il faut réagir rapidement si on vous signale une faille sur un de vos plugins a fortiori si celle-ci est critique.