SQL Injection

SQL Injection er en kritisk sikkerhedssårbarhed, hvor en angriber manipulerer SQL-forespørgsler ved at indsætte ondsindet input, så databasen udfører uautoriserede kommandoer. Angrebet udnytter manglende adskillelse mellem data og SQL-logik.

Hvad er SQL Injection?

SQL injection opstår, når brugerinput indsættes direkte i SQL-queries uden korrekt parameterisering. Databasen kan ikke skelne mellem legitim SQL og injiceret input og eksekverer derfor angriberens payload med applikationens rettigheder.

Det er et server-side angreb med fuld adgang til data-laget.

Hvordan opstår problemet?

SQL injection er muligt, når:

• SQL-queries bygges via string-konkatenation

• Prepared statements ikke anvendes korrekt

• ORM’er omgås via raw queries

• Input valideres forkert eller antages “sikkert”

Eksempel (usikkert): SELECT * FROM users WHERE email = '$email';

Payload: ' OR 1=1 --

Hvorfor er SQL Injection alvorligt?

Sikkerhed

• Læsning, ændring og sletning af data

• Omgåelse af autentifikation

• Eskalering til systemkompromittering

• I visse tilfælde remote code execution

Forretning

• Databrud

• Nedetid

• Tab af kundetillid

• Store juridiske og økonomiske konsekvenser

Compliance

• Brud på GDPR og andre databeskyttelseskrav

• Audit-fund og bøder

Typiske angrebsscenarier

• Login-formularer

• Søgefelter

• Filtrering og sortering

• Admin-paneler

• API-parametre

Typer af SQL Injection

• Classic / In-band

• Blind SQL Injection

• Time-based SQL Injection

• Error-based SQL Injection

• Second-order SQL Injection

Alle udnytter samme grundfejl: ukontrolleret input i SQL.

Best Practice – forebyggelse

Brug parameteriserede queries

• Prepared statements er ikke valgfrit

• Eksempel (PDO): $stmt = $pdo->prepare(
'SELECT * FROM users WHERE email = ?'
);

Brug ORM korrekt

• Stol på query builders

• Undgå raw SQL hvor muligt

• Hvis raw SQL er nødvendigt: bind parametre

Least privilege

• Databasebrugere må kun have nødvendige rettigheder

• Ingen SUPER, DROP eller FILE i runtime-brugere

Input-håndtering

• Valider type og længde

• Brug whitelists for kolonnenavne og sortering

Hvad beskytter ikke mod SQL Injection?

• HTML-escaping

• JavaScript-validering

• WAF som eneste forsvar

• “Vi bruger et framework”

Frameworks beskytter kun, hvis de bruges korrekt.

Forretnings- og udviklingsmæssig betydning

Kritikalitet

SQL injection er ofte game over. Angrebet kompromitterer hele systemet.

Tech Debt

Sårbarheden findes ofte i ældre kode, hotfixes eller edge cases.

Modenhed

Enhver moderne applikation uden korrekt SQL-beskyttelse er uacceptabel.

Udfordringer og løsninger

Udfordring: Legacy kodebase

Løsning: Gradvis refaktorering til prepared statements

Udfordring: Dynamisk filtrering

Løsning: Whitelist tilladte felter og operatorer

Udfordring: Performance-bekymringer

Løsning: Prepared statements forbedrer ofte performance

Opsummering

SQL injection er en velkendt og fuldt undgåelig sårbarhed.

Hvis SQL og brugerinput blandes direkte, er kompromittering kun et spørgsmål om tid.

Korrekt brug af parameterisering er ikke en “best practice”.

Det er et minimumskrav.