Forebygging av SQL-injeksjon
Forstå hvordan SQL Injection fungerer, og implementer robuste mottiltak ved hjelp av parametriserte spørringer og forberedte setninger.
Forebygging av SQL-injeksjon er en gratis leksjon i Sikker koding og OWASP Top 10 for backend på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Sikker koding og OWASP Top 10 for backend, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Sikker koding og OWASP Top 10 for backend inneholder totalt 4 leksjoner.
Hva er SQL-injeksjon?
Se for deg at du snakker med en database ved hjelp av et spesialspråk som heter SQL. Noen ganger kan angripere lure applikasjonen din til å sende uventede SQL-kommandoer til databasen.
Dette trikset kalles SQL-injeksjon (SQLi). Det oppstår når brukerinndata behandles som en del av selve SQL-kommandoen, i stedet for bare som data.
SQLi kan føre til:
- Tyveri eller endring av data
- Omgåelse av innloggingsskjermer
- Kontroll over databaseserveren
Slik fungerer SQLi: Et innloggingseksempel
La oss si at et innloggingsskjema tar imot brukernavn og passord. Applikasjonen kan bygge en SQL-spørring som denne for å kontrollere om du finnes:
SELECT * FROM users WHERE username = 'your_username' AND password = 'your_password';
Hva om 'your_username' ikke bare er et navn, men også en del av SQL-kode?
Den sårbare koden
En vanlig feil er å bygge SQL-spørringer ved å kombinere (sette sammen) brukerinndata direkte med spørringsstrengen. Her er et forenklet eksempel i Java:
public class Main {
public static void main(String[] args) {
String username = "admin"; // User input
String password = "pass123"; // User input
// DANGEROUS: String concatenation
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';";
System.out.println("Executing query:\n" + query);
// In a real app, this query would go to the database.
}
}Utarbeide skadelige inndata
Se nå for deg at en ondsinnet bruker skriver inn dette som brukernavn:
admin' OR '1'='1
Og en valgfri tekst som passord. Når dette kombineres med den sårbare spørringen, blir resultatet:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'any_password';
Delen OR '1'='1 gjør at betingelsen alltid blir sann. Dermed omgås passordsjekken, og angriperen logges inn!
Introduser prepared statements
Det beste forsvaret mot SQL-injeksjon er å bruke Prepared Statements (også kalt Parameterized Queries).
De skiller SQL-logikken fra dataene brukeren oppgir. I stedet for å sette inn inndata direkte bruker du plassholdere, for eksempel ?, i spørringen.
Databasen forstår da at alt som oppgis for disse plassholderne, er rene data og ikke en del av kommandoen.
Prepared statements i praksis
Slik bruker du en prepared statement til å søke trygt etter en bruker med ID-en deres. Legg merke til plassholderen ?.
public class Main {
public static void main(String[] args) {
int userId = 123; // User input
// Secure: Using a placeholder for the value
String sql = "SELECT name, email FROM users WHERE id = ?;";
// In a real application, you'd 'prepare' this SQL
// and then 'set' the parameter value (userId) separately.
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (id): " + userId);
// The database treats 'userId' as a value, not SQL code.
}
}Slik forhindrer parametere SQLi
Når du bruker en prepared statement:
- Ansvarsdeling: SQL-spørringens struktur sendes først til databasen.
- Data kontra kode: Databasen «forhåndskompilerer» spørringen. Når du deretter oppgir verdier for plassholderne, behandles de utelukkende som data.
- Automatisk escaping: Databasen håndterer automatisk eventuelle spesialtegn i inndataene dine, slik at de ikke tolkes som SQL-kommandoer.
Dette sikrer at skadelige inndata som ' OR '1'='1 ikke kan endre hensikten med spørringen.
Sikring av innloggingseksempelet
La oss rette det sårbare innloggingseksempelet ved hjelp av prepared statements. Selv om en bruker prøver å injisere SQL, vil det behandles som en del av brukernavnet eller passordet og ikke som en kommando.
public class Main {
public static void main(String[] args) {
String username = "admin' OR '1'='1"; // Malicious input
String password = "any_password"; // Malicious input
// SECURE: Using prepared statement with placeholders
String sql = "SELECT * FROM users WHERE username = ? AND password = ?;";
// Simulating how parameters are set (conceptual)
System.out.println("Prepared SQL: " + sql);
System.out.println("Parameter 1 (username): " + username);
System.out.println("Parameter 2 (password): " + password);
System.out.println("\nDatabase will look for a user with the literal username 'admin' OR '1'='1' and the given password. This user likely won't exist. Attack thwarted!");
}
}Utover innlogging: Alle SQL-operasjoner
Prepared statements er ikke bare for SELECT-spørringer. Du bør bruke dem for ALLE SQL-operasjoner som involverer brukerinndata:
INSERT-setninger (for eksempel når en ny bruker legges til)UPDATE-setninger (for eksempel når en brukerprofil endres)DELETE-setninger (for eksempel når data fjernes)
Anta alltid at brukerinndata er skadelige inntil det motsatte er bevist. Parameteriserte spørringer er den første forsvarslinjen din.
Kort kontroll: Sikker spørring
Hvilket av følgende kodeeksempler bruker parameteriserte spørringer korrekt for å forhindre SQL-injeksjon ved søk etter et produkt med navn?
Oppsummering: Forebygging av SQL-injeksjon
Godt jobbet! I denne leksjonen lærte du om:
- Hva SQL-injeksjon er, og hvilke farer det innebærer.
- Hvordan sårbare applikasjoner kan utnyttes ved å sette brukerinndata direkte inn i SQL-spørringer.
- Hvor viktig det er å bruke Prepared Statements (parameteriserte spørringer) som den viktigste forsvarsmekanismen.
- Hvordan prepared statements skiller data fra kode, slik at skadelige inndata ikke kan endre spørringslogikken.
Bruk alltid prepared statements for alle SQL-operasjoner som involverer brukerinndata, slik at backend-en din er sikker!
Lær deg Sikker koding og OWASP Top 10 for backend med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Forebygging av SQL-injeksjon» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Sikker koding og OWASP Top 10 for backend, inkludert «Forebygging av SQL-injeksjon», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Sikker koding og OWASP Top 10 for backend inneholder totalt 4 leksjoner.
Hva lærer jeg i «Forebygging av SQL-injeksjon»?
Forstå hvordan SQL Injection fungerer, og implementer robuste mottiltak ved hjelp av parametriserte spørringer og forberedte setninger. Du øver på Sikker koding og OWASP Top 10 for backend med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Sikker koding og OWASP Top 10 for backend?
Ingen tidligere erfaring er nødvendig. Sikker koding og OWASP Top 10 for backend på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.
Hvor lang tid tar leksjonen «Forebygging av SQL-injeksjon»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Sikker koding og OWASP Top 10 for backend-leksjonen?
Ja. Alle Sikker koding og OWASP Top 10 for backend-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Forebygging av SQL-injeksjon
- Kommando- og kodeinjeksjon
- Cross-Site Scripting (XSS) i backend
- Forebygging av XML- og LDAP-injeksjon