1

Cela peut être une question vraiment bête mais je ne comprends pas pourquoi ...Potentiel d'injection SQL ici?

J'utilise RIA Services avec Entity Framework comme backend. J'ai quelques endroits dans mon application où j'accepte l'entrée de l'utilisateur et demande directement à RIA Services (et à tour de rôle EF et à mon tour ma base de données) des questions en utilisant leurs données. Est-ce que l'une de ces couches aide à prévenir les problèmes de sécurité ou devrais-je nettoyer mes données moi-même?

Par exemple, chaque fois qu'un nouveau registre utilisateur avec l'application, j'appelle cette méthode:

[Query] 
public IEnumerable<EmailVerificationResult> VerifyUserWithEmailToken(string token) 
{ 
    using (UserService userService = new UserService()) 
    { 
     // token came straight from the user, am I in trouble here passing it directly into 
     // my DomainService, should I verify the data here (or in UserService)? 
     User user = userService.GetUserByEmailVerificationToken(token); 
     ... 
    } 
} 

(et si je devrais rouler mon propre système de vérification de l'utilisateur est une autre question tout à fait, nous sommes dans le processus (Je suis plus intéressé par l'injection SQL et les services RIA en général)

Répondre

3

injection SQL est basé sur des chaînes sans échappement étant utilisée lors de la génération d'une chaîne SQL brut

par exemple

"SELECT * FROM `user` WHERE `name` = '" . $name . "'" 

est vulnérable, car la valeur de $name pourrait contenir une "marque et modifier ainsi la signification de l'instruction sql. un bon exemple est si le nom $ est ' OR 1=1; -- faisant donc cette requête SQL:

"SELECT * FROM `user` WHERE `name` = '' OR 1=1; --'" 

qui est très utile pour contourner les contrôles de mot de passe je peux vous dire :)

la bonne façon de contourner cela est d'échapper à la ' caractère à \ '(pour mysql). c'est pourquoi des langages tels que php fournissent mysql_real_escape_string. Cependant, si vous utilisez un système de requête paramétré correctement, vous pouvez passer à travers tout ce que vous voulez et la bibliothèque va y échapper correctement.

regardant votre code, il n'y a aucune raison de vérifier la valeur de token à moins que votre UserService fait un peu de génération de chaîne de sql louches (et je suis sûr-cadre de l'entité ne fait pas ça, alors vous devriez être très bien)

+0

Vous devez TOUJOURS scrub les requêtes de base de données, peu importe d'où elles proviennent. Il y a des manières très intéressantes de faire de l'injection SQL là où le programmeur ne s'attendait pas à l'être. Et l'effleurement d'entrée ne consomme pas de ressources du tout. – TheLQ

+0

sûrement pas si la bibliothèque/framework les nettoie déjà? sinon, vous pourriez obtenir des données incorrectes (par exemple des données à double échappement). – oedo

2

Vous devriez être sûr, je suis sûr que EF génère des requêtes paramétrées pour récupérer les données de votre base de données.

3

EF va paramétrer ceci pour vous, cependant si vous voulez vraiment vous assurer que vous démarrez SQL Profiler et voyez ce qui est envoyé à SQL Server