Vad är en SQL-injektion? [MakeUseOf Förklarar]

Världen av Internet-säkerhet plågas med öppna portar, bakdörrar, säkerhetshål, trojaner, maskar, brandväggssårbarheter och en rad andra problem som håller oss alla på tårna varje dag. För privata användare verkar virus och maskar vara de värsta av möjligheterna. Men för alla som kör en databas är SQL-injektionen en av de mest destruktiva säkerhetsbristerna där ute.

Databaser är extremt värdefulla inom datorernas rike. De är viktiga för att lagra data som minne och visa de olika relationerna mellan datapunkter. Här på MakeUseOf har vi många databaser som är avsedda för olika uppgifter: en för alla våra artiklar, en för vår användarbas, en för vårt belöningssprogram, och listan fortsätter. Vad händer när våra databaser skadas angripligt - eller till och med förstörs?

När du inte har faktisk tillgång till en databas är SQL-injektionen en av de mest framträdande attackerna. Fortsätt läsa för att lära dig vad det är exakt och hur det kan vara så farligt.

Vad är SQL, hur som helst?

För att förstå SQL-injektion måste du först förstå vad SQL är och hur det hänför sig till en webbplats. SQL, som står för Structured Query Language, är en typ av programmeringsspråk optimerat för hantering av tabelldata. För alla ändamål är det bara ett sätt för programmerare att kommunicera med en databas och ge det kommandon.

När en databas tas upp, finns det SQL-kommandon som ges och bearbetas. Om du tänker på alla tider när en databas handlas på, kommer du att dra slutsatsen att det bara händer under en mängd omständigheter:

• När nya data behöver infogas,
• När nuvarande data behöver ändras,
• När gamla data måste raderas,
• När en viss data måste söks och hämtas.

När som helst en av dessa åtgärder måste inträffa, körs ett SQL-kommando någonstans på en server. För det mesta får programmeraren bestämma när och var dessa SQL-kommandon uppträder i källkoden. Det finns emellertid oundvikliga omständigheter när en användare kan tvinga manipulation av en databas - och dessa möjligheter ligger runt dig.

Har du någonsin loggat in på en webbplats? Har du någonsin lagt fram en kommentar på en bloggartikel eller ett svar i en forumtråd? Har du någonsin skickat ett Facebook-meddelande till en vän? Skrivit ett e-postmeddelande i Gmail? Sökte efter en webbplats på Google? Varje gång du ser ett inmatningsfält på en webbplats (användarnamn, lösenord, sökfråga, meddelandefält, etc.) skickas den texten till databasen och handlar om.

Om en skadlig användare vill manipulera med en databas finns det inte så många val för honom. En möjlighet skulle vara att få faktiska fysisk tillgång till servern och förstör den vid dess bas. Men annars är det mest vettigt för den skadliga användaren att kapra ett befintligt SQL-kommando när man använder ett inmatningsfält, vilket tvingar servern att utföra ett kommando som skiljer sig från det som ursprungligen var tänkt.

SQL-injektionstekniken

Denna handling att kapra ett befintligt SQL-kommando är vad SQL-injektion avser. Varför kallas det injektion? Eftersom kapning av ett SQL-kommando kräver att användaren injicerar sin egen SQL-kod när han använder ett inmatningsfält. Låter det förvirrande? Låt mig illustrera med ett exempel.

Tänk på MakeUseOfs inloggningssida. När du anger ditt användarnamn och lösenord och träffar “Lämna“, du tvingar webbservern att generera ett SQL-kommando som innefattar den information du bara gav-det vill säga ditt användarnamn och lösenord. Databasen tar emot informationen, verifierar att användarnamnet / lösenordskombinationen är korrekt och ger dig rätt åtkomst till andra delar av webbplatsen.

Tänk nu vad som skulle hända om en skadlig användare inte angav sitt användarnamn och lösenord, utan istället skrev han ett SQL-kommando som sitt användarnamn? Om serverns kod inte är ordentligt säkrad kommer databasen att få felaktigt användarnamn (vilket egentligen är ett SQL-kommando) och faktiskt kör det som ett kommando.

Och det är därför det kallas injektion. SQL-kommandot sprutas in i databasen via helt legitimt sätt, manipulera det så att det slutar göra något det inte var tänkt att göra.

Ett avancerat exempel

Hittills har jag beskrivit SQL-injektion på hög nivå så att alla kan förstå - även de som inte har programmeringskunskap. I det här avsnittet kommer jag att ge ett verkligt exempel på på vilket sätt denna teknik är möjlig. Om du är en SQL-nybörjare, eller om du aldrig har behandlat programmeringen tidigare, kan du tyst hoppa över den här sektionen.

När du loggar in på en webbplats, är det här ett möjligt sätt att koden skulle kunna skrivas i SQL:

SELECT user_id
FRÅN users_db
VAR användarnamn = "$ användarnamn" och lösenord = "$ lösenord"

I princip begär kommandot att databasen ska returnera alla user_ids från bordet users_db som matchar det inmatade användarnamnet och lösenordskombinationen. Ser allt bra och dammigt, rätt?

Låt oss anta att inloggningsformuläret fick följande ingångar:

Användarnamn: David
Lösenord: fubar 'OR' x '=' x

Observera att lösenordsfältet inte börjar eller slutar med en apostrof. När servern tar emot detta inloggningsförsök tar det allt som anges i lösenordsfältet och lägger det i stället för $ lösenordet i koden. Det resulterande SQL-kommandot kommer att se ut så här:

SELECT user_id
FRÅN users_db
VAR användarnamn = "David" och lösenord = 'fubar 'ELLER' x '=' x'

När servern kör det här kommandot kommer den sista delen av det SQL-kommandot att alltid returnera sant. Det innebär att den skadliga användaren kan skriva in något användarnamn och få tillgång till det kontot, eftersom inloggningen skulle fungera om han fick lösenordet eller inte.

Att logga in på någons konto är naturligtvis ett ganska mildt brott när du jämför det med alla andra möjliga hackförsök: radera hela databaser, mucka upp alla data eller till och med stjäla data i databaserna.

Professionella webbutvecklare blir bättre och bättre för att förhindra sådana knep, men du kommer en gång i taget att höra att ett företag drabbats av förlust i händerna på en SQL-injektionsattack. När det händer vet du nu vad det betyder och hur det är möjligt.

Bildkrediter: Intro Image Via Shutterstock, Databasschema Via Shutterstock, HACKED Via Shutterstock