SQL-injeksjon

SQLi-feilen, forkortelse for SQL Injection eller SQL-injeksjon på fransk, er en gruppe metoder for utnyttelse av sårbarheten til et program som interagerer med en database . Den brukes til å injisere en spørring som ikke er gitt av systemet, og som kan kompromittere sikkerheten i den aktuelle SQL-spørringen .

Typer SQL-injeksjoner

Det er flere typer SQL-injeksjon:

den blindbaserte metoden (assosiert med sin kusine den tidsbaserte ), som gjør det mulig å kapre den nåværende SQL-spørringen på systemet og å injisere brikker som vil gi karakter etter karakter det angriperen søker å hente ut fra databasedataene . Den blindbaserte metoden , så vel som den tidsbaserte , er basert på svaret fra serveren: hvis den opprinnelige forespørselen faktisk returnerer det samme resultatet som originalen (og derfor indikerer at tegnet er gyldig) eller ikke returnerer det samme resultatet (og indikerer derfor at den testede karakteren ikke er den riktige). Den eneste forskjellen med tidsbasert er at den er basert på responstiden til serveren i stedet for selve responsen;
den feilbaserte metoden , som gjør det mulig å viderekoble gjeldende SQL-spørring på systemet og å injisere brikker som vil returnere felt for felt det man søker å hente ut fra databasen . Denne metoden utnytter en svakhet i databasesystemene som lar viderekoble en feilmelding generert av databasesystemet og tidligere med vilje forårsaket av SQL-injeksjonen for å gjøre det tilbake til en presis verdi hentet i databasen;
den fagbaserte metoden , som gjør det mulig å kapre den nåværende SQL-spørringen på systemet og å injisere brikker som vil returnere et sett med data direkte hentet fra databasen . Denne metoden utnytter visse metoder for å omdirigere returen til den opprinnelige SQL-spørringen fullstendig for å få den til å returnere et stort volum data i en enkelt spørring direkte hentet fra databasen . I de mest voldelige eksemplene er det mulig å gjenopprette hele databasetabeller i en eller to spørringer, selv om denne metoden generelt returnerer mellom 10 og 100 databaserader per kapret SQL-spørring ;
den farligste av alle Stacked queries- metoden . Ved å dra nytte av en konfigurasjonsfeil på databaseserveren , lar denne metoden deg utføre alle SQL-spørsmål på det målrettede systemet, som ikke er begrenset til bare å gjenopprette data som de tre forrige. Faktisk, når denne typen spørringer ikke er deaktivert, er det tilstrekkelig å injisere et nytt SQL-spørsmål , og det vil bli utført uten problemer, enten det skal se etter data eller endre dem direkte i databasen .

Eksempel

Tenk på et dynamisk nettsted (programmert i PHP i dette eksemplet) som har et system som lar brukere med gyldig brukernavn og passord logge på. Dette nettstedet bruker følgende SQL-spørsmål for å identifisere en bruker:

SELECT uid FROM Users WHERE name = '(nom)' AND password = '(mot de passe hashé)';

Brukeren Dupont ønsker å koble til passordet "ting" hashed i MD5 . Følgende spørring kjøres:

SELECT uid FROM Users WHERE name = 'Dupont' AND password = '45723a2af3788c4ff17f8d1114760e62';

Angrip forespørselen

Tenk deg at PHP-skriptet som utfører denne forespørselen ikke sjekker innkommende data for å sikre sikkerheten. En hacker kunne da gi følgende informasjon:

Bruker: Dupont';--
Passord: noe

Søket blir:

SELECT uid FROM Users WHERE name = 'Dupont';--' AND password = '4e383a1918b432a9bb7702f086c56596e';

Tegn --markerer starten på en kommentar i SQL. Spørsmålet tilsvarer derfor:

SELECT uid FROM Users WHERE name = 'Dupont';

Angriperen kan da koble til under brukeren Dupont med hvilket som helst passord. Dette er en vellykket SQL-injeksjon fordi angriperen klarte å injisere tegnene han ønsket å endre oppførselen til spørringen.

Anta nå at angriperen ikke vil jukse SQL- skriptet på brukernavnet, men på passordet. Han kan deretter injisere følgende kode:

Bruker: Dupont
Passord : ' or 1 --

Apostrofen indikerer slutten av brukerens typesone, koden " or 1 " spør skriptet om 1 er sant, men det er alltid tilfelle, og - indikerer begynnelsen på en kommentar.

Spørringen blir da:

SELECT uid FROM Users WHERE name = 'Dupont' AND password = '' or 1 --';

Dermed er skriptet programmert for å sjekke om hva brukeren skriver er sant, det vil se at 1 er sant, og angriperen vil være logget inn under Dupont- økten .

Løsninger

Unnslipper spesialtegn

Den første løsningen består i å unnslippe spesialtegnene i tegnstrengene som er angitt av brukeren.

I PHP kan du bruke funksjonen mysqli_real_escape_string, som vil transformere strengen ' --til \' --. Søket ble da:

SELECT uid FROM Users WHERE name = 'Dupont\' -- ' AND password = '4e383a1918b432a9bb7702f086c56596e';

Apostrofen på slutten av strengen har blitt de-spesialisert riktig ved å gå foran den med et " \ " tegn .

Flukten kan også gjøres (avhengig av DBMS som brukes) ved å doble apostrofene.

Kommentarmerket vil da være en del av strengen, og til slutt svarer SQL-serveren at det ikke er noen oppføring i databasen som tilsvarer en bruker Dupont' -- med dette passordet.

Funksjonen er addslashesikke tilstrekkelig for å forhindre injeksjoner via numeriske variabler, som ikke er omgitt av apostrofer eller sitater i SQL-spørringer. Eksempel med spørringen:

SELECT ... FROM ... WHERE numero_badge = $numero AND code_4_chiffre = $code;

som lykkes når variabelen $numeroinneholder 0 or 1 --. En forholdsregel er å bruke funksjonen ctype_digittil å sjekke de numeriske variablene i spørringene. Vi kan også tvinge transformasjonen av variabelen til et tall ved å gå foran den med en typecast , som (int)om vi forventer et heltall (strengen 0 or 1 --vil da bli transformert til heltallet 0og SQL-injeksjonen vil mislykkes).

Selve funksjonen addslasheshar noen feil i noen daterte PHP-versjoner. Dessuten rømmer det bare tegnene "\", "NULL", "'" og "" ". Det ville være mer hensiktsmessig å bruke funksjonen mysqli_real_escape_stringsom nøyaktig unnslipper spesialtegnene til en SQL-kommando (NULL, \ x1a, \ n , \ r, \, ', "og \ x00).

Ved hjelp av et forberedt spørsmål

Den andre løsningen består i å bruke forberedte spørsmål: i dette tilfellet blir spørringen samlet før parametrene settes inn og kjøres, noe som forhindrer at noen kode som er satt inn i parameterne tolkes.

Mange rammer er utstyrt med en ORM som blant annet er ansvarlig for å forberede forespørslene.

Hvordan unngå disse angrepene

Disse angrepene kan unngås på flere måter:

Bruk lagrede prosedyrer , i stedet for dynamisk SQL . Dataene som er angitt av brukeren blir deretter overført som parametere, som, hvis de blir brukt riktig av prosedyren (for eksempel injisert i en parameterisert forespørsel), unngår injeksjonen;
Sjekk alle dataene som kommer fra brukeren nøyaktig og uttømmende. Man kan for eksempel bruke et vanlig uttrykk for å validere at et stykke data som er skrevet inn av brukeren, faktisk har ønsket form, eller dra nytte av språkspesifikke transformasjonsfunksjoner;
Bruk SQL-brukerkontoer med begrenset tilgang (skrivebeskyttet) når det er mulig;
Bruk parametrerte SQL-spørringer ( blanke spørsmål sendt til SQL-serveren, serveren som vi deretter sender parametrene til som vil plugge hullene), så det er DBMS som er ansvarlig for å unnslippe tegnene i henhold til typen innstillinger.

I PHP

De " magiske sitatene " ble brukt som standard i konfigurasjonen av PHP . De tillot at en fluktfigur automatisk ble plassert foran farlige apostrofer og sitater.

Noen sikkerhetsproblemer og forsvinningen av magic_quotes_gpci PHP5.4 oppfordrer til å erstatte dette alternativet med ovennevnte løsninger: funksjonen mysqli_real_escape_string, klassen PHP Data Objects , etc.

Eksempler

I Februar 2002, Avslører Jeremiah Jacks en sikkerhetsfeil på Guess.com-nettstedet som kan utnyttes av et SQL-injeksjonsangrep, og som gjør det mulig å få kontaktinformasjonen til mer enn 200 000 mennesker inkludert kredittkortnummer med utløpsdatoen.
De 1 st november 2005, en ung hacker bruker SQL-injeksjon for å bryte seg inn på det taiwanske informasjonsstedet viet til datasikkerhet og beslaglegger data fra kundebasen.
De 29. mars 2006, angriper en hacker med en SQL-injeksjon det offisielle indiske turistnettstedet som tilhører regjeringen.
I Januar 2008blir titusenvis av PCer infisert av en automatisk SQL-injeksjon som utnytter et sikkerhetsproblem i Microsoft SQL Server.
De 13. april 2008 10597 amerikanske personnummer ble stjålet.
De 17. august 2009, identifiserer det amerikanske justisdepartementet amerikaneren Albert Gonzalez og to russere som gjerningsmennene for tyveri av 130 millioner kredittkortnumre takket være et SQL-injeksjonsangrep. De største ofrene er kortbetalingsprosessoren Heartland Payment Systems , supermarkedkjedene 7-eleven og Hannaford Brothers .
De 24. juli 2010, klarer samtidig SQL-injeksjonsangrep fra Japan og Kina å trenge gjennom selskapet NeoBeat, som driver supermarkeder på Internett og stjeler 12.191 bankkortdata.
De 8. november 2010, en rumensk hacker kalt TinKode bruker et SQL-injeksjonsangrep for å lamme Royal Navy-nettstedet i England.
De 11. april 2011, er hele Barracuda-nettverket offer for et SQL-injeksjonsangrep. Ansatte-ID og e-postadresser er kapret.
De 1 st juni 2011blir gruppen som heter LulzSec beskyldt for et SQL-injeksjonsangrep mot Sony-nettstedet. Minst 1 million kunder har stjålet kuponger, aktiveringsnøkler og passord.
I Juli 2012, Yahoo rapporterer datatyveri fra mer enn 450.000 kunder.
I August 2013, Yahoo rapporterer datatyveri fra over 1 milliard kontoer.

Merknader og referanser

(in) " Web Reporting Guesswork Hole Plagues " , SecurityFocus ,6. mars 2002.
(in) " Whid 2005-46: Teen bruker SQL-injeksjon til å bryte til et magasin for sikkerhetsnettsteder " , Web Application Security Consortium ,1 st november 2005(tilgjengelig på en st desember 2009 ) .
(i) " Whid 2006-27: SQL Injection i incredibleindia.org " , Web Application Security Consortium ,29. mars 2006(åpnet 12. mars 2010 ) .
(i) Alex Papadimoulis, " Oklahoma lekker titusener av personnummer, andre sensitive data " , The Daily WTF ,15. april 2008(åpnet 16. mai 2008 ) .
(in) ' US man' stjal 130m kortnummer ' ' , BBC ,17. august 2009(åpnet 17. august 2009 ) .
(in) Royal Navy angrepet dette nettstedet av rumenske hackere , BBC News , 8-11-10 , Tilgang til november 2010.
(in) Sam Kiley, " Super Virus A Target For Cyber Terrorists " ,25. november 2010(åpnet 25. november 2010 ) .
(in) " Hacker bryter inn i Barracuda Networks-databasen " .
(in) " LulzSec hacks Sony Pictures, avslører 1m ubeskyttede passord " , electronista.com ,2. juni 2011.
(in) Ridge Shan, " LulzSec Hacker Arrested, Sony Group Leaks Database " , The Epoch Times ,6. juni 2011.
(en) Chenda Ngak. "Yahoo skal ha blitt hacket: Er kontoen din trygg?" , CBS News . 12. juli 2012. Tilgang til 16. juli 2012.
(i) Jamie Yap , " 450 000 brukerpassord lekket i Yahoo-brudd | ZDNet ” , ZDNet ,12. juli 2012( les online , konsultert 18. februar 2017 )
Sébastien Gavois , " Yahoo kunngjør tyveri av data fra mer enn en milliard kontoer ", Next INpact ,15. desember 2016( les online , konsultert 4. juli 2017 )
Florian Reynaud , “ The Piracy of Yahoo! er det største datatyveriet i historien ”, Le Monde.fr ,15. desember 2016( ISSN 1950-6244 , lest online , åpnet 4. juli 2017 )

Se også

Relaterte artikler

Sårbarhet (IT)
Skripting på tvers av nettsteder
Metasploit , et penetreringsverktøy med åpen kildekode, inkludert SQL-injeksjonstester

Eksterne linker

Grunnleggende om SQL-injeksjoner : Hvordan finne dem, bruke dem, korrigere dem