Injektion – när din kod luras att lyda någon annan

När gränsen mellan data och kommandon suddas ut

I en typisk applikation skickar användaren in data, till exempel ett användarnamn, ett lösenord eller ett formulär. Den informationen ska behandlas som just det: data. Programmet ska jämföra, spara eller hantera innehållet, men inte agera på det som instruktioner.

Vid en injektion suddas gränsen mellan kod och data ut. Det som ser ut som inmatning kan plötsligt tolkas som ett kommando, och då gör applikationen något helt annat än vad utvecklaren tänkt sig. Det är detta som gör injektion så farligt: användaren styr programflödet utan att ha rätt att göra det.

Låt oss ta ett konkret exempel:

string userCheckQuery = $"SELECT * FROM Users WHERE Username = ‘{model.Username}' AND Password='{model.Password}'";
var command = new SqlCommand(query, connection);

Här byggs en SQL-fråga upp genom att stoppa in användarens inmatade namn rakt in i frågan. Det betyder att någon kan skriva detta som användarnamn:

' OR 1=1 --

Eftersom — påbörjar en kommentar, förändrar detta frågan till:

SELECT * FROM Users WHERE Username = ' OR 1=1 --' …

Den här frågan är alltid sann, och kommenterar bort resten. Resultatet? Angriparen loggas in, oavsett vilket lösenord som angivits.

Hur allvarligt kan det bli?

En lyckad injektionsattack kan ge angriparen långt mer än bara obehörig inloggning. Med hjälp av verktyg som automatiskt testar olika tekniker kan en angripare:

· Läsa hela databasen, inklusive personuppgifter och lösenord.

· Radera, manipulera eller ersätta befintlig information.

· Skapa nya användare med höga rättigheter.

· Använda sårbarheten för att komma åt bakomliggande system eller köra godtycklig kod.

Det är inte ovanligt att en injektionssårbarhet blir startpunkten för en fullständig systemkompromettering, särskilt om databasanvändaren har för breda rättigheter eller om fler komponenter är dåligt isolerade.

Varför händer det här?

Injektion beror nästan alltid på två saker:

För det första: att kommandon och data blandas. När man bygger SQL-frågor (eller motsvarande) som strängar, och stoppar in användarens indata direkt, riskerar man att databasen tolkar den som kod.

För det andra: att applikationen har för hög tilltro till användarens indata. Programmet antar att det som skickas in är ofarligt, men en angripare utnyttjar precis det. Och det gäller inte bara formulär, även lagrade data kan innehålla skadlig kod om den skrivs till ett skript, loggas eller används i ett nästa steg.

Hur skyddar vi oss?

Det mest effektiva sättet att skydda sig mot injektion är att aldrig låta användarens indata påverka programflödet direkt. Här är några viktiga åtgärder du kan ta till:

1. Parametrisera frågor

Med parametrar skiljer vi strikt mellan kod och data. Så här kan ett säkrare alternativ se ut i .NET:

var userCheckQuery = "SELECT * FROM Users WHERE Username = @Username AND Password = @Password"; var command = new SqlCommand(query, connection); command.Parameters.AddWithValue("@Username", model.Username); command.Parameters.AddWithValue("@Password", model.Password);

Här talar vi om för databasen att det vi stoppar in i användarnamnet inte är kod – utan data. Oavsett vad någon försöker skriva in kommer det aldrig att tolkas som ett kommando.

2. Validera och sanera indata

Även om parametrisering är viktigast, bör du komplettera med att kontrollera vad som kommer in. Är det ett tal, en e-postadress eller ett begränsat antal val? Sätt tydliga regler. Men kom ihåg: validering är inte ett skydd i sig, det är ett komplement.

3. Minimera rättigheter i databasen

Den användare som applikationen använder för att prata med databasen bör bara ha de rättigheter som krävs. Ska den bara läsa? Då ska den inte kunna skriva, radera eller skapa nya användare. Det minimerar skadan om något går fel.

4. Logga och övervaka ovanligt beteende

Har någon plötsligt gjort hundratals likadana anrop, eller skickat in märklig syntax i ett formulär? Logga inmatning och beteende, det kan hjälpa dig att upptäcka attacker innan de lyckas.

5. Använd ORM-ramverk korrekt

Ramverk som Entity Framework och Hibernate har inbyggda skydd mot injektion, men bara om du använder dem rätt. Undvik att skapa egna SQL-strängar, och lita på ramverkets metoder för att hantera frågor.

Sammanfattning

Injektion uppstår när vi blandar kod och data, och alltså låter användaren styra mer än den borde. Det är som att ge någon ett formulär, men också låta dem skriva om instruktionerna för hur det ska behandlas. Resultatet? Total kontroll för angriparen.

Lösningen är tydlig separering: använd parametrar, håll hårt på rättigheter och testa din implementation. Det är ett litet steg i koden, men ett stort steg mot en säkrare applikation.

Glöm heller inte att det finns fler typer av injektion än SQL: kommandorad, LDAP, NoSQL, ORM, XML, loggar, och fler.

Vill du se hur det här fungerar i praktiken? Kolla in vår video nedan, där visar vi hur en injektion fungerar, och hur lätt det kan gå fel.

Är du osäker på hur ditt system hanterar indata? Kontakta vårt AppSec-team på appsec@decerno.se. Vi hjälper dig få kontroll över dina indataflöden.