ASP.NET met en place plusieurs protections afin de protéger le site Web contre les utilisateurs malveillants. Par exemple, lors de l'entrée de texte dans un formulaire, il est impossible d'entrer des balises HTML, à moins que le programmeur n'en donne spécifiquement l'autorisation.
Malgré cela, il faut prendre certaines précautions lorsqu'on utilise les données entrées par un internaute pour effectuer une requête SQL.
Voici un exemple concret :
Soit la requête suivante :
requete = "SELECT usager_prenom, usager_nomfamille, usager_motpasse FROM usager
WHERE ;
Une requête montée à l'aide d'une concaténation de ce genre peut ouvrir des portes aux utilisateurs malveillants.
Si on permet à l'internaute d'entrer un code d'usager du genre « ' UNION SELECT 'monprenom','monnom','abc' -- », on obtiendra la requête suivante :
SELECT usager_prenom, usager_nomfamille, usager_motpasse
FROM usager
WHERE usager_login = '' UNION SELECT 'monprenom','monnom','abc' --' AND usager_motpasse = '...';
N'importe qui pourrait donc être authentifié sans connaître le mot de passe.
Pour se protéger de ce type d'injection, on pourrait échapper par programmation des apostrophes afin qu'ils ne soient pas interprétés par le serveur SQL.
Mais pour être plus efficace, on fera appel aux mécanismes prévus par ASP.NET. Ainsi, on évitera l'utilisation de requêtes SQL contenant des paramètres entrés « à bras » à l'aide d'une concaténation.
On utilisera TOUJOURS le mécanisme des paramètres prévu dans la classe SqlDataSource. Les requêtes ne contiendront donc JAMAIS de concaténation avec des variables.
▼Publicité Le texte se poursuit plus bas
« How To: Protect From Injection Attacks in ASP.NET ». MSDN. http://msdn.microsoft.com/en-us/library/ff647397.aspx
Site fièrement hébergé chez A2 Hosting.
