Que se passe t’il sans quelques règles élémentaires de sécurité ?

Quand il est question de sécurité pour les sites internet, il est souvent nécessaire de relativiser. Avoir un site 100% étanche à tous les types de failles est une tache infinie et dit le tout de suite, généralement inutile. Néanmoins, je pense qu'il reste vital de réfléchir au moins 2 secondes avant d'écrire son code.

 

Pourquoi cet article ?

La découverte qui m'a fait écrire cet article est celle de cette recherche Github sur le terme exec($_GET .

J'explique pour ceux qui ne parlent pas PHP.

$_GET est un tableau qui contient toutes les valeurs envoyées depuis les URL des pages. Vous savez, les choses comme ça : index.php?page=4 . Dans cet exemple, $_GET["page"] vaut "4".

exec(); est une commande qui demande à PHP d'exécuter une chaîne de texte comme si c'était une commande pour le serveur.

Résultat des courses avec l'exemple précédent : n'importe qui peut exécuter des commandes depuis votre site simplement en les mettant dans les URL.

Évidemment, je ne dis pas que ce genre de choses se trouve dans le code que vous produisez, ou dans celui que vos prestataires produisent. Je dis juste que ce code se trouve dans 99 847 dépôts Github. 

Près de 100 000 dépôts open source possède cette faille évidente.

Le développement Web peut sembler simple : beaucoup de ressources et de moyens d'apprendre, beaucoup de clients, il est finalement assez simple en cherchant un peu et en prenant le temps de monter un site avec un peu d'expérimentations.

Mais le développement web a une autre particularité : votre produit est sur votre serveur, accessible à tous. Contrairement à du développement logiciel (où les hackers peuvent modifier leur version uniquement) la même instance est disponibles pour tous. Une négligence de votre part peut donc mener à une punition globale pour tous vos visiteurs.

Pour la sécurité de tous, je vais donner ici quatre toutes petites règles élémentaires que tout le monde se doit de connaitre.

 

N'exécutez jamais du code venant du navigateur

L'exemple exec($_GET[… en PHP est un bon exemple. Avec une faille comme cela, un hacker à accès à tout le système (dans la limite de l'utilisateur exécutant le code Php, souvent www-admin).

Selon le reste du système, il serait simple de faire chauffer le serveur ou remplir les disques, mais aussi zipper entièrement votre site et se l'envoyer par mail. De cette manière, il sera beaucoup plus simple de découvrir d'autres failles, ou vos accès SQL et donc toutes les donnes de vos utilisateurs.

La solution : ne pas utiliser exec en production semble un bon compromis. Plus sérieusement, vérifiez que le contenu du get est dans une liste blanche est un strict minimum.

N'envoyez jamais du code venant du navigateur dans une base SQL sans le nettoyer

Le code SQL est bête. Mettez un ";" a la fin d'une commande et vous pouvez souvent engager une autre commande. Que se passerait-il par exemple si un utilisateur mettait comme pseudo : hackerz';DROP DATABASE; ?

Réponse : rien du tout, ce code n'est pas valide, et il n'est pas possible de chainer un drop avec mySQL. Je pense que vous avez néanmoins compris le message.

La solution : mysqli_real_escape_string

N'affichez jamais sur votre site du code venant du navigateur sans en enlever les balises HTML

Pouvoir utiliser du HTML dans un commentaire sur votre blog est une idée que vous trouvez génial . Je respecte ce point de vue. Et bien entendu, vous avez pris soin de supprimer les balises script, tout de même. Non ? Que se passera t'il si quelqu'un entre le commentaire ci dessous ?
<script>window.location.replace("http://stackoverflow.com");</script>

La solution : nettoyer les commentaires de tout ce que vous ne voulez pas sur votre blog, ou utilisez un langage comme le markdown ou le bbcode pour limiter les abus.

Ne linkez jamais une ressource Javascript distante

Vous avez trouve une ressource cool. Quoi de plus simple que de la linker directement ? ça sera beaucoup plus rapide que de la télécharger pour la passer par le FTP. Sauf que le propriétaire de la ressource peut s'en rendre compte, et par là envoyer du Javascript sur votre site, pour par exemple récupérer les cookies de vos visiteurs, leur afficher de la pub, ou les rediriger sur Youporn. À éviter.

La solution : Toujours télécharger les ressources pour les héberger sur votre site, ce n'est pas plus compliquée que cela.

 

Le mot de la fin

Ces 4 points ne sont évidemment pas les seules failles de sécurité évidentes que vous pouvez laisser trainer dans votre code, mais ce sont pour moi ceux qui releve le plus de la negligence : il est tellement aise de les corriger que les laisser passe a mes yeux pour une faute professionnelle.

Un des points précédents fait partie d'une de vos habitudes ? Je vous conseille de repasser sur votre travail pour essayer de corriger tout cela. 

Deux ou trois de ces points font partie de vos habitudes . Il serait peut-être temps de montrer votre code à un professionnel (ami, collègue, stackoverflow, on connaît tous un développeur !) pour avoir un avis objectif sur vos failles.