SQL-injeksjoner: Hvorfor er det hackernes favorittvalg?

SQL-injeksjoner: Hvorfor er det hackernes favorittvalg?

Siden 2003 har SQL-injeksjoner holdt seg på topp 10-listen over sikkerhetsproblemer. Hvorfor er det hackernes favorittvalg? Hvorfor er det den største trusselen mot applikasjonssikkerhet? Hvorfor er det fremdeles aktuelt etter alle disse årene? Svaret er: det fungerer! Det er enkelt å utføre og virkningen er katastrofal.

Bildet nedenfor illustrerer Akamais daglige oppdateringer om «the state of the internet» (bilde er tatt 13.09.2020).

The state of the internet

SQL-inteksjoner definisjon

SQL-injeksjonsangrep består av innsetting eller “injeksjon” av SQL-spørring via inngangsdataene fra klienten til applikasjonen.

En vellykket SQL-injeksjonsutnyttelse kan lese sensitive data fra databasen, endre databasedata (Insert / Update / Delete), utføre administrasjonsoperasjoner på databasen (for eksempel å avslutte DBMS), gjenopprette innholdet i en gitt fil som er tilstede på DBMS-filen systemet, og i noen tilfeller gi kommandoer til operativsystemet. 

Utføring av et SQL-injeksjonsangrep

Når webapplikasjonen snakker med databasen, må den autentisere. Så webapplikasjonen har database-credentials lagret i den, som den bruker til å identifisere seg selv når den går til databasen. Hva er det webapplikasjonen er tillatt å gjøre? Hvilken legitimasjon har den? Hvilke data kan den lese/skrive? Hvilke kommandoer kan den utføre på databaseserveren?

Ofte vil webapplikasjonen koble til databasen ved hjelp av samme identitet uavhengig av hvem brukeren er.

SQL-injeksjon avhenger av forståelsen av SQL

Vi lister opp noen viktige ting du må ha forståelse for når du skal jobbe med SQL.

Enkel SQL-syntaks

SELECT fruitName, fruitColor FROM FruitTable

SELECT * FROM FruitTable

SELECT fruitName, fruitColor FROM FruitTable WHERE  fruitColor = ‘yellow’

SELECT fruitName, fruitColor FROM FruitTable WHERE  fruitID = 2

Når du bygger SQL-injeksjonsangrep, bruker du utsagnstermineringer (;) og kommentarsyntaks () for å avslutte spørringen, og ignorere alt som kommer etter at den ondsinnede koden skal settes inn i databasen.

Utsagnstermineringer

; brukes til å avslutte statements i SQL.

SELECT * FROM FruitTable; SELECT * FROM usersTable;

; lar oss avslutte en spørring og utføre en annen.

Kommenterer ut

Følgende brukes til å kommentere ut:

 

 

  • /* comment */

 

 

SELECT fruitName, fruitColor FROM FruitTable; — WHERE  fruitColor = ‘yellow’;

Avsluttet den første delen av spørringen og kommenterte ut resten av spørringen fra WHERE.

Hvordan oversettes handlinger i nettleseren til spørringer på databaseserveren?

Når en bruker skriver inn et brukernavn og passord i nettleseren, blir det sannsynligvis oversatt til følgende SQL-spørring:

SELECT * FROM tableName WHERE userName=’username’ and password=’password’

Du kan også manipulere URL-en eller andre inndatafelt i nettleseren, for eksempel søkefelt:

http://fruitsite.com/fruit?fruitID=2

Du kan se at det er en bane som heter frukt som sender en spørring string som heter fruitID med verdien 2. Når den URL-en brukes, genererer den et SQL-spørring som sannsynligvis ser slik ut:

SELECT * FROM FruitTable WHERE  fruitID = 2;

SQL-injeksjon handler om å manipulere parametrene i et webapplikasjon slik at det kan endre den underliggende spørringen.

Vi kan bruke et enkelt tegn (single quote ) for å teste om et nettsted har en risiko for SQL-injeksjon

http://fruitsite.com/fruit?fruitColor=yellow

Ovennevnte URL er en http GET-forespørsel og oversettes til følgende spørring:

SELECT * FROM FruitTable WHERE  fruitColor = ‘yellow

Hvis du legger til et på slutten av yellow:

http://fruitsite.com/fruit?fruitColor=yellow

Det får SQL-setningen til å se slik ut:

SELECT * FROM FruitTable WHERE  fruitColor = ‘yellow

Det er ikke lenger gyldig SQL-syntaks.

Hvis du får et internt exception i nettleseren, er det sannsynlig at den har en risiko for SQL-injeksjon.

På samme måte kan du skrive et   i brukernavnfeltet eller passordfeltet på en påloggingsside.

Eksempel pålogging med SQL

La oss ta ett skritt videre. La oss legge til (or 1=1–) i URL-en eller brukernavnet og passordet på påloggingssiden:

http://fruitsite.com/fruit?fruitColor=yellow’ or 1=1–

Det vil føre til at SQL-setningen ser slik ut:

SELECT * FROM FruitTable WHERE  fruitColor = yellow’ or 1=1–

Sign in SQL eksempel

Forklaring:

WHERE  fruitColor = ‘yellow’ or 1=1–

Denne ‘yellow’ string er lukket av med det eneste som vi sendte inn i spørrings string.

Deretter passerte vi en or operatør, og så legger vi til en annen condition i WHERE-setningen.

1=1 vil alltid være SANT, og å kombinere 1=1 med or operatoren (or 1=1 og deretter returnere resultatene), og det vil negere den yellow’ condition, det spiller ingen rolle hva vi setter inn før or  operatoren.

er kommentarsyntaks for SQL-server. Det avbryter det siste tilbudet. Så det siste tilbudet blir aldri henrettet fordi det kommenteres.

Derfor skal http://fruitsite.com/fruit?fruitColor=yellow’ or 1=1–  returnere alt på FruitTable.

Konklusjon 

Dette var et svært enkelt eksempel som kan lykkes og virkningen er katastrofal. Men det finnes mer sofistikerte angrep som krever mye semantikk i utførelsen og mer komplekse spørresyntakser.

I mitt neste innlegg vil jeg utforske hvordan vi kan teste det, både ved manuell testing og ved bruk av verktøy, og vil også beskrive noen av verktøyene som kan brukes til å fortelle deg om webapplikasjonen din har en risikoen for SQL-injeksjon eller ikke.

Guide: Slik utfører du sikkerhetstesting gjennom utviklingsløpet

Vil du lære mer om sikkerhet og sikkerhetstesting? I denne guiden gjennomgår sikkerhetsekspert Even Lysen hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.

Last ned guiden

2