SQL-injektion och kommandoinjektion

SQL-injektion (SQLi) uppstår när en angripare infogar eller ”injicerar” skadlig SQL-kod i ett inmatningsfält som senare skickas vidare till en databasfråga. Eftersom applikationen sammanfogar användarens indata direkt med en SQL-sats kan databasen inte skilja mellan legitima data och kommandon som angriparen har skickat. SQLi rankas konsekvent som en av de farligaste webbrelaterade sårbarheterna i OWASP Top 10.

En sårbar inloggningsfråga kan se ut så här: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. En angripare som anger ' OR '1'='1 som användarnamn omvandlar frågan så att WHERE-villkoret alltid är sant, vilket helt kringgår autentiseringen. Detta är den klassiska injektionen baserad på en tautologi.

SQL-injektionsattacker förekommer i flera former: In-band SQLi returnerar resultat direkt i HTTP-svaret (baserad på fel eller union). Blind SQLi härleder data genom booleska svar som är sanna eller falska, eller genom avsiktliga tidsfördröjningar (SLEEP(5)). Out-of-band SQLi använder sekundära kanaler, till exempel DNS-uppslagningar, för att exfiltrera data när svaren inte är synliga.

Det främsta skyddet mot SQL-injektion är parametriserade frågor (även kallade förberedda satser). I en parametriserad fråga kompileras SQL-strukturen först, och användarens indata skickas som en separat parameter – den kan aldrig ändra frågans struktur. Denna metod är språkoberoende och betydligt mer tillförlitlig än enbart sanering av indata.

Även om parametriserade frågor är det främsta skyddet utgör indatavalidering ett viktigt sekundärt lager. Validering med allowlist godkänner endast förväntade tecken (till exempel enbart alfanumeriska tecken i ett användarnamnsfält) och avvisar allt annat. Validering med denylist blockerar kända skadliga tecken, men angripare kodar eller förvränger ofta payloads för att kringgå denylistor – därför är allowlistor betydligt starkare.

Kommandeinjektion (OS command injection) uppstår när en applikation skickar osanerad användarindata till ett systemskal. Till skillnad från SQL-injektion, som riktar sig mot databaser, riktar sig kommandeinjektion mot själva operativsystemet – vilket ger angripare möjlighet att köra godtyckliga kommandon med samma behörigheter som webbserverprocessen. Den bedöms ha kritisk allvarlighetsgrad och leder ofta till att hela systemet komprometteras.

En webbapp som pingar en IP-adress som användaren anger kan använda: ping -c 1 INPUT. Om en angripare anger 8.8.8.8; cat /etc/passwd tolkar skalet ; som en kommandoseparator och kör båda kommandona. Vanliga injektionsoperatorer är ;, &&, ||, | och ersättning av kommandon med backtick.

Det säkraste skyddet mot kommandeinjektion är att helt undvika att anropa OS-kommandon från användarindata – använd biblioteksfunktioner som åstadkommer samma sak. När skalanrop inte kan undvikas ska argument skickas som en lista (aldrig som en sammanfogad sträng), skaltolkning inaktiveras, indata valideras mot en strikt allowlist och processer köras med ett användarkonto med så små behörigheter som möjligt.

OWASP:s topp 10 listar injektion (som omfattar SQL-, NoSQL-, OS- och LDAP-injektion) som en av de mest kritiska säkerhetsriskerna i applikationer. OWASP rekommenderar ett försvar på djupet: använd säkra API:er som undviker tolken, utför positiv indatavalidering (allowlist) på serversidan, escape:a specialtecken med den syntax som är specifik för tolken och använd SQL-kontroller som LIMIT för att förhindra massutlämning av data.

En brandvägg för webbapplikationer (WAF) kan upptäcka och blockera vanliga injektionspayloads genom att inspektera HTTP-begäranden mot signaturmönster. WAF:er kan dock kringgås med hjälp av kodningsknep och ersätter inte säker kodning. Korrekt loggning av applikationen — där frågeparametrar, svarskoder och felmeddelanden registreras — gör det möjligt för säkerhetsteam att identifiera injektionsförsök vid incidentgranskning.

Injektionsattacker har orsakat några av historiens största dataintrång. Intrånget hos Equifax 2017 exponerade 147 miljoner poster via en sårbarhet i en webbapplikation. En SQL-injektion mot Sony PlayStation Network äventyrade 77 miljoner konton 2011. Dessa incidenter visar att injektionssårbarheter får extrem verksamhetspåverkan: datastöld, myndighetsböter, skadat anseende och juridiskt ansvar följer alla efter en lyckad injektionsattack.

I den här lektionen lärde du dig att: SQL-injektion utnyttjar osanerad indata som sammanfogats med databasfrågor, kommandoinjektion skickar skadlig indata till OS-skalet via operatorer som ; och | och parametriserade frågor samt att undvika shell=True är de huvudsakliga försvaren. Härnäst går vi igenom Cross-Site Scripting (XSS) och CSRF-attacker.