Votre entreprise a développé une application de e-commerce. Dès la phase de conception, une modélisation des menaces a permis d’identifier un scénario selon lequel un attaquant pourrait réussir à exfiltrer des données clients par l’injection de requêtes SQL malveillantes. Parmi les solutions proposées, laquelle vous parait la plus efficace pour se protéger contre ce type d’attaques ?
[A] Authentification à deux facteurs (2FA)
[B] Instructions préparées (Prepared statements)
[C] Validation des entrées côté serveur (Server-side input validation)
[D] Encapsulation des données client (Data encapsulation)
Les propositions [A] et [D] ne protègent en aucune manière contre les attaques par injection SQL.
La proposition [C] peut répondre à la problématique mais elle est d’une part assez difficile à mettre en œuvre par les développeurs et d’autre part plusieurs techniques offensives peuvent être utilisées pour la contourner. On notera cependant qui si on doit contrôler des entrées utilisateur pour des raisons de sécurité c’est toujours au niveau du serveur (server-side) qu’il faut le faire et jamais au niveau du client (client-side).
Les instructions préparées (Prepared statements) offrent la meilleure protection contre les attaques par injection SQL en séparant clairement les données des commandes SQL dans les requêtes exécutées par l’application. Lorsque vous utilisez des instructions préparées, les paramètres de la requête sont transmis séparément des instructions SQL proprement dites et ne sont jamais interprétés comme du code SQL par le moteur de la base de données.
La mise en œuvre d’une instruction préparée s’effectue en deux étapes :
1. Préparation de la requête : La requête SQL est définie avec des placeholders (généralement sous la forme de points d’interrogation) pour les valeurs qui seront insérées. Par exemple : `SELECT * FROM users WHERE username = ?`.
2. Liaison des valeurs : Les valeurs qui doivent être insérées dans les placeholders sont fournies à la base de données, qui les traite comme de simples données. Ces valeurs n’étant jamais interprétées en tant que code SQL, toute tentative d’injecter un code malveillant sera traitée comme une chaîne de caractères et non comme une instruction exécutable.
Pour résumer, le processus de préparation et de liaison garantit que l’entrée de l’utilisateur est toujours interprétée comme des données et non comme du code. Cela élimine le risque qu’une entrée malveillante modifie la structure ou l’exécution de la requête SQL.
La bonne réponse est la proposition [B] les instructions préparées (Prepared statements).
Pour en savoir plus sur l’intégration de la sécurité dans le développement des logiciels nous vous recommandons de suivre les modules n°20 et 21 de la formation CISSP de VERISAFE.
Questions et réponses rédigées par VERISAFE selon le programme officiel du CISSP actuellement en vigueur
© VERISAFE – Utilisation ou reproduction (même partielle) strictement interdite sans l’accord écrit de VERISAFE
