Hvis det er én ting nettkriminelle elsker, så er det data. Stjålne data er svært verdifulle på ulovlige markedsplasser, og tilgang til private databaser kan være en fin måte for ondsinnede aktører å tjene penger på sine virksomheter. En måte å få tilgang til private data på er via en SQL-injeksjon. Men hva er egentlig en SQL-injeksjon, hvordan fungerer den, og kan et slikt angrep forhindres?
Hva er en SQL-injeksjon?
Programvare er avhengige av kode for å fungere. Kode er også språket som maskiner bruker for å utføre operasjoner, og kan komme i mange former (Python, JavaScript, C++, etc.). Det er ofte gjennom kode at nettkriminelle kan angripe ofre, og SQL-injeksjoner (eller SQLis) er ikke annerledes. Disse lar ondsinnede aktører "injisere" skadelig kode i en SQL-setning.
La oss først gå gjennom hva SQL betyr.
SQL står for Structured Query Language.
Dette er en annen type programmeringsspråk spesielt brukt når du arbeider med databaser. SQL ble utviklet på 1970-tallet av IBM og kan manipulere, lagre og hente databaseinformasjon. Mange databasekommunikasjonssystemer rundt om i verden bruker SQL, så det er ingen overraskelse at trusselaktører har utviklet måter å misbruke det for å målrette mot databaser.SQL-setninger utgjør en sentral del av databasekommunikasjon. En SQL-setning er en kommando som kommer i mange forskjellige former. Noen endrer data, noen henter eller sletter dem, og noen kan endre strukturen til selve databasen. Når en SQL-injeksjon oppstår, injiseres den skadelige koden i en SQL-setning.
Selvfølgelig må et nettsted eller en applikasjon bruke SQL-programmeringsspråket for at en SQL-injeksjon skal være mulig. Men hvordan fungerer denne angrepsvektoren?
La oss si at du har en vanlig kodelinje som brukes av en applikasjon. Når en nettkriminell setter inn en ondsinnet SQL-injeksjon, legges det til en kodelinje som kan forstyrre spørringene applikasjonen selv sender til databasen. Ved å gjøre dette kan databasen utnyttes på en måte som gjør at trusselaktøren kan se data som de ellers ikke ville hatt tilgang til.
Herfra kan nettkriminelle stjele data for å utnytte dem direkte eller selge den på det mørke nettet eller andre steder. De kan også endre, legge til eller slette data fra den målrettede databasen. Avhengig av graden av SQL-injeksjonsangrepet, kan mye skade gjøres. Hvis betalingsopplysninger, personnummer eller andre typer private data er tilgjengelig, kan mange mennesker risikere å bli utnyttet.
På den annen side, hvis angriperen klarer å endre databasen betydelig, kan store deler av data gå tapt permanent. Alt i alt kan SQL-injeksjoner ødelegge hele databaser gjennom bare ett angrep. Selv om de har eksistert siden 1998, er de fortsatt relevante og farlige i våre dager.
Som funnet av Open Web Application Security Project (OWASP)274 000 forekomster av SQL-injeksjoner ble identifisert ved testing av applikasjoner for tilstedeværelsen av et slikt angrep i 2021.
Typer av SQL-injeksjon
Det finnes noen få forskjellige typer SQL-injeksjon, med de tre viktigste blind-, in-band- og out-of-band-injeksjoner.
En blind (eller inferensiell) SQL-injeksjon oppstår når applikasjonen eller nettstedet blir angrepet av injeksjon, men HTTP-svarene (Hypertext Transfer Protocol) som er oppgitt inneholder ikke resultatet av SQL-spørring. Med andre ord, ingen data fra databasen som er angrepet blir gitt til nettkriminelle. Så, hva er vitsen med dette?
Ved å bruke en blind SQL-injeksjon sender en angriper data til målserveren og kan deretter skjelne visse ting om en database gjennom arten av selve HTTP-svaret. På toppen av dette kan faktorer knyttet til HTTP-responsen hjelpe angriperen til å lage en annen, mer effektiv SQL-injeksjon for å få tilgang til databasen.
Det er to nøkkeltyper blind SQL-injeksjon, kjent som tidsbasert og boolsk. Disse to variantene er ganske like i sin natur. Både en boolsk og tidsbasert SQL-injeksjon sender en rekke ja- eller nei-svarspørsmål, selv om sistnevnte vil kreve at databasen venter en kort stund før den svarer på spørsmålene.
Neste opp er det in-band SQL-injeksjoner. In-band SQL-injeksjoner lar operatøren utføre angrepet og få ønsket resultat ved å bruke samme kanal. In-band SQL-injeksjoner er de mest brukte, rett og slett fordi de er de enkleste å utføre på grunn av det faktum at de bare krever én kanal.
Til slutt har du en SQL-injeksjon utenfor båndet. Dette er i hovedsak den alternative versjonen av en in-band SQL-injeksjon, der angriperen ikke kan utføre angrepet totalt ved å bruke én enkelt kanal. Alternativt kan et angrep måtte ty til en SQL-injeksjon utenfor båndet hvis målserveren rett og slett ikke er rask nok til å gi resultater.
Disse faktorene gjør prosessen litt vanskeligere, noe som betyr at den må stole på visse funksjoner for å være aktiv på den målrettede databasen for å lykkes. For eksempel må plattformen som blir angrepet ha mangel på inngangssanering. På grunn av dette er in-band SQL-injeksjoner langt mer vanlig enn out-of-band SQL-injeksjoner. Men de skjer fortsatt.
Kan SQL-injeksjoner unngås?
SQL-injeksjoner er mer en bekymring for bedrifter og organisasjoner enn vanlige enkeltpersoner. Men det er ting som disse potensielle målene kan gjøre for å redusere sjansen for å bli truffet av et slikt angrep.
Inndatasanering er den viktigste vanlige praksisen for å unngå SQL-injeksjoner. Dette er en filtreringsprosess som skanner og renser inndata for farlige tegn. Hvis SQL-kode behandles før den renses, vil sjansen for en SQL-injeksjon naturlig nok øke.
I tillegg kan parameteriserte spørringer hjelpe deg med å unngå SQL-injeksjoner. Dette er spørringer som krever minst én parameter for utførelse. Å bruke parametere gjør det vanskeligere for nettkriminelle å gjennomføre et SQL-injeksjonsangrep.
Men det er ingen sikker måte å forhindre en SQL-injeksjon på. Som tilfellet er med mange nettangrep, er det ganske umulig å holde enhetene og systemene dine helt lufttette. Når det gjelder SQL-injeksjoner, er det beste du kan gjøre å rense alle innganger og etablere parameteriserte spørringer.
SQL-injeksjoner er eldre, men fortsatt en trussel
Selv om SQL-injeksjoner har eksistert i over 20 år, utgjør de fortsatt en risiko for mange nettsteder og applikasjoner. Så det er en god idé å ha denne formen for angrep i tankene og ta de nødvendige skritt for å prøve å forhindre det, da det kan utgjøre en trussel mot databasene dine på et tidspunkt i fremtiden.