I denna övning utforskar vi **SQL Injection (SQLi)**, en allvarlig server-sidans sårbarhet. SQLi utnyttjar en applikations oförmåga att skilja på **data** och **kommandon**. När användarinmatning läggs direkt till en SQL-fråga utan sanering, kan en angripare injicera egen SQL-kod och manipulera databasens operationer.
Denna variant, **Error-based SQLi**, är särskilt pedagogisk (och farlig i skarpa system) eftersom applikationen är konfigurerad att visa de tekniska felmeddelandena direkt från databasen. Dessa felmeddelanden ger angriparen värdefull intern information om databasens struktur, versioner och den exakta SQL-frågan som misslyckades. Denna information kan sedan användas för att fullända attacken och exfiltrera (stjäla) data.
SELECT * FROM users WHERE username = '{$username}' AND password = '{$password}'. De enkla citattecknen (') runt variablerna är nyckeln till attacken.') för att avbryta den ursprungliga frågans sträng. Databasen försöker köra den ogiltiga syntaxen och returnerar ett detaljerat fel.' OR '1'='1. Detta ändrar frågan till: SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'.'1'='1' alltid är sant, ignorerar databasen lösenordskontrollen och returnerar alla rader. I en inloggningsfunktion returneras den första användaren, oftast **admin**, vilket leder till en lyckad inloggning utan lösenord.Den primära försvarsmekanismen mot alla typer av SQL Injection är att **aldrig använda strängkonkatenering** för att bygga SQL-frågor med användarinmatning. Istället ska man använda: