2016-07-11 27 views
0

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.

+1

Unabhängig von der SQL-Injektion Bedrohung ... das ist wirklich schlechte Praxis, ich empfehle Ihnen dringend, diesen Code zu wiederholen. –

+0

@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

+0

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? –

Antwort

1

Solange der Benutzer den als @LocalDatabase übergebenen Wert nicht beeinflusst, wäre dieser Ansatz in Ordnung. Nicht mit dynamischem SQL wäre besser, aber dieser Ansatz kann funktionieren ...

+0

danke aber wenn ich fragen darf, ob das Design gute Praxis ist und warum ja oder warum nicht? – f0rfun

+0

Nun: Generell wird empfohlen, dynamisches SQL möglichst zu vermeiden. Ich glaube nicht, es ist möglich, dynamisch-Datenbanken für eine Abfrage zu ändern, so dass die einzige Alternative eine Kopie dieser Abfrage für jede Datenbank in einer großen zu erstellen ist, wenn/else-Anweisung. Das ist die gleiche Abfrage, so dass es nicht wirklich hilft, es in Zukunft zu erhalten. Also würde ich sagen, wegen der Leichtigkeit der Wartung und solange es nicht zu einer schrecklichen Leistung führt, würde ich diese nur für den Wartungsaspekt bleiben lassen. –