Cours de sécurisation PHP

Je viens de donner un cours sur l’apprentissage des règles de sécurisation PHP.
Pour cela, j’ai donc mis en place un github avec un site rempli de failles. Le but étant pour les étudiants de  les identifier, et de les corriger. Si vous voulez y jeter un oeil: https://github.com/ynizon/securite-apprentissage

Voici en résumé la liste des problèmes que vous auriez du identifier:

Bases de données

Connexion à la base de données non en PDO (donc inutilisable en PHP 7). Injection SQL possible car les requêtes ne sont pas paramétrées mais concaténées.
Les requêtes SQL de suppression ne sont stockées pas au même endroit que les autres (dans un repository par ex) . Cela va poser des problèmes de maintenance.
Les mots de passe sont en claire dans la base de données au lieu d’un encodage avec salage.

Le code PHP front

Fichier article.php:
Failles javascript avec injection de code XSS si on envoie <script>alert(« ok »);</script>  ou <script>window.location.href= »http://www.google.com »;</script>
Toujours contrôler les données envoyés par l’internaute !

Les données passés en paramètre ne sont pas vérifiées (int pour l’id). On peut même appeler article.php?id=1 or id=2

Le backend

Page d’administration:
L’accès est possible directement sur la page admin/admin.php sans passer par la page de login. Pas de sécurisation de session.
Le formulaire de login est accessible via SQL Injection (mettre dans le password ‘ OR ‘1’=’1).

Pas de contrôle de token (CSRF), donc le lien vers la page de suppression est possible (on peut même supprimer des utilisateurs avec /admin/remove.php?mode=users&id=1).
Il faut contrôler que la requête a bien été demandée par l’utilisateur à l’aide d’un timestamp (token).

L’import de fichiers provenant d’urls distantes est non vérifiées (partie : images). Ici on pourrait carrément ajouter un script shell pour gérer le serveur comme le fameux wso.

Le répertoire backup est disponible et non protégé par un htpasswd avec les informations de la base (et en plus le répertoire est indiqué dans le robots.txt – idéal pour les outils de scan)

Le listage des contenus des répertoires est activé via htaccess (Options -Indexes).

La page iframe permet d’injecter du code distant via le paramètre GET[« iframe »].

Annexes

Les emails des utilisateurs ne sont pas contrôlés à l’enregistrement et affichés directement sur la page. Pas de captcha pour se protégér du spamming. La page admin n’est pas bloquée au crawl dans le robots.

Conclusion

Si vous parvenez à corriger tout cela, félicitations, vous aurez compris les pièges à éviter. Et n’oubliez pas que lorsque vous intégrer des plugins à un CMS, si les développeurs n’ont pas étés sensibilisés à la sécurité, il est possible que certaines failles subsistent rendant poreux votre site. C’est pour cela, qu’il est recommandé d’utiliser toujours le minimum de plugins.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.