La cybersécurité applicative est essentielle pour protéger les entreprises et les utilisateurs contre les cyberattaques.
Lorsqu'une application n'est pas correctement sécurisée, elle peut devenir la cible de pirates qui cherchent à voler des données sensibles ou à perturber son fonctionnement.
Afin de structurer et normaliser la sécurité des sites PrestaShop et Magento, l'industrie s'appuie sur des standards reconnus, notamment sur les travaux de l'OWASP (Open Worldwide Application Security Project, anciennement Open Web Application Security Project) et son ensemble de règles appelé Core Rule Set (OWASP CRS).
💡 Qu'est-ce que l'OWASP Core Rule Set (CRS) ?
L'OWASP CRS est un ensemble de règles destinées à détecter et bloquer les tentatives de piratage comme le piratage PrestaShop.
Ces règles sont utilisées par des systèmes de protection appelés Web Application Firewall (WAF - parefeu applicatif), qui agissent comme un bouclier entre PrestaShop et les utilisateurs malveillants.
Les règles fournies par OWASP CRS aident ainsi à empêcher des attaques de type 0 day (attaque non connue), comme l'injection de code malveillant et bien d'autres.
Comprendre l'injection SQL et son dépistage par OWASP CRS
Les attaques les plus courantes sont les injections SQL et XSS.
Cette technique permet à un pirate d'exploiter une faille PrestaShop pour accéder à des informations confidentielles stockées dans une base de données.
Exemple simple d'injection SQL
Imaginons une page PrestaShop de connexion demandant un identifiant utilisateur. Si elle n'est pas bien sécurisée, un attaquant pourrait entrer une commande spéciale comme :
' OR '1'='1
Comment OWASP CRS bloque ce type d'attaque ?
L'OWASP CRS dispose de règles qui surveillent les informations entrées par les utilisateurs. Lorsqu'une tentative suspecte est détectée, elle est bloquée avant d'atteindre la base de données.
Quid des blocages non souhaités (faux positifs) ?
Toutes les règles de sécurité de niveau professionnel donc étant en capacité de gérer des 0day (attaque non connue) peuvent générer des faux positifs (blocage non souhaité), car elles s'appliquent à des contextes variés où certaines actions légitimes ressemblent à des attaques.
De plus, certaines contraintes imposées par des tiers – comme des passerelles de paiement, des APIs ou des partenaires techniques – peuvent forcer l'application de pratiques incompatibles avec certaines règles de sécurité.
Il revient donc à l'infogérance PrestaShop de surveiller ces blocages en temps réel, d'analyser leur impact et d'ajuster immédiatement les règles en conséquence.
L'objectif est double : maintenir un haut niveau de sécurité tout en garantissant la continuité des opérations. Chaque ajustement doit être effectué avec précision afin de réduire les faux positifs sans introduire de nouvelles vulnérabilités dans le système.
NB : Si une règle de protection contre les menaces (injections SQL, XSS, etc.) ne nécessite aucun ajustement, cela signifie qu'elle repose uniquement sur une détection par signature ou liste noire. Dans ce cas, votre PrestaShop reste vulnérable face à des attaquants expérimentés – de niveau confirmé à senior – qui maîtrisent parfaitement les techniques de contournement, en particulier sur les boutiques générant plus d'un million d'euros de chiffre d'affaires par an.
🖥️ ️Pour les plus techniques d'entre vous
Cette détection se base sur un langage spécifique de programmation informatique qui s'appelle l'expression régulière (regex pour les intimes). Tous les spécialistes en cybersécurité le parlent comme leur langue maternelle, c'est indispensable.
La commande spéciale fournie précédemment est triviale, elle sera capturée par plusieurs expressions régulières dont la 942110.
Des outils comme Regex 101 nous aident au quotidien pour parfaire les règles et leurs éventuelles exclusions : Regex101.
🔍 Pourquoi de nombreux e-commerçants ne respectent pas l'état de l'Art en cybersécurité applicative ?
- 🤔 Un manque de compréhension technique : Beaucoup d'acteurs du e-commerce ne sont pas des experts en cybersécurité et n'ont pas conscience des risques réels qu'ils encourent.
- 💰 La priorité aux ventes plutôt qu'à la sécurité : L'objectif principal d'un e-commerçant est de maximiser ses ventes et de garantir une expérience fluide pour ses clients. Si une solution de cybersécurité ralentit le site ou bloque des utilisateurs, elle sera souvent perçue comme un frein aux performances.
- 🚫 Le refus d'allouer un budget à la cybersécurité : La sécurité est souvent vue comme un coût plutôt que comme un investissement. Certains préfèrent réagir après un incident plutôt que d'anticiper le problème.
- ⚠️ La peur des faux positifs (blocage non souhaité) : Un WAF mal configuré peut bloquer des clients réels, ce qui représente une perte directe de chiffre d'affaires. Plutôt que d'affiner la configuration, certains préfèrent désactiver certaines protections.
- 🙄 La technique du "pas vu, pas pris" : Plutôt que de reconnaître et corriger les failles, certains e-commerçants préfèrent enterrer les hacks pour éviter d'effrayer leurs clients. Cette dissimulation met en danger les données bancaires et peut les exposer à des poursuites pour complicité dans un recel de cartes bleues volées (incluant leurs développeurs souvent au courant)
- 🛠️ La complexité de mise en œuvre : Respecter les meilleures pratiques en cybersécurité demande des compétences spécifiques et du temps. Beaucoup de e-commerçants travaillent avec des prestataires qui ne sont pas spécialisés en cybersécurité PrestaShop et qui mettent l'accent sur la rapidité du développement plutôt que sur la robustesse des protections.
- 🙈 Une confiance aveugle envers leur prestataire : De nombreux e-commerçants considèrent que leur prestataire technique gère tout correctement et ne remettent jamais en question la sécurité mise en place. C'est une grave erreur, car les défenses doivent être testées et stressées régulièrement pour identifier les failles avant qu'un attaquant ne les exploite.
Limitations d'OWASP Core Rule Set (CRS)
OWASP CRS (Core Rule Set) constitue un excellent socle pour améliorer la résistance de PrestaShop contre une large gamme d'attaques. Cependant, bien qu'il apporte une protection robuste, il présente plusieurs limitations qu'il est essentiel de comprendre et d'anticiper.
1. Une couverture incomplète, notamment sur la fuite de données
OWASP CRS est principalement conçu pour détecter et bloquer des tentatives d'intrusion actives, mais il ne couvre pas de manière exhaustive les scénarios liés aux fuites de données. En particulier, il ne prend pas en charge la détection des robots d'exploration qui parcourent les répertoires à la recherche d'archives, de sauvegardes ou d'autres fichiers sensibles accidentellement exposés, comme les fichiers .zip, .gzip, ou .csv qui sont fréquemment utilisés pour exporter des données sensibles (clients, commandes, inventaires, etc.).
Ces robots peuvent ainsi récupérer des données critiques (sauvegarde de bases de données, fichiers de configuration contenant des identifiants, exports clients, etc.) sans générer d'alerte.
Pour pallier cette lacune, il est essentiel d'adopter des mesures complémentaires, telles que des politiques de durcissement des permissions d'accès aux fichiers, la mise en place de règles de détection d'anomalies dans les accès aux ressources sensibles, ainsi que des stratégies de journalisation avancées pour repérer les tentatives suspectes d'exfiltration de données.
Par ailleurs, OWASP CRS ne prend pas en charge de manière native le blindage applicatif (hardening), qui permet d'interdire l'accès à certains dossiers ou fichiers dans des arborescences sensibles. Par exemple, il ne bloque pas systématiquement l'exécution de fichiers dangereux (.php) placés dans des répertoires censés ne contenir que des fichiers statiques (CSS, JS, images, répertoire de téléchargement), ce qui peut représenter une fragilité critique dans certaines configurations.
Pour les plus techniques d'entre vous : n'oubliez pas de bloquer également l'accès aux répertoires racines appelant implicitement des fichiers index.php, par exemple www.monsite.fr/css/ qui appele implicitement www.monsite.fr/css/index.php
2. Une gestion perfectible des uploaders de fichiers
Les règles standard d'OWASP CRS ne couvrent pas efficacement les risques liés aux fichiers transférés vers le serveur. Si certaines protections existent contre l'exécution de scripts malveillants, elles ne bloquent pas systématiquement les formats de fichiers potentiellement dangereux ni les techniques d'obfuscation utilisées par les attaquants (double extension, contenu malveillant masqué dans un fichier légitime, etc.).
Nativement, OWASP CRS n'examine pas le contenu des fichiers soumis, se limitant à des contrôles basiques sur les extensions. Cela permet à des attaquants d'introduire des virus sans difficulté, en exploitant des détournements tels que l'insertion de code malveillant dans des archives PHAR (fichiers PHP compilés) camouflées en images, ou encore l'injection de scripts XSS dans des fichiers CSS et JavaScript.
Ces failles nécessitent une approche complémentaire intégrant des mécanismes d'analyse approfondie, comme la vérification des signatures de fichiers, l'inspection du contenu et l'isolement des fichiers suspects pour une validation manuelle.
3. L'importance du diagnostic et de l'adaptation aux besoins du marchand
Étant donné que les règles d'OWASP CRS sont génériques, elles ne tiennent pas compte des spécificités de chaque PrestaShop. Un diagnostic précis des règles appliquées permet de comprendre leur périmètre opérationnel et d'ajuster leur configuration afin de maximiser la protection sans perturber le site E-Commerce. Il est donc essentiel d'analyser régulièrement les journaux, de tester les faux positifs (blocage non souhaité) et de compléter ces règles avec des ajustements sur mesure adaptés aux besoins des PrestaShop protégés.
En somme, OWASP CRS est une brique de sécurité précieuse, mais il ne peut être considéré comme une solution clé en main. Son efficacité repose sur une configuration fine, une surveillance proactive et une intégration avec d'autres outils de protection adaptés aux enjeux spécifiques de chaque application.
Conclusion
La cybersécurité applicative repose sur des standards reconnus comme l'OWASP Core Rule Set. Ces règles permettent de bloquer des attaques dangereuses incluant des attaques non connues (0day).
Toutefois, une configuration adaptée est nécessaire pour garantir un équilibre entre sécurité et accessibilité.
Une surveillance continue et des ajustements permettent d'assurer une protection optimale tout en préservant une bonne expérience utilisateur.
Nous vous encourageons à réaliser un diagnostic de votre WAF - notre diagnostiqueur WAF PrestaShop peut vous aider.