Je connais des utilisations des paramètres dans des phrases SQL, mais juste pour la curiosité est sans danger pour empêcher la fonction de format pour empêcher les injections SQL au lieu d'utiliser des paramètres d'utilisation.
Comme cet échantillon
3 Réponses :
qui serait probablement être sécurisé contre l'injection SQL, en supposant que Cependant, même si citedstrstr était assez bon, il est toujours préférable d'utiliser des paramètres pour une raison différente: la performance. Lorsque vous séparez vos paramètres de votre requête, vous pouvez finir par envoyer exactement le même code de requête plusieurs fois plusieurs fois avec différents paramètres. Si vous faites cela, la base de données peut mettre en cache beaucoup de travaux qu'il contient dans le calcul de la requête, de sorte que votre accès à dB devient plus rapide. Cela ne fonctionne pas (ou du moins pas aussi non aussi) lorsque vous mélangez les paramètres dans le code de requête lui-même. ciedtr fonctionne comme prévu et il n'y a pas de cas de bord qui peut le casser. (Ce qui n'est nullement garanti. Comme Linas a souligné dans un commentaire, MySQL vous permet d'utiliser \ ' pour échapper à des devis. D'autres DBMS ont probablement des capacités similaires. Un attaquant avec suffisamment de connaissances théoriques du système serait capable de les exploiter.)
+1 Pour le commentaire sur "Cache", de nombreux serveurs SQL peuvent réutiliser le plan d'exécution des sensibles SQL.
Cela ne serait probablement pas sûr de MySQL car MySQL permet de s'échapper à une citation afin de ne pas vous aider ici.
Notez que MS SQL Server peut «paramétrer automatiquement» les requêtes. Voir MSDN.MicRosoft.com/en-us /Library/ee343986%28V=SQL.100%29.asp x pour des exemples.
Chaque fois que vous construisez une chaîne SQL par des cordes concaténantes ensemble, il existe un potentiel d'attaque d'injection, quelle que soit la sécurité que vous pensez que l'accès à ces chaînes est. Pour tout ce que vous savez, une personne pourrait exécuter votre application à l'intérieur d'un débogueur, mettre un point d'arrêt du résultat de Utiliser les paramètres SQL réels est le moyen le plus sûr d'aller. Non seulement cela évite-t-il les injections, mais cela permet également au moteur SQL de décider de la meilleure façon de formater les paramètres à ses propres besoins afin de ne pas avoir à vous soucier de formater les valeurs dans votre propre code, cela fonctionne bien avec fortement-tapé. Langues (comme Delphi). Sans parler des avantages de la performance d'être capable de préparer l'instruction SQL sur le côté du serveur à l'avance avant de l'exécuter dans votre code, même plusieurs fois, réduisant considérablement le trafic entre le client et le serveur et augmenter la performance globale. P > ciedstr () code> et modifier son contenu avant d'autoriser le format au format () code> pour voir Il. var
sCustomer : string
begin
AdoSql.CommandText := 'Select SUM(value) result from invoices where customer=:Customer';
AdoSql.Prepared := True;
...
AdoSql.Parameters['Customer'].Value := sCustomer;
AdoSql1.ExecSQL;
...
AdoSql.Parameters['Customer'].Value := sCustomer;
AdoSql1.ExecSQL;
...
AdoSql.Prepared := False;
end;
Ce premier paragraphe est un peu stupide. L'injection SQL est essentiellement sur la prise d'accès non autorisé à la base de données. Mais si quelqu'un a un accès au niveau de débogage à votre application elle-même, ils ne ont besoin une attaque d'injection SQL pour accéder à la base de données; Ils peuvent être supposés y avoir déjà accès, au même niveau de privilège que l'application elle-même.
Non si l'application utilise une connexion cryptée sur la base de données ou si l'attaquant ne peut pas, ou ne veut pas, déterminez quel type de base de données est utilisé ou comment y accéder directement. Laissez l'application faire tout le travail, changez simplement le SQL qui est exécuté.
Dans ce scénario, alors l'utilisation de paramètres ne serait pas sûr car l'utilisateur pourrait modifier les valeurs des paramètres - quelque chose que je fais parfois lors du débogage de mes propres applications.
Même si l'attaquant change les valeurs de paramètre, l'utilisation de paramètres est toujours plus sûre. Comme je l'ai dit, les paramètres permettent au moteur de DB de s'assurer que les valeurs sont sûres et formatées correctement. En d'autres termes, en passant une chaîne non notée à un paramètre (ce que vous êtes censé faire) permet au moteur de gérer correctement la chaîne lorsqu'elle exécute la requête. C'est pourquoi les paramètres sont utilisés pour éviter les attaques d'injection en premier lieu.
Non, La partie du code dans la question qui fait quoi que ce soit contre l'injection SQL est l'appel à L'unique avantage du format Dans ce contexte est que le modèle de chaîne entière est au même endroit, vous êtes donc moins susceptible d'obtenir un espacement et une ponctuation incorrecte que si vous deviez construire La chaîne avec des opérations successives Format n'offre aucune sécurité de l'injection SQL. Ce n'est pas différent de la concaténation à cordes ordinaire à cet égard.
ciedtr , que vous pouvez utiliser avec ou sans format . Ce n'est pas aussi fiable que de vraies requêtes paramétrées, cependant.
+ , où les apostrophes SQL pourraient se perdre parmi les apostrophes Delphes.
Je pense que le titre aurait dû être
Cotedstr fonction des paramètres VS dans les scénarios d'injection SQL? Mais le modifier, allumera des réponses ici. Le problème est surciedtr et non au format.