Na gute Frage. Die Antwort ist eher stochastisch als deterministisch und ich werde versuchen, meine Ansicht anhand eines kleinen Beispiels zu erklären.
Es gibt viele Referenzen im Internet, die uns empfehlen, Parameter in unseren Abfragen zu verwenden oder gespeicherte Prozeduren mit Parametern zu verwenden, um SQL Injection (SQLi) zu vermeiden. Ich werde Ihnen zeigen, dass gespeicherte Prozeduren (zum Beispiel) nicht der Zauberstab gegen SQLi sind. Die Verantwortung liegt weiterhin beim Programmierer.
Betrachten Sie die folgende gespeicherte SQL Server-Prozedur, mit der die Benutzerzeile aus einer Tabelle 'Benutzer' abgerufen wird:
create procedure getUser
@name varchar(20)
,@pass varchar(20)
as
declare @sql as nvarchar(512)
set @sql = 'select usrID, usrUName, usrFullName, usrRoleID '+
'from Users '+
'where usrUName = '''+@name+''' and usrPass = '''+@pass+''''
execute(@sql)
Sie können die Ergebnisse erhalten, indem Sie den Benutzernamen und das Passwort als Parameter übergeben. Angenommen, das Passwort ist im freien Text (nur zur Vereinfachung dieses Beispiels), wäre ein normaler Anruf:
DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)
EXECUTE @RC = [dbo].[getUser]
@name = 'admin'
,@pass = '!@Th1siSTheP@ssw0rd!!'
GO
Aber hier haben wir eine schlechte Programmiertechnik, die vom Programmierer innerhalb der gespeicherten Prozedur verwendet wird, so dass ein Angreifer Folgendes ausführen kann:
DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)
EXECUTE @RC = [TestDB].[dbo].[getUser]
@name = 'admin'
,@pass = 'any'' OR 1=1 --'
GO
Die obigen Parameter werden als Argumente an die gespeicherte Prozedur übergeben, und der SQL-Befehl, der schließlich ausgeführt wird, lautet:
select usrID, usrUName, usrFullName, usrRoleID
from Users
where usrUName = 'admin' and usrPass = 'any' OR 1=1
..die alle Zeilen von Benutzern zurückbekommt
Das Problem hierbei ist, dass selbst wir dem Prinzip "Erstellen einer gespeicherten Prozedur und Übergeben der Felder zur Suche als Parameter" folgen, das SQLi weiterhin ausgeführt wird. Dies liegt daran, dass wir nur unsere schlechte Programmierpraxis in die gespeicherte Prozedur kopieren. Die Lösung des Problems besteht darin, unsere gespeicherte Prozedur wie folgt umzuschreiben:
alter procedure getUser
@name varchar(20)
,@pass varchar(20)
as
select usrID, usrUName, usrFullName, usrRoleID
from Users
where usrUName = @name and usrPass = @pass
Ich versuche zu sagen, dass die Entwickler zuerst lernen müssen, was ein SQLi-Angriff ist und wie er ausgeführt werden kann, und dann ihren Code entsprechend schützen müssen. Das blinde Befolgen von "Best Practices" ist nicht immer der sicherere Weg ... und vielleicht haben wir deshalb so viele "Best Practices" -Fehler!