Vor kurzem zufällig auf eine gespeicherte Prozedur, die von den Vorgängern fest codiert wurde, einige CRUD durchzuführen. Es betrifft nicht kritische Tabellen in der Produktionsdatenbank. Ich habe das Gefühl, dass SQL-Injektionen verwundbar sind, aber es scheint, als ob die Injektion wirklich harmlos ist, da CRUD auf nicht-kritischen Tabellen ausgeführt wird.Wie viel Schaden kann die SQL-Injektion über diese gespeicherte Prozedur verursachen?
Der Parameter @LocalDatabase wird in der Konfigurationsdatei connectionString="Server=localHost;Database=localDatabase;..."
übergeben.
Ich frage mich, ob eine mögliche SQL-Injektion in diesem speziellen SP die Produktionsdatenbank katastrophal schädigen kann? Ich wäge den Kosten-Nutzen-Effekt ab, dieses ganze Modul neu zu schreiben.
ALTER PROCEDURE StoredProc_Name
(
@LocalDatabase varchar(50),
@Result int OUTPUT
)
SET @Sql = N'UPDATE <Production Database>.Table1
SET ...
FROM <Production Database>.NewTable INNER JOIN
'+ @LocalDatabase +'.dbo.Table1 ON ... INNER JOIN
'+ @LocalDatabase +'.dbo.Table2 ON ...
WHERE NOT EXISTS(SELECT 1
FROM <Production Database>.dbo.Table2
WHERE .....)'
EXEC(@Sql)
SET @Result = @@ROWCOUNT
Schätzen Sie alle Ratschläge oder helfen Sie, in die richtige Richtung zu zeigen. Danke im Voraus.
Unabhängig von der SQL-Injektion Bedrohung ... das ist wirklich schlechte Praxis, ich empfehle Ihnen dringend, diesen Code zu wiederholen. –
@SufyanJabr warum ist es so? Kann ich einige Einsichten haben, damit ich meinen Fall besser begründen kann, um das Modul neu zu schreiben? Ya wissen ... 'Es macht die Arbeit erledigt' Argument. – f0rfun
Mir ist nicht der genaue Fall bekannt, den Sie haben, aber die Verwendung von Exec durch Verketten der SQL ist eine der wirklich schlechten Praktiken, und es muss vermieden werden. Von was ich sehen kann ist, dass Sie versuchen, Datenbanken basierend auf dem Parameter zu wechseln, warum tun Sie es nicht auf der Verbindungszeichenfolge? –