Comme beaucoup de frameworks, Symfony comprend des fonctionnalités de sécurité. Symfony est plutôt robuste par défaut, mais ce serait tout de même une erreur de s’appuyer entièrement sur cette réputation pour assurer la sécurité d’une application.
Parce que chaque application est différente, le contexte de sécurité est différent lui aussi. Les développeurs ont donc toujours un rôle important à jouer pour s’assurer que tout est bien configuré et testé.

Filtrage des inputs, authentification, gestion des sessions… Cette série d’articles aborde les différentes mécaniques que tout développeur Symfony peut utiliser, afin d’assurer la sécurité et la fiabilité de l’application qu’il développe.
Et parce que “built-in security” ne signifie pas que tout est déjà fait, nous verrons quelles sont les choses réellement importantes, et les pièges classiques.

Mis à jour : 23 Déc 2020

Cet article ne remplace pas de bonnes connaissances en PHP, mais peut vous donner de réels bons conseils pour booster votre sécurité.
Il n’y aura ici rien à copier/coller directement dans vos fichiers PHP. Cependant, nous croyons que ces conseils et bonnes pratiques vous apporteront des bénéfices à long terme, en comprenant et en appliquant les différents points en fonction de vos besoins et de votre contexte.

Cet article est le troisième de notre série dédiée à la sécurité pour PHP.
Le premier article vous donne des indications pour la configuration de PHP, les mises à jour, le filtrage des données, ainsi que l’organisation du code.
Le second article traite de la protection contre les attaques les plus courantes.

Nous allons maintenant traiter des risques liés aux cookies, uploads, CRSF ainsi que de la sécurité par l’obscurité.

Mis à jour : 23 Déc 2020

Cet article ne remplace pas de bonnes connaissances en PHP, mais peut vous donner de réels bons conseils pour booster votre sécurité.
Il n’y aura ici rien à copier/coller directement dans vos fichiers PHP. Cependant, nous croyons que ces conseils et bonnes pratiques vous apporteront des bénéfices à long terme, en comprenant et en appliquant les différents points en fonction de vos besoins et de votre contexte.

Cet article est le deuxième de notre série dédiée à la sécurité pour PHP. Le premier article “Protéger votre site : Bonnes pratiques de sécurité pour PHP #1” vous donne des indications pour la configuration de PHP, les mises à jour, l’organisation du code ainsi que le filtrage/échappement des données.

Nous allons à présent examiner les attaques les plus courantes, ainsi que les moyens de s’en défendre.

Mis à jour 1. Déc 2020 PHP reste le langage de programmation côté serveur le plus populaire : il est utilisé par presque 80% des sites (source). Ce langage continue à être développée, et PHP 8 a été publié la semaine dernière ! Cette version apporte de nouvelles fonctionnalités et devrait renforcer la sécurité. Cependant, la sécurité de PHP se construit dès ses fonctionnalités centrales ‘historiques’. L’article qui suit ne remplace pas de bonnes connaissances en PHP,…

Mis à jour 16 fev. 2021

Faille logique

Les failles logiques restent un type de vulnérabilités méconnues dans la sécurité informatique. Ce ne sont pas des erreurs dans le raisonnement logique. Il s’agit de failles liées au fonctionnement d’une application web. Elles diffèrent des vulnérabilités techniques, qui elles, sont directement liées à des erreurs de code, d’implémentation ou de configuration.

Nous trouvons régulièrement ces vulnérabilités de logique business lors de tests d’intrusion, sur tout type d’applications. Généralement, les sites ecommerce et les logiciels SaaS sont les solutions où ces vulnérabilités se retrouvent le plus fréquemment.

Qu’est-ce que 2FA

2FA signifie Two Factor Authentication (authentification à deux facteurs). Il s’agit d’un moyen permettant de renforcer un processus d’authentification.
Un exemple de ce type d’authentification se trouve sur de nombreux sites de banques, sur les fonctionnalités critiques telles que la réalisation de virements bancaires. Suivant votre banque, celle-ci peut vous envoyer un code via SMS, que vous devez recopier sur le site web afin de confirmer le virement.

Le second facteur utilisé peut être un téléphone, un objet physique en votre possession, une caractéristique physique (biométrie) ou un secret que vous seul connaissez.

Un process 2FA comprend quelques inconvénients : il rend le processus d’authentification plus complexe, et le second facteur doit impérativement être “disponible”, ce qui peut constituer un problème avec les téléphones mobiles. Batterie déchargée, mauvaise couverture réseau ou tout autre problème peuvent empêcher le processus de fonctionner correctement.

L’intérêt d’un web application firewall

Si vous ne voyez pas exactement la différence entre un firewall “classique” et un WAF (web application firewall), je vous conseille de consulter un article précédent, expliquant les différences : Firewalls traditionnels ou Web Application Firewalls?
Les menaces pesant sur les applications font des web application firewalls une approche véritablement complémentaire aux bonnes pratiques de développement et aux tests de sécurité (audits).
La protection globale qu’ils apportent contre les attaques connues (et non connues), le patching virtuel et le reporting d’événements liés à la sécurité ont une vraie valeur ajoutée.

Les firewalls traditionnels ont pour but de protéger des environnements informatiques contre les attaques, en autorisant ou en bloquant certains services.
Ces firewalls contrôlent le trafic réseau entrant et sortant, en se basant sur une série de règles.

Voici un exemple simple :
Supposons que votre entreprise possède un serveur web dans son infrastructure informatique. Afin de rendre le serveur web accessible depuis l’extérieur de votre entreprise, certaines règles devront être définies pour autoriser le trafic web vers et depuis ce serveur.
Certains “ports” seront ouverts, pour une adresse IP (celle de votre serveur web).
Votre entreprise peut choisir d’autoriser seulement le trafic web, ou d’autoriser un autre type de trafic en fonction de ses besoins.

La sécurité peut impliquer de lourds investissements en termes de développement web.
Mais certains petits ajustements peuvent aussi vous permettre une avancée significative en matière de sécurité. Ces modifications sont minimes en termes de code et de configuration, mais elles requièrent une bonne analyse et une validation avant d’être implémentées. Il s’agit des headers HTTP.

Il y a quelques années, on se posait la question suivante : faut-il faire tester la sécurité de son site web ? A présent, la question est devenue : à quelle fréquence faut-il effectuer des tests ? Cette réflexion vaut pour les sites internet ainsi que pour les applications mobiles et les logiciels développés à partir de technologies web. Bien que la partie systèmes et serveurs mérite elle aussi d’être sécurisée, nous nous focalisons ici sur la partie applicative qui rattrape progressivement son retard dans le domaine.

Alors que le nombre de piratages augmente, les pare-feu applicatifs (web application firewalls) et les filtres sont de plus en plus plébiscités. Ces outils permettent de renforcer la sécurisation de vos applications web. Comment fonctionnent-ils? Quelles sont leurs différences? Voici une brève introduction sur le sujet.