Entrées et sorties
La principale faille de sécurité actuelle des applications est de ne pas traiter correctement les données reçues de sources externes, et plus particulièrement les entrées des utilisateurs. Vous devez toujours examiner de manière approfondie les entrées pour vous assurer qu’elles ont été validées avant de les utiliser. Si vous n’analysez pas les entrées des utilisateurs à la recherche de possibles attaques, cela peut entraîner une perte de données ou une exposition, une élévation de privilège, voire l’exécution de code malveillant sur les ordinateurs des autres utilisateurs.
Le plus tragique dans ce cas, c’est qu’il s’agit d’un problème facile à résoudre. Dans cette unité, nous allons aborder le traitement des données quand elles sont reçues, affichées à l’écran et stockées pour une utilisation ultérieure.
Pourquoi devons-nous valider notre entrée ?
Imaginez que vous développez une interface pour autoriser un utilisateur à créer un compte sur votre site web. Nos données de profil incluent un nom, une adresse électronique et un pseudonyme que nous présentons à tous les utilisateurs qui visitent le site. Que se passe-t-il si un utilisateur crée un profil et entre un pseudonyme qui inclut des commandes SQL ? Par exemple, que se passe-t-il si un utilisateur malveillant entre un élément semblable à l’extrait suivant :
Eve'); DROP TABLE Users;--
Si nous insérons aveuglément cette valeur dans une base de données, elle peut potentiellement altérer l’instruction SQL d’exécution de commandes que nous ne souhaitons absolument pas exécuter ! Cet exemple est appelé attaque par « injection SQL » et représente l’un des nombreux types d’attaques qui peuvent potentiellement être effectuées quand vous ne gérez pas correctement les entrées des utilisateurs. Donc, que pouvons-nous faire pour résoudre ce problème ? Cette unité vous indique quand valider une entrée, comment encoder une sortie et comment créer des requêtes paramétrées (ce qui résout l’attaque ci-dessus). Voici les trois principales techniques de défense contre les entrées malveillantes introduites dans vos applications.
Quand dois-je valider l’entrée ?
La réponse est toujours. Vous devez valider chaque d’entrée pour votre application. Ceci inclut les paramètres d’une URL, l’entrée d’un utilisateur, les données d’une base de données, les données d’une API et tout ce qui est transmis qu’un utilisateur peut potentiellement manipuler. Adoptez toujours l’approche de liste d’autorisation, qui implique que vous n’acceptez que les entrées « connues », au lieu d’une liste de refus (où vous recherchez plus particulièrement les entrées incorrectes), car il est impossible d’établir une liste complète d’entrées potentiellement dangereuses. Effectuez cette tâche sur le serveur, et non côté client (ou en plus du côté client), pour vous assurer que vos défenses ne peuvent pas être contournées. Considérez TOUTES les données comme non approuvées. Vous vous protégerez ainsi de la plupart des vulnérabilités d’application web courantes.
Si vous utilisez ASP.NET, l’infrastructure offre une aide appréciable pour la validation de l’entrée côté client et côté serveur.
Si vous utilisez une autre infrastructure web, des techniques exceptionnelles de validation des entrées sont disponibles sur la fiche récapitulative de validation d’entrée OWASP.
Toujours utiliser des requêtes paramétrées
Les bases de données SQL sont couramment utilisées pour stocker des données ; par exemple, votre application peut stocker des informations de profil utilisateur dans une base de données. Vous ne devez jamais créer de requêtes SQL inline ni d’autres requêtes de base de données dans votre code avec des entrées utilisateur brutes et les envoyer directement à la base de données. Comme nous l’avons vu, le résultat serait désastreux.
Par exemple, ne créez pas de code similaire à l’exemple SQL Inline suivant :
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
Nous concaténons ici des chaînes de texte pour créer la requête, en utilisant l’entrée de l’utilisateur et en générant une requête SQL dynamique pour rechercher l’utilisateur. Là encore, si un utilisateur malveillant a réalisé que nous l’avons fait, ou simplement tenté différents styles d’entrée pour voir s’il existait une vulnérabilité, nous pourrions subir un désastre majeur. Utilisez plutôt des instructions SQL paramétrées ou des procédures stockées comme suit :
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
Avec cette méthode, vous pouvez appeler la procédure à partir de votre code de manière sécurisée, en lui passant la chaîne userName sans vous soucier de son traitement dans l’instruction SQL.
Toujours encoder votre sortie
Une sortie que vous présentez visuellement ou dans un document doit toujours être encodée et placée dans une séquence d’échappement. Cette action peut vous protéger si un élément a été oublié pendant la phase d’assainissement ou si le code génère accidentellement un élément pouvant être utilisé à des fins malveillantes. Ce principe de conception permet de s’assurer que tout est affiché en tant que de sortie et n’est pas interprété par inadvertance comme un élément à exécuter, ce qui constitue une autre technique d’attaque courante appelée « Attaque par scripts intersites (XSS) ».
Étant donné que la prévention XSS est une exigence courante pour l’application, cette technique de sécurité est un autre domaine dans lequel ASP.NET fait le travail à votre place. Par défaut, toute la sortie est déjà encodée. Si vous utilisez un autre framework web, vous pouvez vérifier vos options d’encodage de sortie sur les sites web dans la fiche récapitulative de la prévention XSS OWASP.
Récapitulatif
L’assainissement et la validation de votre entrée sont des conditions requises pour garantir que votre entrée est valide, sûre à utiliser et à stocker. La plupart des frameworks web récents offrent des fonctionnalités intégrées qui peuvent automatiser une partie de ce travail. Vous pouvez consulter la documentation de votre framework préféré et découvrir les fonctionnalités qu’il propose. Comme cela se passe le plus couramment dans les applications web, n’oubliez pas que d’autres types d’applications peuvent être tout aussi vulnérables. Ne pensez pas que vous êtes en sécurité juste parce que votre nouvelle application est une application de bureau. Vous devez toujours gérer correctement l’entrée utilisateur pour vous assurer que personne n’utilise votre application dans le but d’endommager vos données ou de nuire à la réputation de votre entreprise.