SQL-injektion og command injection
Lær, hvordan angribere udformer injection-payloads, der manipulerer databaseforespørgsler eller operativsystemkommandoer, og hvordan parametriserede forespørgsler og inputvalidering forhindrer dem.
SQL-injektion og command injection er en gratis Security+ Academy-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Security+ Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Security+ Academy-kurset indeholder 4 lektioner i alt.
Hvad er SQL-injektion?
SQL-injektion (SQLi) opstår, når en angriber indsætter eller »injicerer« ondsindet SQL-kode i et inputfelt, som senere sendes videre til en databaseforespørgsel. Fordi applikationen sammenkæder brugerinput direkte med en SQL-sætning, kan databasen ikke skelne mellem legitime data og kommandoer fra angriberen. SQLi ligger konsekvent blandt de farligste websårbarheder på OWASP Top 10.
Eksempel på klassisk SQLi-payload
En sårbar loginforespørgsel kan se sådan ud: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Hvis en angriber angiver ' OR '1'='1 som brugernavn, ændres forespørgslen, så WHERE-betingelsen altid er sand, og godkendelsen omgås fuldstændigt. Dette er den klassiske tautologibaserede injektion.
-- Vulnerable query (DO NOT use in production)
SELECT * FROM users
WHERE username = '' OR '1'='1'
AND password = 'anything';
-- Returns ALL rows — auth bypassedTyper af SQL-injektion
SQL-injektionsangreb findes i flere former: In-band SQLi returnerer resultater direkte i HTTP-svaret (fejlbaseret eller unionbaseret). Blind SQLi udleder data gennem booleske sand/falsk-svar eller bevidste tidsforsinkelser (SLEEP(5)). Out-of-band SQLi bruger sekundære kanaler som DNS-opslag til at eksfiltrere data, når svarene ikke er synlige.
-- Time-based blind SQLi example
SELECT * FROM users
WHERE id = '1' AND SLEEP(5)--';
-- If response is delayed 5s, injection succeededForebyggelse af SQLi: parametriserede forespørgsler
Det primære forsvar mod SQL-injektion er parametriserede forespørgsler (også kaldet prepared statements). I en parametriseret forespørgsel kompileres SQL-strukturen først, og brugerinput sendes som en separat parameter — det kan aldrig ændre forespørgslens struktur. Denne tilgang er uafhængig af programmeringssprog og langt mere pålidelig end input-sanitering alene.
# Python example — parameterized query (safe)
import sqlite3
conn = sqlite3.connect('app.db')
cursor = conn.cursor()
username = 'admin'
password = 'secret'
cursor.execute(
'SELECT * FROM users WHERE username=? AND password=?',
(username, password) # parameters, never concatenated
)Inputvalidering som forsvar i dybden
Selvom parametriserede forespørgsler er det primære forsvar, udgør inputvalidering et vigtigt sekundært lag. Validering med en tilladelsesliste accepterer kun forventede tegn (f.eks. kun alfanumeriske tegn i et brugernavnsfelt) og afviser alt andet. Validering med en afvisningsliste blokerer kendte skadelige tegn, men angribere koder eller slører ofte payloads for at omgå afvisningslister — derfor er tilladelseslister langt stærkere.
Hvad er kommandoinjektion?
Kommandoinjektion (OS-kommandoinjektion) opstår, når en applikation sender usaniteret brugerinput til en systemskal. I modsætning til SQL-injektion, som angriber databaser, angriber kommandoinjektion selve operativsystemet — og giver angribere mulighed for at køre vilkårlige kommandoer med de rettigheder, som webserverprocessen har. Den vurderes som kritisk alvorlig og fører ofte til fuldstændig kompromittering af systemet.
Eksempel på kommandoinjektion
En webapp, der pinger en IP-adresse angivet af brugeren, kan bruge: ping -c 1 INPUT. Hvis en angriber angiver 8.8.8.8; cat /etc/passwd, fortolker skallen ; som en kommandoseparator og kører begge kommandoer. Almindelige injektionsoperatorer omfatter ;, &&, ||, | og kommandosubstitution med backticks.
# Vulnerable Python (subprocess with shell=True)
import subprocess
user_ip = '8.8.8.8; cat /etc/passwd' # attacker input
subprocess.run('ping -c 1 ' + user_ip, shell=True)
# Safe alternative — avoid shell=True, pass args as list
subprocess.run(['ping', '-c', '1', '8.8.8.8'])Forebyggelse af kommandoinjektion
Det sikreste forsvar mod kommandoinjektion er helt at undgå at kalde OS-kommandoer fra brugerinput — brug biblioteksfunktioner, der opnår det samme. Når kald til skallen ikke kan undgås, skal du sende argumenter som en liste (aldrig som en sammenkædet streng), deaktivere fortolkning af skalkommandoer, validere input mod en streng tilladelsesliste og køre processer med den mindst privilegerede brugerkonto, der er mulig.
OWASP-kontekst: Injection i top 10
OWASP Top 10 angiver Injection (som omfatter SQL-, NoSQL-, OS- og LDAP-injection) som en af de mest kritiske sikkerhedsrisici i applikationer. OWASP anbefaler en forsvar-i-dybden-tilgang: Brug sikre API'er, der undgår fortolkeren, udfør positiv inputvalidering på serversiden ved hjælp af en tilladelsesliste, escap specialtegn ved hjælp af den syntaks, der gælder for den pågældende fortolker, og brug SQL-kontroller som LIMIT for at forhindre masseudlæsning.
Registrering: WAF'er og logning
En Web Application Firewall (WAF) kan registrere og blokere almindelige injection-payloads ved at inspicere HTTP-anmodninger og sammenligne dem med signaturmønstre. WAF'er kan dog omgås ved hjælp af kodningstricks og kan ikke erstatte sikker programmering. Korrekt logning af applikationen — hvor forespørgselsparametre, svarkoder og fejlmeddelelser registreres — gør det muligt for sikkerhedsteams at identificere injection-forsøg under gennemgang af hændelser.
Injection-angreb i den virkelige verden
Injection-angreb har forårsaget nogle af historiens største databrud. Equifax-bruddet i 2017 afslørede 147 millioner poster via en fejl i en webapplikation. SQL-injection mod Sony PlayStation Network kompromitterede 77 millioner konti i 2011. Disse hændelser viser, at injection-sårbarheder kan have ekstrem indvirkning på virksomheden: Datatyveri, bøder fra myndigheder, skade på omdømmet og juridisk ansvar følger alle efter et vellykket injection-angreb.
Hurtigt tjek
Test din forståelse af CompTIA Security+ (SY0-701)-begreberne fra denne lektion.
Opsummering af lektionen
I denne lektion har du lært, at SQL-injection udnytter ufiltreret input, der er sammenkædet med databaseforespørgsler, at command injection sender skadeligt input til operativsystemets shell via operatorer som ; og |, og at parameteriserede forespørgsler og undgåelse af shell=True er de primære forsvarsmekanismer. Næste gang ser vi på Cross-Site Scripting (XSS) og CSRF-angreb.
Lær Security+ Academy med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 30
- Lektioner
- 120
Ofte stillede spørgsmål
Er lektionen “SQL-injektion og command injection” gratis?
Ja — alle 3 lektioner i læringssporet Security+ Academy, inklusive “SQL-injektion og command injection”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Security+ Academy-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “SQL-injektion og command injection”?
Lær, hvordan angribere udformer injection-payloads, der manipulerer databaseforespørgsler eller operativsystemkommandoer, og hvordan parametriserede forespørgsler og inputvalidering forhindrer dem. Du øver dig i Security+ Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Security+ Academy?
Der kræves ingen tidligere erfaring. Security+ Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.
Hvor lang tid tager lektionen “SQL-injektion og command injection”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Security+ Academy-lektion?
Ja. Alle Security+ Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- SQL-injektion og command injection
- Cross-Site Scripting (XSS) og CSRF
- Defekt godkendelse og usikker deserialisering
- Sikker SDLC samt SAST- og DAST-værktøjer