Phenquestions
SQL-avkortingssårbarhet eksisterer vanligvis i MySQL-databaser. Dette sikkerhetsproblemet ble først beskrevet i CVE-2008-4106, som var relatert til WordPress CMS.
Hvordan SQL-avkortingsangrep fungerer
Dette angrepet fungerer på grunn av avkorting av brukerinngang i databaser ved bruk av funksjonene 'utvalg' og 'innsetting'.
- Når input er gitt i skjemafeltet, kontrollerer 'select' -funksjonen for redundans som tilsvarer innganger i databasen.
- Etter å ha sjekket for redundans, kontrollerer 'innsettings'-funksjonen lengden på inngangen, og brukerinngangen vil avkuttes hvis lengden overstiger.
Anta at en utvikler oppretter "brukere" -tabellen via følgende spørsmål:
opprette tabellbrukere (user_id INT IKKE NULL AUTO_INCREMENT,
brukernavn VARCHAR (20) IKKE NULL,
passord VARCHAR (40) IKKE NULL,
HOVEDNØkkel (user_id)
);
Ved å bruke dette skjemaet, hvis utvikleren oppretter en administratorkonto med følgende:
user_name = 'admin'passord = “secret_p4ssw0ord”
Åpenbart er disse legitimasjonene ikke offentlige. Det er bare en administratorkonto i databasen, og hvis en angriper prøver å registrere en annen konto med 'admin' brukernavnet, vil angriperen mislykkes på grunn av redundanssjekkene i databasen. Angriperen kan fortsatt omgå den overflødighetskontrollen for å legge til en annen administratorkonto ved å utnytte sårbarheten for SQL-avkorting. Anta at angriperen registrerer en annen konto med følgende inndata:
User_name = 'adminxxxxxxxxxxxxxxxxrandom'(x er mellomrommene)
&
Passord = ”Tilfeldig bruker”
Databasen tar brukernavn (26 tegn) og sjekker om dette allerede eksisterer. Da vil brukernavn-inngangen bli avkortet, og 'admin' ('admin' med mellomrom) vil bli lagt inn i databasen, noe som resulterer i to dupliserte adminbrukere.
Angriperen kan da opprette en 'admin' bruker med sitt eget passord. Nå har databasen to admin 'brukernavn' oppføringer, men med forskjellige passord. Angriperen kan logge på med de nyopprettede legitimasjonene for å få et adminpanel fordi både brukernavn “admin” og “admin” er like for databasenivå. Nå skal vi se på et eksempel på et praktisk angrep.
Eksempel på angrep
I dette eksemplet tar vi et scenario fra nettstedet.org. Overthewire-fellesskapet tilbyr krigsspill-CTF-er som vi kan øve på sikkerhetskonseptene våre. Scenarioet for SQL-avkorting forekommer i natas-spill Nivå 26-> 27. Vi kan få tilgang til nivået ved å bruke følgende:
URL: http: // natas27.natas.laboratorier.overthewire.orgBrukernavn: natas27
Passord: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Dette nivået er tilgjengelig på: https: // overthewire.org / wargames / natas / natas27.html. Du får se en påloggingsside som er sårbar for et SQL-avkortingsangrep.
Ved inspeksjon av 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_truncation-angrepet. Så vi vil legge inn natas28, etterfulgt av 57 mellomrom og et tilfeldig alfabet (i vårt tilfelle a), brukernavn og hvilket som helst passord. Bokstaven 'a' er ikke synlig på skjermbildet på grunn av brukernavnet på 65 tegn. Etter at brukerkontoen er opprettet, vil du kunne se 'en.'
Hvis databasen inneholder sql_truncation-sårbarhet, skal databasen nå ha to 'natas28' brukernavn. Ett brukernavn vil inneholde passordet vårt. La oss prøve å legge inn legitimasjonen på påloggingssiden.
Nå er vi logget på som 'natas28' bruker.
Skadebegrensning
For å redusere dette angrepet, må vi vurdere flere faktorer.
- Vi bør ikke tillate duplisering av kritiske identiteter som brukernavnet. Vi bør gjøre disse identitetene til primære nøkler.
- Avkortingsfunksjonen skal implementeres for alle felt i frontend-skjemaer, samt backend-kode, slik at databaser mottar avkortede innganger.
- Streng modus bør være aktivert på databasenivå. Uten streng modus aktivert, gir databaser bare advarsler i bakenden, men lagrer likevel dupliserte data. I streng modus gir databaser feil i tilfelle duplisering og unngår lagring av data.
La oss for eksempel se etter streng modus ved hjelp av følgende spørsmål:
mysql> velg @@ sql_mode
Vi vil lage en database og tabellens brukere.'
mysql> OPPRETT DATABASE-testSpørring OK, 1 rad berørt (0.02 sek)
mysql> Bruk test
Databasen endret
mysql> OPPRETT TABELL brukere (brukernavn VARCHAR (10), passord VARCHAR (10));
Spørring OK, 0 rader berørt (0.05 sek)
Deretter oppretter vi en adminbruker med legitimasjon ved hjelp av INSERT-spørringen.
mysql> INSERT INTO VALUE ('admin', 'password1');Spørring OK, 1 rad berørt (0.01 sek)
Vi kan se informasjonen om brukernes tabell ved å bruke alternativet 'velg * fra brukerne'.
Brukernavnens lengde er 10 tegn. Nå skal vi prøve SQL-avkortingsangrepet.
Når vi prøver å legge inn følgende:
Brukernavn = 'adminxxxxxa'(x er mellomrommene)
&
Passord = 'pass2'
Vi får en feil, noe som betyr at streng modus er helt effektiv.
mysql> INSERT INTO brukerverdier ('admin a', 'pass2')FEIL 1406 (22001): Data for lange for kolonnen 'brukernavn' på rad 1
Uten streng modus aktivert, vil databasen sende advarsler, men vil fortsatt sette inn dataene i tabellen.
Konklusjon
Angripere kan få tilgang til høy-privilegerte kontoer hvis sql_trunction-sårbarheten eksisterer i applikasjonen din. Angriperen kan enkelt få informasjon om et brukernavn og dets databaselengde ved hjelp av de kritiske feltene, og deretter opprette det samme brukernavnet, etterfulgt av mellomrom og tilfeldig alfabet etter minimumslengden, noe som resulterer i opprettelsen av flere høy-privilegier-kontoer. Dette sikkerhetsproblemet er kritisk, men det kan unngås hvis du tar noen sikkerhetsforholdsregler, for eksempel å aktivere streng modus for brukerinnganger og gjøre det følsomme feltet til Primærnøkkel i databasen.
