Vue d'ensemble des attaques de script
Mise à jour : novembre 2007
Du point de vue d'un navigateur, une page Web n'est qu'une longue chaîne de caractères. Le navigateur traite cette chaîne de façon séquentielle, en affichant certains caractères et en en interprétant d'autres, tels que <b> et <script>, en fonction de règles spécifiques. Si un utilisateur malveillant parvient à insérer certains de ces caractères dans une page, le navigateur ne saura pas qu'ils ne sont pas censés s'y trouver et les traitera comme s'ils faisaient partie de la page.
De façon schématique, une attaque de script fonctionne de la manière décrite ci-dessous. Dans le cas d'une application permettant aux utilisateurs de publier des commentaires sur les films les plus récents afin que d'autres utilisateurs les lisent, les étapes d'attaque peuvent être :
L'application affiche un formulaire permettant aux utilisateurs d'entrer leurs commentaires. L'utilisateur malveillant écrit un commentaire comprenant un bloc <script>.
Le formulaire est publié et le commentaire de l'utilisateur malveillant est stocké dans une base de données.
Un autre utilisateur visite le site. Lors de la construction de la page, les commentaires sont lus à partir de la base de données et insérés dans la page. Le bloc <script> de l'utilisateur malveillant est écrit dans la page comme s'il s'agissait d'un commentaire de texte.
Lorsque le navigateur du second utilisateur affiche la page, il récupère le bloc <script> et l'exécute.
Les utilisateurs malveillants peuvent également attaquer un script d'autres manières. La plupart des attaques de script supposent que l'application accepte l'entrée malveillante et l'injecte (ou la reproduise) dans une page dans laquelle elle est exécutée par le navigateur. Les dommages possibles provoqués par ces attaques dépendent du script exécuté. Il peut s'agir d'un message inoffensif, mais ennuyeux, s'affichant dans le navigateur. Toutefois, les dommages peuvent être plus sérieux : vol de cookies, vol d'entrées d'utilisateur (telles qu'un mot de passe), et, si la sécurité Internet est faible, exécution de code natif sur l'ordinateur de l'utilisateur.
Pour plus d'informations sur la façon d'empêcher des attaques de script, consultez Comment : se protéger contre les attaques de script dans une application Web en utilisant le codage HTML.
.gif "Remarque") Remarque : |
|---|
Pour assurer une protection contre les attaques de script déguisées en URL, ASP.NET recherche la présence de chaînes potentiellement dangereuses (comme "<!", "</" et "<?"). |
Attaques d'instructions SQL
Il existe une variante d'attaque de script qui provoque l'exécution d'instructions SQL nuisibles. Ceci peut se produire lorsqu'une application invite l'utilisateur à entrer des informations, puis concatène les entrées d'utilisateur dans une chaîne représentant l'instruction SQL. Par exemple, une application peut demander un nom de client dans l'intention d'exécuter une instruction telle que la suivante :
"Select * From Customers where CustomerName = " & txtCustomerName.Value
Un utilisateur malveillant disposant d'informations sur la base de données peut utiliser la zone de texte pour entrer une instruction SQL incorporée avec le nom du client, telle que la suivante :
Select * From Customers Where CustomerName = 'a' Delete From Customers Where CustomerName > ''
Lors de l'exécution de la requête, la base de données est mise en péril.
Protection contre les attaques de script
La première défense contre les attaques de script consiste à ne jamais se fier aux informations provenant d'un utilisateur. Considérez que toute donnée publiée dans votre application à partir d'un navigateur peut contenir un script nuisible.
De même, chaque fois que vous écrivez une chaîne dans une page, considérez qu'elle est susceptible de contenir un script nuisible (sauf si vous avez vous-même créé la chaîne par programme). Par exemple, lorsque vous lisez des chaînes à partir d'une base de données, considérez qu'elles sont susceptibles de contenir un script nuisible. Les développeurs les plus sensibilisés aux problèmes de sécurité se méfient même de leurs propres bases de données, considérant qu'un utilisateur malveillant a pu trouver un moyen de les falsifier.
ASP.NET vous offre différents moyens de vous protéger des attaques de script :
ASP.NET exécute la validation de la demande par rapport à des variables chaîne de requête et de formulaire, et à des valeurs de cookie. Par défaut, si le Request actuel contient des éléments HTML ou certains caractères HTML (tels que — pour le tiret cadratin), l'infrastructure des pages ASP.NET déclenche une erreur.
Si vous souhaitez afficher des chaînes dans votre application sans toutefois leur faire confiance, utilisez le codage HTML lorsque les chaînes sont réécrites dans une réponse. Par exemple, avec le codage, la balise <b> devient <b>. Vous pouvez appliquer cette méthode si les chaînes que vous affichez proviennent d'une base de données dont le contenu n'est pas fiable.
Si vous souhaitez que votre application accepte certains éléments HTML (par exemple, certaines instructions de mise en forme provenant des utilisateurs), vous devez coder le HTML chez le client avant qu'il soit envoyé au serveur. Pour plus d'informations, consultez Comment : se protéger contre les attaques de script dans une application Web en utilisant le codage HTML.
Pour vous protéger contre les attaques d'instructions SQL, ne créez jamais de requêtes SQL à l'aide de la concaténation de chaînes. Créez plutôt une requête paramétrée et assignez aux objets de paramètre les valeurs des entrées d'utilisateur. Pour plus d'informations, consultez Paramètres des commandes d'adaptateur de données.
Validez toujours une entrée de formulaire par rapport à un jeu de valeurs attendues et effectuez une validation de mise en forme de chaîne/de type. Par exemple, si une variable de formulaire spécifique est supposée être un entier, utilisez la méthode Int32.TryParse pour vérifier que la valeur est vraiment un entier et utilisez la vérification de plage pour vous assurer que la valeur est comprise dans une plage acceptable.