Sécurité et entrée utilisateur

Les données utilisateur, qui sont n’importe quel type d’entrée (données d’une requête web ou d’une URL, entrée aux contrôles d’une application Microsoft Windows Forms, et ainsi de suite), peuvent influencer négativement le code, car souvent ces données sont utilisées directement comme paramètres pour appeler d’autres codes. Cette situation est analogue au code malveillant appelant votre code avec des paramètres étranges, et les mêmes précautions doivent être prises. En réalité, une entrée utilisateur est plus difficile à sécuriser, car il n’existe aucune frame de pile permettant de détecter la présence de données potentiellement non fiables.

Ces bogues sont parmi les bogues de sécurité les plus subtils et les plus difficiles à trouver, car, bien qu’ils puissent exister dans le code qui n’est apparemment pas lié à la sécurité, il s’agit d’une passerelle qui transmet des données incorrectes à d’autres codes. Pour rechercher ces bogues, suivez n’importe quel type de données d’entrée, imaginez la plage de valeurs possibles et déterminez si le code qui voit ces données peut gérer tous ces cas. Vous pouvez corriger ces bogues par le biais de la vérification de plage et rejeter toute entrée que le code ne peut pas gérer.

Voici quelques considérations importantes concernant les données utilisateur :

• Toutes les données utilisateur d’une réponse de serveur s’exécutent dans le contexte du site du serveur sur le client. Si votre serveur web accepte des données utilisateur et l’insère dans la page Web retournée, il peut, par exemple, inclure une <script> balise et s’exécuter comme si à partir du serveur.

• N’oubliez pas que le client peut demander n’importe quelle URL.

• Tenez compte des chemins d’accès difficiles ou non valides :

  • ..\ , des chemins d’accès extrêmement longs.

  • Utilisation de caractères génériques (*).

  • Expansion des jetons (%token%).

  • Formes étranges de chemins avec une signification particulière.

  • Noms de flux alternatifs du système de fichiers, par exemple filename::$DATA.

  • Versions courtes des noms de fichiers comme longfi~1 pour longfilename.

• N’oubliez pas que Eval(userdata) peut faire quoi que ce soit.

• Méfiez-vous de toute liaison tardive vers un nom comprenant des données utilisateur.

• Si vous traitez des données web, tenez compte des différentes formes d’échappement autorisées, notamment :

  • Échappements haxadécimaux (%nn).

  • Échappements Unicode (%nnn).

  • Échappements UTF-8 longs (%nn%nn).

  • Échappements doubles (%nn devient %mmnn, où %mm est l’échappement pour '%').

• Soyez méfiant des noms d’utilisateur qui peuvent avoir plusieurs formats canoniques. Par exemple, vous pouvez souvent utiliser le formulaire MYDOMAIN\username ou le formulaire username@mydomain.example.com.

Voir aussi

• instructions de codage sécurisé
• sécurité de base ASP.NET