2010-08-05 5 views
1

J'ai du code dans ASP qui place les valeurs dans un champ de texte dans SQL Server à l'aide de requêtes paramétrées. Je me demandais si le paramétrage suffisait, ou si je devais chercher des commandes potentielles sur le terrain, en remplaçant les simples ticks par des doubles ticks, etc. Les champs de texte sont des essais, ils peuvent donc avoir un nombre quelconque de mots ou de caractères.Prévention de l'injection SQL dans les champs TEXT de SQL Server à l'aide de ASP classique

Suis-je en sécurité?

sSQL="[usp_SaveDocumentGradeCriteria]" 
      Set dbCommand = Server.CreateObject("ADODB.Command")  
      Set dbCommand.ActiveConnection = oConn 
      dbCommand.CommandType = adCmdStoredProc 
      dbCommand.Commandtext=sSQL 
      dbCommand.Parameters.Append (dbCommand.CreateParameter("@CriteriaXML", adLongVarChar, adParamInput, len(saveXML), saveXML)) 
      dbCommand.Parameters.Append (dbCommand.CreateParameter("@Comments", adLongVarChar, adParamInput, len(commentText), commentText))  
      dbCommand.Parameters.Append (dbCommand.CreateParameter("@documentGUID", adGuid, adParamInput, 0, documentGUID)) 
      dbCommand.Parameters.Append (dbCommand.CreateParameter("@graderFYCUserID", adInteger, adParamInput, 0, fycuserid)) 
      dbCommand.Parameters.Append (dbCommand.CreateParameter("@graderSequence", adInteger, adParamInput, 0, graderSequence)) 
      if trim(grade)<>"" then 
       dbCommand.Parameters.Append (dbCommand.CreateParameter("@grade", adInteger, adParamInput, 0, grade))  
      end if 


      set oRST=dbCommand.Execute 

Répondre

9

Passer le texte en tant que paramètre éliminera la possibilité d'une injection SQL pour l'invocation de la procédure stockée. Cependant, cela ne dit rien sur la procédure stockée elle-même, elle peut tout aussi bien être exposée à l'injection SQL si elle utilise le SQL dynamique. Et même si la procédure stockée est sûre, vous devez toujours vous assurer que vous n'effectuez pas de script intersite avec le contenu téléchargé lorsque vous l'affichez au client.

Est vraiment un jeu de bout en bout sur lequel vous devez sécuriser à chaque étape. L'utilisation de paramètres lors de l'invocation de la procédure est bonne, mais personne ne peut dire si cela suffit. Vous devez suivre les données jusqu'à ce que le navigateur du client s'affiche (et peut-être même continuer après, si manipulé par JScripts ...)

+0

Bons points. Je suis plus préoccupé par le point d'invocation depuis que j'ai sécurisé la procédure dans T-SQL. Devra trouver une bonne ressource sur le filtrage des tentatives XSS. Des idées? – Caveatrob

+0

http://support.microsoft.com/kb/252985, http://support.microsoft.com/kb/253119/ –

+0

@Caveatrob Utilisez l'expression régulière pour vérifier si certains éléments ne figurent pas dans votre texte.Par exemple, limiter l'utilisateur à utiliser de "<",">", mieux encore juste faire Encodage sur soumettre et décoder sur récupérer, cela permettra d'éclairer toute possibilité d'injection SQL et de fournir une sécurité pour le contenu. –

Questions connexes