SQL avkortningsangrep

SQL -avkortningssårbarheten oppstår når en database avkortes brukerinngangen på grunn av en begrensning på lengden. Angripere kan samle informasjon om lengden på et kritisk felt (for eksempel et brukernavn) og utnytte denne informasjonen for å få uautorisert tilgang. Angripere kan logge inn som en annen bruker, for eksempel en administrator, med sitt eget registrerte passord.

SQL avkortningssårbarhet eksisterer vanligvis i MySQL -databaser. Denne sårbarheten ble først beskrevet i CVE-2008-4106, som var relatert til WordPress CMS.

Hvordan SQL -avkortningsangrep fungerer

Dette angrepet fungerer på grunn av avkortning av brukerinngang i databaser ved bruk av "valg" og "innsetting" -funksjoner.

• Når innspill er gitt i formfeltet, er "Select" -funksjonskontrollene for redundans som tilsvarer innganger i databasen.
• Etter å ha sjekket for redundans, sjekker 'innsetting' -funksjonen lengden på inngangen, og brukerinngangen vil avkortes hvis lengden overstiger.

Anta at en utvikler oppretter “brukere” -tabellen via følgende spørsmål:

Lag tabellbrukere (
user_id int ikke null auto_increment,
brukernavn varchar (20) ikke null,
passord varchar (40) ikke null,
Primærnøkkel (user_id)
);

Bruke dette skjemaet, hvis utvikleren oppretter en admin -konto med følgende:

user_name = 'admin'
Passord = “Secret_p4sssw0ord”

Det er klart at disse legitimasjonene ikke er offentlige. Det er bare en administratorkonto i databasen, og hvis en angriper prøver å registrere en annen konto hos 'admin' brukernavn, vil angriperen mislykkes på grunn av redundansskontrollene til databasen. Angriperen kan fremdeles omgå den redundanssjekken for å legge til en annen administratorkonto ved å utnytte SQL avkortningssårbarheten. Anta at angriperen registrerer en annen konto med følgende innspill:

User_name = 'adminxxxxxxxxxxxxxxxxxrandom'
(x er rommene)
Og
Passord = ”Randomuser”

Databasen vil ta 'brukernavn' (26 tegn) og sjekke om dette allerede eksisterer. Deretter vil brukernavninngangen bli avkortet, og 'admin' ('admin' med plass) vil bli lagt inn i databasen, noe som resulterer i to dupliserte administratorbrukere.

Angriperen kan da opprette en 'admin' bruker med sitt eget passord. Nå har databasen to admin 'User_Name' oppføringer, men med forskjellige passord. Angriperen kan logge inn med de nyopprettede legitimasjonene for å få et administratorpanel fordi både User_Names “Admin” og “Admin” er like for databasenivået. Nå vil vi se på et praktisk angrep.

Prøveangrep

I dette eksemplet vil vi ta et scenario fra nettstedet Overhewire.org. OverThewire -samfunnet gir Wargame CTF -er som vi kan øve på sikkerhetskonseptene våre. Scenariet med SQL-avkortning skjer i Natas spillnivå 26-> 27. Vi får tilgang til nivået ved å bruke følgende:

URL: http: // natas27.Natas.laboratorier.Overwire.org
Brukernavn: Natas27
Passord: 55TBJppzuUjgvp5b3bnbg6on9udpvzcj

Dette nivået er tilgjengelig på: https: // Overhewire.org/wargames/natas/natas27.html. Du vil bli vist en påloggingsside som er sårbar for et SQL -avkortningsangrep.

Når du inspiserer kildekoden, vil du se at lengden på brukernavnet er 64, som vist nedenfor.

En bruker som heter 'Natas28' eksisterer allerede. Målet vårt er å opprette en annen bruker som heter 'Natas28' ved hjelp av SQL_TRUCATION Attack. Så vi vil legge inn NATAS28, etterfulgt av 57 mellomrom og et tilfeldig alfabet (i vårt tilfelle, a), brukernavn og ethvert passord. Brevet 'A' er ikke synlig på skjermbildet på grunn av brukernavnet på 65 tegn. Etter opprettelsen av brukerkontoen, vil du kunne se 'en.'

Hvis databasen inneholder SQL_TRUCASION -sårbarhet, bør databasen nå ha to 'Natas28' brukernavn. Ett brukernavn vil inneholde passordet vårt. La oss prøve å legge inn legitimasjon på påloggingssiden.

Nå er vi logget inn som 'Natas28' bruker.

Skadebegrensning

For å dempe dette angrepet, må vi vurdere flere faktorer.

• Vi skal ikke tillate duplisering av kritiske identiteter som brukernavnet. Vi bør gjøre disse identitetene til primære nøkler.
• Den avkortede funksjonen bør implementeres for alle felt med frontendformer, samt backend -kode, slik at databaser mottar avkortede innganger.
• Streng modus skal aktiveres på databasenivå. Uten streng modus aktivert, gir databaser bare advarsler i backend, men likevel lagre de dupliserte dataene. Med streng modus gir databaser feil i tilfelle duplisering og unngå å lagre data.

La oss for eksempel se etter den strenge modusen ved hjelp av følgende spørsmål:

mysql> velg @@ sql_mode

Vi oppretter en database og tabellen 'brukere.'

MySQL> Opprett databasetest
Spørring OK, 1 rad berørt (0.02 sek)
mysql> bruk test
Databasen endret
MySQL> Opprett tabellbrukere (brukernavn varchar (10), passord varchar (10));
Spørring OK, 0 rader berørt (0.05 sek)

Deretter oppretter vi en administratorbruker med legitimasjon ved hjelp av Sett inn spørringen.

mysql> sett inn i brukerverdier ('admin', 'passord1');
Spørring OK, 1 rad berørt (0.01 sek)

Vi kan se "brukere" tabellinformasjon ved å bruke alternativet "Select * fra brukere".

Brukerens lengde er 10 tegn. Nå vil vi prøve SQL -avkortningsangrepet.

Når vi prøver å legge inn følgende:

Brukernavn = 'adminxxxxxa'
(x er rommene)
Og
Passord = 'pass2'

Vi vil få en feil, noe som betyr at streng modus er helt effektiv.

mysql> sett inn i brukere verdier ('admin a', 'pass2')
Feil 1406 (22001): Data for lenge for kolonnen 'Brukernavn' på rad 1

Uten streng modus aktivert, vil databasen sende ut advarsler, men vil fremdeles sette inn dataene i tabellen.

Konklusjon

Angripere kan få tilgang til høye privilegier-kontoer hvis SQL_TRUNCTION-sårbarheten eksisterer i søknaden din. Angriperen kan enkelt få informasjon om et brukernavn og databaselengden ved hjelp av de kritiske feltene, og deretter lage samme brukernavn, etterfulgt av mellomrom og tilfeldig alfabet etter minimumslengde, noe. Denne sårbarheten er kritisk, men den kan unngås hvis du tar noen sikkerhetsforholdsregler, for eksempel å aktivere streng modus for brukerinnganger og gjøre det sensitive feltet til den primære nøkkelen i databasen.