Wenn Benutzer plötzlich Admin sind

SQL Injection ist kein Theorieproblem.
Es reicht ein falsch gebauter Login-Screen.
Und plötzlich kann ein Nutzer DROP TABLE ausführen.

Gerade in KMU mit Access-Frontends, alten PHP-Skripten oder dynamischem SQL ist das Risiko real.
Und: SQL Server schützt Dich nicht automatisch.

Klassiker: Dynamisches SQL mit Benutzereingabe

DECLARE @sql NVARCHAR(MAX);
SET @sql = 'SELECT * FROM kunden WHERE name = ''' + @eingabe + '''';
EXEC sp_executesql @sql;

Wenn @eingabe = 'a'' OR 1=1 -- ist, dann sieht der Server:

SELECT * FROM kunden WHERE name = 'a' OR 1=1 --'

→ komplette Tabelle im Ergebnis.

Besser: Parameterisiertes SQL

DECLARE @sql NVARCHAR(MAX);
SET @sql = N'SELECT * FROM kunden WHERE name = @name';
EXEC sp_executesql @sql, N'@name NVARCHAR(100)', @name = @eingabe;

Jetzt wird der Inhalt sauber geparst.
Keine Chance für Injection.

Auch in VBA: Prepared Statements nutzen

Falsch:

Dim cmd As New ADODB.Command
cmd.CommandText = "SELECT * FROM kunden WHERE name = '" & txtName.Text & "'"
cmd.Execute

Richtig:

Dim cmd As New ADODB.Command
With cmd
    .CommandText = "SELECT * FROM kunden WHERE name = ?"
    .Parameters.Append .CreateParameter(, adVarChar, adParamInput, 100, txtName.Text)
    .Execute
End With

Parameter werden sauber übergeben.
Keine Ausführung von Code durch Benutzereingaben.

Stored Procedures sind keine Garantie

CREATE PROCEDURE get_kunden
    @filter NVARCHAR(100)
AS
BEGIN
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = 'SELECT * FROM kunden WHERE name LIKE ''' + @filter + '''';
    EXEC(@sql);
END;

Auch hier kann ein Angreifer SQL einschleusen.
Nur weil’s in einer SP steht, ist es nicht sicher.

Besser:

CREATE PROCEDURE get_kunden
    @filter NVARCHAR(100)
AS
BEGIN
    SELECT * FROM kunden WHERE name LIKE @filter;
END;

Was Du sonst noch tun kannst

• Rechte einschränken: Der Datenbankuser braucht keine ALTER, DROP, DELETE-Rechte auf alles
• Input validieren: Zeichen wie ;, ', -- rausfiltern
• Logging verdächtiger Muster (z. B. viele OR 1=1)
• Keine Fehlerdetails anzeigen:
  Fehler wie Syntax near 'DROP' helfen Angreifern

Tools zur Prüfung

• SQL Server Audit
• Extended Events (z. B. auf sql_text mit verdächtigen Mustern)
• Application Firewall
• Code Review + Penetrationstests

Beispiel: verdächtige SQL-Texte loggen

SELECT TOP 100
    text,
    creation_time,
    execution_count
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle)
WHERE text LIKE '%--%' OR text LIKE '% OR %=%'
ORDER BY qs.creation_time DESC;

Mein Fazit

SQL Injection ist kein Thema für Großkonzerne.
Es reicht ein Formularfeld ohne Prüfung – und Deine Datenbank ist offen.

Wenn Du überall mit Parametern arbeitest, bist Du auf der sicheren Seite.
Dynamisches SQL? Nur mit sp_executesql und sauberer Trennung von Daten und Code.

Wenn Du willst, prüfe ich Deinen Code auf SQL Injection – pragmatisch, unaufgeregt, gründlich.