Quelles solutions techniques pour améliorer la performance de votre site web ?
change de nom...
La sécurité est une question centrale des directions informatiques qui intervient souvent en cas d'attaque. Or cette question doit se poser dès le développement; elle couvre aussi bien la partie applicative que la partie serveur.
Alors, comment se prémunir des failles ? Quel CMS choisir? Quelles procédures mettre en place?
Dans cet article, nous verrons:
Source : https://cve.mitre.org
Voici les failles de sécurité dont on fait particulièrement attention lorsque l'on créé des ressources accessibles à distance ou bien des formulaires, qu'ils soient public (formulaire de recherche ou de login par exemple), ou bien privé avec des formulaires provoquant des enregistrements en base de données.
On peut parler ici des basiques de la sécurité Web :
Par la saisie de morceaux de commandes SQL au sein d’un formulaire (connexion, recherche, contact ...), la volonté est de détourner la requête qui devait être exécutée afin de modifier ce qu’elle était censée faire. Les possibilités de supprimer des données, de se connecter sans mot de passe ou bien d’accéder à des informations protégées peuvent en être les principales motivations.
L'utilisation d'un ORM permettant d'intégrer une couche abstraction pour l'accès aux données permet notamment de se prémunir de ce type de faille. Chez Codéin, nous utilisons notamment l'ORM Doctrine intégrée au sein du framework Symfony.
Les faille XSS (l'acronyme CSS étant déjà utilisé) consistent à de l’injection de code Javascript au sein d’un formulaire mal protégé.
Il existe 2 types de faille XSS:
L’utilisation d'un framework permettant de sécuriser la récupération des données et leurs enregistrements en base de données permet de se prémunir de ce type de faille.
La faille CSRF permet de faire exécuter par un tiers une action via une URL dont il n'a pas les droits d'accès (ex : la suppression d'une donnée particulière, le rajout d'un droit).
Cette faille peut tout à fait être exploitée par un voisin de bureau qui n'aurait pas de compétences particulière en informatique.
2 possibilités s'ouvrent pour un hacker qui souhaite exécuter une action dont il n'a pas les droits :
Un site utilise parfois les ressources d'un site d'un autre domaine pour afficher le contenu d'une page. Ceci peut être fait via l'utilisation d'iframe ou d'appels Ajax contactant des ressources distantes (via des API notamment).
Lors de la création d'API, l'autorisation de répondre à un site distant doit être précisé. Seulement, si l'autorisation est faite de manière globale, les adresses (routes) permettant la modification ou la suppression de données pourront également être utilisées.
Il faut donc veiller à vérifier ce qui est exposé et soumis à utilisation distante sans autorisation, de ce qui est soumis à authentification ou à utilisation uniquement local au serveur.
Un hacker par le biais de requête HTTP "Put" ou "Delete" peut tenter d'aller modifier ou supprimer une donnée qu'il aurait récupérée de manière publique via une reqûete Http "Get".
Le site de l'OWASP (Open Web Application Security Project) publie chaque année sur son site le top 10 des failles de sécurité dont voici la liste :
Parmi ces failles certaines d'entre-elles sont directement liées au framework, s'ajoute aux failles concernant l'interjection SQL et le Cross-Site Scripting cité plus haut les failles suivantes :
Un faible niveau de protection (pas de protection https, algorythme de cryptage dépassé) conduit à la possibilité de violation de données personnelles (numéro de cartes bleues, mot de passe) lorsque ces dernières provienne d'une saisie utilisateur et transitent entre le poste client et le serveur.
De mauvaises pratiques de programmation permettent d'accéder à des fonctionnalités pourtant non accessible selon son niveau de permission accordé.
La faille "Using Components with Known Vulnerabilities" est une faille liée à des composants tiers vunérables, obsoltètes ou non mis à jour.
En 2018, toujours selon l'Owasp :
Ces dernières données couplées au comparatif des attaques par CMS nous indiquent clairement que ces sites sont la cible des hackers et qu'il est indispensable de mettre à jour son CMS (installation des patchs de sécurité, migration).
L’utilisation d'un framework imposant l'implémentation de mécanique d'authentification et d'autorisation permet de réduire les risques:
- liées aux interjection SQL
- aux injections de code javascript
- de violation de données personnelles
- de mauvaises pratiques de programmation
- de vulnérabilités liées à des composants obsolètes
Un framework réputé avec une communauté importante est ainsi vivement recommandée afin d'obtenir une dynamique de mise à jour soutenue.
Chez l’éditeur eZ Systems, la remontée des failles se fait via le support, leurs résolutions ont lieu dans les heures ou les jours qui suivent selon la complexité. En 2019, 8 failles ont été répertoriées.
En savoir plus sur la sécurité chez eZ :
Exemple d'architecture
Pour aller plus loin
Besoin d'aide pour le choix de votre CMS open source ?
Contactez-nous !
Besoin d'aide pour le choix de votre CMS open source ?
Contactez-nous !
Besoin d'auditer la sécurité de votre SI ?
Contactez-nous!