SQL-injeksjon

Klassifisering av SQL-injeksjonsangrepsvektorer i 2010

I datasikkerhet er SQL-injeksjon en kodeinjeksjonsteknikk som brukes til å angripe applikasjoner som administrerer data gjennom relasjonsdatabaser ved å bruke SQL -språket . Unnlatelse av å kontrollere brukerinndata lar deg kunstig sette inn strenger med SQL -kode som vil bli utført av serverapplikasjonen : takket være denne mekanismen er det mulig å utføre SQL-kommandoer, selv svært komplekse, ved å endre dataene (f.eks. opprettelse av nye brukere) til fullstendig nedlasting av innholdet i databasen.

Historie

De første offentlige diskusjonene knyttet til SQL-injeksjon dukket opp rundt 1998. For eksempel en artikkel fra 1998 i Phrack Magazine .

Beskrivelse

Den utnytter sikkerhetssårbarhetene til applikasjonskoden som kobles til SQL-datakilden, for eksempel ved å utnytte mangelen på brukerinndatafiltrering (f.eks. "escape-tegn" i SQL-strenger) eller mangelen på sterk inntasting av variablene som brukes. Det er best kjent som et nettapplikasjonsangrep , men det brukes også til å angripe alle andre typer applikasjoner som bruker SQL-databaser på en usikker måte.

Den lar angripere forfalske identifisere , endre eksisterende data, forårsake avvisningsproblemer som å kansellere transaksjoner eller endre regnskap, skaffe alle data på systemet, slette eller gjøre data utilgjengelige og opprette eller kompromittere brukere (f.eks. administratorer) av databaseserveren.

I en studie fra 2012 ble det observert at webapplikasjoner i gjennomsnitt mottar 4 angrep per måned, og forhandlere mottar dobbelt så mange angrep enn bransjer.

Typer SQL-injeksjon

SQL-injeksjon (SQLI) anses av Open Web Application Security Project for å være en av de 10 største sårbarhetene for nettapplikasjoner i 2007 og 2010. I 2013 og 2017 ble SQLI ansett som det første angrepet på OWASP topp 10. Det er fire hovedunderklasser av SQL-injeksjon:

• Klassisk SQLI
• Blind eller inferens SQL-injeksjon
• Databasestyringssystem- spesifikk SQLI
• Sammensatt SQLI

• SQL-injeksjon + utilstrekkelig autentisering
• SQL-injeksjon + DDoS - angrep
• SQL-injeksjon + DNS-kapring
• SQL-injeksjon + XSS

Stormormen er et eksempel på bruk av Compounded SQLI .

Denne klassifiseringen av tilstanden til SQLI representerer utviklingen frem til 2010.

Tekniske implementeringer

Escape-tegn ikke filtrert riktig

Denne typen SQL-injeksjon oppstår når brukerinndata ikke filtreres ut av escape-tegn og deretter sendes i en setning. Dette kan føre til manipulering av utsagnene i databasen av sluttbrukerne av applikasjonen.

Følgende kodelinje illustrerer denne typen sårbarhet:

statement = "SELECT * FROM users WHERE name = '"+ userName + "';"

Denne SQL-koden henter alle poster som har et bestemt brukernavn fra brukertabellen. Men hvis en angriper skriver "brukernavn"-variabelen på en bestemt måte, kan SQL-setningen gjøre mer enn hva forfatteren av koden hadde til hensikt. Sett for eksempel «brukernavn»-variabelen som:

'ELLER' 1 '=' 1

Eller ved å bruke kommentarer for å stoppe resten av spørringen som kjøres (det er tre typer SQL-kommentarer ). Alle tre linjene har et mellomrom på slutten:

'ELLER' 1 '=' 1 '-
'ELLER' 1 '=' 1 '({
'ELLER' 1 '=' 1 '/ *

Slik ser gjengivelsen av SQL-setningen ut etter å ha satt inn en av kodelinjene med kommentar og uten:

SELECT  *  FROM  brukere  WHERE  name  =  ''  ELLER  '1' = '1' ;

SELECT  *  FROM  brukere  WHERE  name  =  ''  ELLER  '1' = '1'  - ';

Hvis denne koden ble brukt i en autentiseringsprosedyre, kan dette eksemplet brukes til å tvinge frem valget av alle datafelt (*) for "alle" brukere i stedet for et enkelt brukernavn som tiltenkt med koden, dette skjer fordi evalueringen av ' 1' = '1' er alltid sant ( kortslutningsevaluering ).

I eksemplet nedenfor vil verdien av "brukernavn" føre til sletting av "bruker"-tabellen og valg av alle dataene i "brukerinfo"-tabellen (i utgangspunktet avsløre informasjonen til alle brukere), ved å bruke en API som tillater uttalelsesmultipler :

til';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Når du skriver inn inndataene som er spesifisert ovenfor, blir SQL-setningen slik:

SELECT  *  FRA  brukere  WHERE  navn  =  'a' ; DROP  TABLE  brukere ;  SELECT  *  FROM  brukerinfo  WHERE  't'  =  't' ;

Mens mange av SQL-serverimplementeringene lar deg utføre flere setninger med et enkelt kall, tillater ikke noen av disse APIene som i PHP-funksjonen mysql_query()det av sikkerhetsgrunner. Dette forhindrer angripere i å injisere helt separate søk i setningen, men det hindrer dem ikke i å endre dem.

Feil håndtering av type

Denne typen SQL -injeksjon oppstår når et brukeroppgitt felt ikke er sterkt skrevet eller typebegrensninger ikke er merket. Dette kan for eksempel skje når et numerisk felt brukes i en SQL-setning, men programmereren foretar ingen kontroller for å bekrefte at inndataene som er lagt inn av brukeren faktisk er numeriske. For eksempel:

statement: = " " + en_variabel + ";"
SELECT * FROM userinfo WHERE id =

Fra denne uttalelsen er det tydelig at forfatteren ønsket at variabelen skulle være et tall som refererer til "id"-feltet. Men hvis det faktisk er en streng , kan sluttbrukeren manipulere setningen etter eget ønske, og dermed omgå behovet for escape-tegn. For eksempel å sette en variabel til

1; DROP TABLE-brukere

"Brukere"-tabellen slettes fra databasen, siden SQL-setningen blir:

VELG  *  FRA  brukerinfo  WHERE  id = 1 ;  DROP  TABLE  brukere ;

Blind SQL-injeksjon

Blind SQL Injection brukes når en nettapplikasjon er sårbar for SQLI, men resultatene av operasjonen er ikke synlige for angriperen. Siden med sårbarheten er kanskje ikke en som viser data, men den kan vises forskjellig avhengig av resultatet av den logiske typesetningen injisert i den opprinnelige SQL-setningen som kalles for den siden. Denne typen angrep kan ta mye tid fordi du må lage en ny setning for hver bit som hentes. Det finnes ulike verktøy som lar deg automatisere disse angrepene når sårbarhetene er identifisert og hva målinformasjonen er.

Betingede svar

En av typene blind SQL-injeksjon tvinger databasen til å evaluere en logisk setning på en vanlig applikasjonsskjerm. Et nettsted for bokomtaler bruker for eksempel en søkestreng for å bestemme hvilken bokanmeldelse som skal vises. Deretter vil URL http://books.example.com/showReview.php?ID=5 -en få serveren til å utføre spørringen

VELG  *  FRA  bokanmeldelser  WHERE  ID  =  'Verdi (ID)' ;

Som den vil fylle siden med anmeldelsesdataene med ID 5, lagret i bokanmeldelsestabellen. Spørringen kjører fullstendig på serveren; så brukeren vil ikke kjenne navnene på databasen, tabellen eller feltene, og han vil heller ikke kjenne spørringsstrengen. Brukeren vil bare se at URL-en ovenfor returnerer en bokomtale. En hacker kan laste inn følgende URL- er og , som kan generere utførelsen av disse spørringene henholdsvis: http://books.example.com/showReview.php?ID=5 OR 1=1http://books.example.com/showReview.php?ID=5 AND 1=2

VELG  *  FRA  bokanmeldelser  WHERE  ID  =  '5'  ELLER  '1' = '1' ; 
VELG  *  FRA  bokanmeldelser  WHERE  ID  =  '5'  OG  '1' = '2' ;

Hvis du bruker nettadressen med "1 = 1" lastes den opprinnelige anmeldelsen inn og med nettadressen "1 = 2" lastes en tom side eller feilside, og den returnerte siden viser ikke brukeren at det bare er en ugyldig nettadresse. er lagt inn, er det svært sannsynlig at nettstedet er sårbart for SQL-injeksjonsangrep fordi det betyr at begge spørringene kunne ha blitt utført av databaseserveren. Hackeren kan utføre følgende spørringsstreng for å finne ut versjonsnummeret til MySQL som er tilstede på serveren: når den er utført, vil den vise anmeldelsen av boken hvis serveren bruker MySQL 4 og ellers en tom side eller feilside. Hackeren kan fortsette å bruke kode innenfor spørringsstrengene for å få mer og mer informasjon om serveren inntil en ny angrepsvei blir oppdaget eller til målene hans er nådd. http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4

Andre ordens SQL-injeksjon

Andre ordens SQL-injeksjon skjer når verdiene som sendes inn av brukeren inneholder ondsinnede kommandoer som er lagret på serveren i stedet for å bli utført umiddelbart. I noen tilfeller kan applikasjonen lagre den ondsinnede inngangen som om den var en gyldig SQL-setning, og en annen del av applikasjonen som ikke sjekker for å beskytte seg mot SQL-injeksjoner, kan utføre den lagrede setningen. Denne typen angrep krever kunnskap om at verdiene som sendes brukes senere. Nettapplikasjonssikkerhetsskannere vil kanskje ikke lett legge merke til denne typen SQL-injeksjon og må kanskje instrueres manuelt om hvor de skal lete etter ledetråder om angrepet.

Forebygging

SQL-injeksjon er et velkjent angrep som enkelt kan unngås med enkle tiltak. Etter det som antas å ha vært et SQL-injeksjonsangrep på det britiske selskapet TalkTalk Group, meldte BBC at sikkerhetseksperter var forbløffet over at et så stort selskap var sårbart for denne typen angrep.

Utsagn parametrisert

Med mange av utviklingsplattformene er det mulig å bruke parameteriserte setninger som fungerer med parametere (kalt plassholdere eller bindevariabler) i stedet for å sette inn brukerinndata direkte i setningen. En plassholder kan bare lagre en verdi av den angitte typen og ikke en hvilken som helst SQL-setning. På denne måten blir SQL-injeksjon ganske enkelt behandlet som en ugyldig verdi for den parameteren.

I mange tilfeller er SQL-setningen i stedet fast, og hver parameter er derfor en skalar, og ikke en tabell. Brukerinndata blir deretter tilordnet (bundet) til en parameter.

Håndhevelse på kodenivå

Ved å bruke objektrelasjonelle kartleggingsbiblioteker unngår du å skrive SQL-kode. ORM-bibliotekene genererer automatisk parameteriserte SQL-setninger, med utgangspunkt i objektorientert kode.

Escape

En enkel, men feilutsatt måte å forhindre SQLI-angrep på er å unngå tegn som har spesiell betydning i SQL. SQL DBMS-manualene forklarer hvilke tegn som har spesielle betydninger, dette lar deg lage en liste over tegn som må erstattes fordi de er potensielt skadelige. For eksempel må hver apostrof ( ') i en parameter erstattes med to apostrof ('') for å få en gyldig SQL-streng med bokstaver. For eksempel, i PHP unngår vi vanligvis spesialtegn i parametere ved å bruke funksjonen mysqli_real_escape_string();før du sender SQL-spørringen:

$ mysqli  =  new  mysqli ( 'vertsnavn' ,  'db_brukernavn' ,  'db_passord' ,  'db_navn' ); 
$ query  =  sprintf ( "SELECT * FROM` Users` WHERE UserName = '% s' AND Password = '% s' " , 
                  $ mysqli -> real_escape_string ( $ brukernavn ), 
                  $ mysqli -> real_escape_string ( $ passord )); 
$ mysqli -> query ( $ query );

Denne funksjonen legger skråstrek foran følgende tegn : \x00,,,, \nog . Den brukes vanligvis til å sikre spørringer før sending til en MySQL- database . I PHP er det like mange andre funksjoner for ulike typer databaser som for PostgreSQL . Funksjonen brukes for å unngå spesialtegn, og brukes spesielt til å spørre databaser som ikke har noen escape-funksjoner i PHP, den returnerer en streng med omvendte skråstreker før tegnene som skal siteres. Disse tegnene er apostrof ('), doble anførselstegn ("), skråstrek og NULL-tegnet. Å alltid unnslippe SQL-strenger er en feilutsatt praksis fordi det er lett å glemme å unnslippe SQL-strenger. en bestemt streng. Opprette et gjennomsiktig lag for å sikre inngangen kan redusere feil eller eliminere dem helt. \r\'"\x1a
pg_escape_string()addslashes(string $str)

Mønsterkontroll

Du kan sjekke parametere med strenger av heltall, flyter eller booleaner, og sjekke om verdien deres har en gyldig struktur for typen data som er sjekket. Strenger som har en ganske rigid struktur (dato, UUID, kun alfanumerisk osv.) kan sjekkes for å se om de gjenspeiler strukturen til datatypen.

Databasetillatelser

Begrensning av tillatelsene i påloggingen som brukes av nettapplikasjonen for å få tilgang til databasen, ved kun å sette inn de nødvendige tillatelsene, kan bidra til å redusere effektiviteten til ethvert SQL-injeksjonsangrep, rettet mot applikasjonsfeil.

For eksempel, på Microsoft SQL Server kan du forby databasepåloggingen å gjøre et valg til noen av systemtabellene, på denne måten unngår man at JavaScript settes inn i alle kolonnene i databasen.

nekte valg på sys . sysobjects til webdatabaselogon ;     
nekte valg på sys . objekter til webdatabaselogon ;     
nekte valg på sys . tabeller til webdatabaselogon ;     
nekte valg på sys . visninger til webdatabaselogon ;     
nekte valg på sys . pakker til webdatabaselogon ;     

Hex-konvertering

Heksadesimal konvertering gjøres ved å konvertere ren tekst til dens heksadesimale representasjon før den brukes i en SQL-kommando. I PHP er funksjonene som brukes funksjon bin2hex() eller dechex . Funksjonen bin2hex()foretrekkes siden den konverterer et hvilket som helst tegn og ikke bare tall. Kun funksjonen vil bli brukt i denne delen bin2hex().

Eksempel på bruk av PHP-funksjon bin2hex():

echo  bin2hex ( "test" );

Utgangen av funksjonen ovenfor er:

74657374

Som et eksempel snakker vi bare om databasen MySQL . I MySQL brukes funksjon unhex() til å konvertere en heksadesimal streng tilbake til ren tekst.

Eksempel på funksjonen unhex()i MySQL:

SELECT  *  FROM  myTable  WHERE  id = unhex ( '32' );

Hvis vi konverterte strengen med unhex()til ren tekst ville den blitt:

SELECT  *  FROM  myTable  WHERE  id = 2 ;

Hex-konvertering eliminerer SQL-injeksjonsangrep fordi den heksadesimale strengen som sendes til funksjonen unhex()returneres som en tidligere brukt streng og ikke tolkes.

Programmeringseksempel

Følgende korte program introduserer et PHP-program og dets funksjon. Programmet viser et SQL-injeksjonsangrep på en enkel SQL-kommando. Deretter viser han hvordan han ved å konvertere alle innkommende data til heksadesimal, klarer å stoppe angrepet. PHP-funksjonen er et enkelt sett med kommandoer for databasen og for å hente utdata fra SQL-databasen. Som nevnt ovenfor er databasen som brukes MySQL.

Eksempelkode

Fil: test.php 
<? Php

    include_once  "dosql.php" ; 
# 
# Legg inn databaseinformasjonen din her. Jeg bruker data fra loggfilen min. 
# 
    $ vertsnavn  =  "minvert" ; 
    $ brukernavn  =  "min bruker" ; 
    $ passord  =  "mittPassord" ; 
    $ database  =  "min Database" ;

    $ mysqli  =  ny  mysqli ( $ vertsnavn ,  $ brukernavn ,  $ passord ,  $ database );

    if  ( $ mysqli -> connect_errno )  { 
        echo  "Kunnet ikke koble til MySQL: (" ,  $ mysqli -> connect_errno ,  ")" ,  $ mysqli -> connect_error ; 
        avslutte ; 
    } 
    echo  "SQL INJEKSJON - Vanlig \ n " ; 
    $ sql  =  "VELG * FRA logg WHERE log_id = '2' ELLER 1 = 1; # '" ; 
    $ res  =  dosql ( $ sql ); 
    foreach  ( $ res [ 0 ]  som  $ k  =>  $ v )  { 
        echo  "RES [ $ k ] = $ v \ n " ; 
    }

    echo  " \ n \ n SQL INJECTION = Heksadesimal \ n " ; 
    $ sql  =  "SELECT * FROM log WHERE log_id = unhex ('"  .  bin2hex ( "2' eller 1 = 1; # '" )  .  "')" ; 
    $ res  =  dosql ( $ sql ); 
    foreach  ( $ res [ 0 ]  som  $ k  =>  $ v )  { 
        echo  "RES [ $ k ] = $ v \ n " ; 
    }

    avslutte ; 
?>

Fil: dosql.php 
<? Php

############################################### ############################################### ## ############################### 
# dosql (). Gjør SQL-kommandoen. 
############################################### ############################################### ## ################################ 
function  dosql ( $ sql ) 
{ 
    global  $ mysqli ;

    $ cmd  =  "INSERT I loggen (dato, oppføring) VERDIER (NÅ (), unhex ('"  .  bin2hex ( $ sql )  .  "'))" ; 
    $ res  =  $ mysqli -> spørring ( $ cmd );

    $ res  =  $ mysqli -> spørring ( $ sql ); 
    if  ( ! $ res )  { 
        $ array  =  debug_backtrace (); 
        if  ( isset ( $ array [ 1 ]))  {  $ a  =  $ array [ 1 ] [ 'line' ];  } 
        else  if  ( isset ( $ array [ 0 ]))  {  $ a  =  $ array [ 0 ] [ 'line' ];  } 
        annet  {  $ a  =  "???" ;  }

        echo  "ERROR @" ,  $ a ,  ": (" ,  $ mysqli - > feilmelding ,  ") \ n " ,  $ mysqli -> feil ,  " \ n \ n " ; 
        echo  "SQL = $ sql \ n " ; 
        avslutte ; 
    }

    if  ( preg_match ( "/ INSERT / i" ,  $ sql ))  {  return  $ mysqli -> insert_id ;  } 
    if  ( preg_match ( "/ DELETE / i" ,  $ sql ))  {  return  null ;  } 
    if  ( ! er_objekt ( $res ))  {  return  null ;  }

    $ count  =  - 1 ; 
    $ array  =  array (); 
    $ res -> data_seek ( 0 ); 
    while  ( $ rad  =  $ res -> fetch_assoc ())  { 
        $ count ++ ; 
        foreach  ( $ rad  som  $ k  =>  $ v )  {  $ array [ $ count ] [ $ k ]  =  $ v ;  } 
    }

    return  $ array ; 
}

Programutgang

SQL INJEKSJON - Vanlig
RES [log_id] = 1
RES [dato] = 2015-03-25 10:40:18
RES [entry] = VIS hele kolonner FRA logg

SQL INJEKSJON = Heksadesimal
RES [log_id] = 2
RES [dato] = 2015-03-25 10:40:18
RES [oppføring] = VELG * FRA logg BESTILL ETTER tittel ASC

Den første delen av programutgangen viser SQL-kommandoen som sendes uten å foreta noen kontroller eller endringer. Den opprinnelige forespørselen skulle returnere den andre posten, men takket være SQL-injeksjon, returneres den første posten. Den andre delen av utdataene viser hva som skjer hvis alle inndataene konverteres til heksadesimale. Ved å bruke konvertering konverteres alle tegn i kommandoen, inkludert de som legges inn ved SQL-injeksjon, til heksadesimale og er ikke lenger en fare fordi de ikke tolkes som kommandoer, men som strenger. Siden alle tegn blir behandlet som en del av hele strengen, hvis MySQL forstår at den trenger et tall, konverterer den strengen til et tall. Reglene for konvertering av streng til tall er å konvertere strengen til den når et ikke-numerisk tegn eller slutten av strengen. Når en av disse to hendelsene inntreffer, stopper konverteringen på det tidspunktet. Deretter vises "2" og deretter apostrof ('), som forteller My SQL å fullføre konverteringen av strengen. Til slutt brukes den numeriske verdien to (2) for å bestemme hvilken post som skal returneres. Denne prosessen eller metoden for å evaluere innkommende data er grunnen til at SQL-injeksjonsangrep ikke kan oppstå hvis en hex-konvertering brukes.

Ytterligere hensyn

I tillegg krever bruk av BIN2HEX og UNHEX mindre utførelsestid enn de andre metodene som presenteres. Dette er hovedsakelig på grunn av den forenklede karakteren til begge funksjonene. Som vist i JavaScript-kodebiten, er konvertering til hex ganske grei og grei:

Eksempelkode

Fil :  toHex . js 
///////////////////////////////////////////// /////////////////////////////// 
toHex (). Konverter en streng til heksadesimal. 
///////////////////////////////////////////// ////////////////////////////// - 
funksjonen  til Hex ( s ) 
{ 
	var  l  =  "0123456789ABCDEF" ; 
	var  o  =  "" ;

	if  ( type  s  ! =  "streng" )  {  s  =  s . toString ();  } 
	for  ( var  i  =  0 ;  i  <  s . lengde ;  i ++ )  { 
		var  c  =  s . charCodeAt ( i ); 
		o  =  o  +  l [( c  >>  4 )]  +  l [( c  &  0xf )]; 
	}

	returnere  eller ; 
}

Som vist, i motsetning til mysqli_real_escape_string() som må escapes for hver forskjell, bin2hex()konverterer den ganske enkelt alle tegn til deres tilsvarende heksadesimal. Og funksjonen unhex()gjør den motsatte operasjonen. Siden ingen tester må gjøres for en bestemt karakter eller tegn, er konverteringssyklusen liten og effektiv. I motsetning til mysqli_real_escape_string(), hvis en ny metode oppdages i fremtiden, vil funksjonen bin2hex()automatisk deaktivere kombinasjonen av tegn, fordi den returnerer en heksadesimal streng. Et eksempel på dette er Control-D ASCII-tegnet. Control-D kan forårsake en "Slutt på overføring"-tilstand på noen språk. Hvis funksjonen brukes, bin2hex()blir Control-D ganske enkelt ren ASCII-tekst "04", som ikke kan forårsake noen problemer.

Eksempler

• I februar 2002 oppdaget Jeremiah Jacks at Guess.com var sårbar for et SQL -injeksjonsangrep, slik at alle som var i stand til å lage en spesiallaget URL kunne hente mer enn 200 000 navn, numre og datoer. nettstedets kundedatabase.
• 1. november 2005 brukte en mindreårig hacker et SQL-injeksjonsangrep for å bryte seg inn på nettstedet til et taiwansk cybersikkerhetsmagasin fra Tech Target Group og stjele kundeinformasjon.
• Den 13. januar 2006 gikk russiske nettkriminelle inn på Rhode-regjeringens nettsted og stjal kredittkortinformasjon fra enkeltpersoner som hadde gjort forretninger med statlige etater.
• Den 29. mars 2006 oppdaget en hacker en SQL-injeksjonssårbarhet på et offisielt nettsted for turisme i India.
• Den 29. juni 2009 forringet en nettkriminell Microsofts britiske nettsted ved å bruke et SQLI-angrep. Et britisk nettsted, The Register , rapporterte at en talsperson for Microsoft hadde bekreftet problemet.
• I januar 2008 ble titusenvis av PC-er infisert med et automatisert SQL-injeksjonsangrep som utnyttet sårbarheter i kode ved hjelp av Microsoft SQL Server
• I januar 2008 ble det malaysiske nettstedet Kaspersky Lab hacket av en tyrkisk hacker kjent som "m0sted" som hevdet å ha brukt SQL-injeksjon.
• I februar 2013 hacket en maldivisk hackergruppe nettstedet "UN-Maldivene" ved å bruke SQL Injection.
• 27. mai 2009 sa Anti-US Hackers Infiltrate Army Servers etterforskere at de trodde de hadde mottatt et angrep kalt SQL-injeksjon som utnyttet en Microsoft SQL Server-sikkerhetssårbarhet for å komme inn på webservere. "m0sted" er kjent for å ha utført lignende angrep på mange andre nettsteder tidligere.
• I mai 2008 brukte en serverfarm i Kina automatiserte søk sendt til Googles søkemotor for å identifisere nettsteder som bruker SQL-server, som var sårbar for et SQLI-verktøy.
• I 2008, i hvert fall fra april til august, begynte en rekke angrep for å utnytte SQLI-sårbarhetene til IIS-nettserveren og SQL Server. Angrepet krevde ikke å gjette et tabellnavn eller kolonne, og korrupte alle kolonner med tekst i alle tabeller i én forespørsel. En HTML-streng ble lagt til hver verdi med en referanse til en JavaScript - malware . Da verdien deretter ble vist til den besøkende på nettstedet, forsøkte skriptet ulike tilnærminger for å ta kontroll over den besøkendes system. Antall nettsider som utnyttes er estimert til å være rundt 500 000.
• Den 17. august 2009 siktet det amerikanske justisdepartementet en amerikansk statsborger, Albert Gonzalez , og to russere for tyveri av 130 millioner kredittkortnumre ved bruk av et SQLI-angrep. Det er rapportert som "det største tilfellet av identitetstyveri i amerikansk historie".
• I desember 2009 fikk en hacker tilgang til en RockYou- database som inneholdt de ukrypterte passordene og brukernavnene til omtrent 32 millioner brukere ved å bruke et SQLI-angrep.
• I juni 2010 innhentet en søramerikansk sikkerhetsforsker som går under aliaset "Ch Russo" sensitiv informasjon om brukere av et populært BitTorrent- nettsted , The Pirate Bay . Han fikk tilgang til kontrollpanelet som nettstedsadministrator, og utnyttet en sårbarhet i SQLI som gjorde det mulig for ham å skaffe brukerkontoinformasjon, inkludert IP-adresser, MD5- passord-hasher og registreringer av hvilke torrenter hver bruker hadde lastet opp.
• Fra 24. til 26. juli 2010 brukte hackere fra Japan og Kina SQL-injeksjon for å få tilgang til kundekredittkortdata fra Neo BEAT, et Osaka-basert selskap som driver nettstedet til et stort nettsupermarked. Angrepet skadet også syv forretningspartnere som supermarkedskjedene Izumiya Co, Maruetsu Inc og Ryukyu Jusco Co. Datatyveriet rammet 12 191 kunder. Per 14. august 2010 ble det rapportert om mer enn 300 tilfeller av kredittkortinformasjon brukt til å kjøpe varer og tjenester i Kina.
• Den 19. september 2010, under det svenske stortingsvalget 2010, forsøkte en velger en kodeinjeksjon for hånd ved å skrive SQL-kommandoer på stemmeseddelen.
• Den 8. november 2010 ble nettstedet til den britiske Royal Navy kompromittert av en rumensk hacker ved navn TinKode som brukte et SQL-injeksjonsangrep.
• 5. februar 2011 penetrerte HBGary , et cybersikkerhetsfirma, LulzSec ved å bruke SQL-injeksjon på deres CMS-drevne nettsted.
• Den 27. mars 2011 ble mysql.com, det offisielle MySQL -nettstedet , kompromittert av en hacker som brukte et blindt SQL-injeksjonsangrep.
• 11. april 2011 ble Barracuda Networks kompromittert på grunn av en SQLi-sårbarhet. Ansattes e-postadresser og brukernavn ble innhentet.
• I løpet av en 4-timers periode, 27. april 2011, skjedde et automatisert SQL-injeksjonsangrep på Broadband Reports- nettstedet som var i stand til å få 8 % av brukernavn/passord-parene, 8000 tilfeldige kontoer av 9000 aktive og 90 000 kontoer. gamle eller inaktiv.
• 1. juni 2011 ble " hacktivistene " i LulzSec -gruppen anklaget for å ha stjålet kuponger , nedlastingsnøkler og passord som ble lagret i tekstdatabasen på Sony -nettstedet , for å få tilgang til personlig informasjon til millioner av brukere.
• I juni 2011 ble PBS hacket, mest sannsynlig via SQLi; hele prosessen som brukes av hackerne for å utføre angrepet er beskrevet på denne Imperva- bloggen .
• I mai 2012 ble nettsiden til Wurm Online , et massivt flerspiller online spill , tatt ned via et SQL-injeksjonsangrep da siden ble oppdatert.
• I juni 2012 stjal en gruppe hackere 450 000 påloggingsinformasjon fra Yahoo! . Pålogginger ble lagret i ren tekst. Gruppen brøt gjennom Yahoos sikkerhet via en " fagforeningsbasert SQL-injeksjonsteknikk".
• 1. oktober 2012 ga en hackergruppe kalt "Team GhostShell" ut personlige poster over studenter, fakulteter, ansatte, nyutdannede ved 53 universiteter, inkludert Harvard , Princeton , Stanford , Cornell , Johns Hopkins og University of Zurich på pastebin. com . Hackerne sa at de ønsket å "øke bevisstheten om endringene i utdanning i dag", og klaget over endringen i utdanningslovene i Europa og økningen i undervisning i USA.
• 27. juni 2013 brøt hackergruppen " RedHack " gjennom Istanbuls administrasjonsside. De hevdet at de ville slette gjelden som folk skyldte til vann, gass, internett, elektrisitet og telefonselskaper. I tillegg publiserte de et administratorbrukernavn og passord slik at innbyggerne kunne logge inn og slette gjelden sin. De annonserte denne nyheten via Twitter.
• Den 4. november 2014 kompromitterte hacktivistgruppen "RaptorSwag" 71 kinesiske regjeringsdatabaser ved å bruke et SQL-injeksjonsangrep på nettstedet til det kinesiske handelskammeret. De lekkede dataene ble publisert sammen med Anonymous -samarbeidet .
• 2. februar 2014 lekket en hackergruppe kalt @deletesec 40 000 kontoer fra AVS TV-siden.
• 21. februar 2014 hadde det amerikanske styreforumet et angrep som resulterte i eksponering av 3 215 kontoer.
• 21. februar 2014 hacket en hackergruppe kalt @deletesec Spirol International etter at de truet med å få hackerne arrestert for å ha rapportert sikkerhetssårbarheten. Detaljene til 70 000 brukere ble avslørt under denne konflikten.
• I oktober 2015 ble et SQL-injeksjonsangrep antatt å ha blitt brukt på serverne til et britisk telekommunikasjonsselskap, Talk Talk , og stjal personopplysningene til millioner av forbrukere.

Referanser i massekultur

• Uautorisert pålogging til et nettsted via SQL-injeksjon gir en narrativ pekepinn for romanen The Vacant Seat av JK Rowling , utgitt i 2012.
• En xkcd -tegneserie handler om en karakter som heter "Robert '); DROP TABLE-studenter; -" som utfører en SQL-injeksjon. Som et resultat av denne tegneserien blir SQL-injeksjon noen ganger uformelt referert til som 'Bobby Tables'.
• I 2014 omdøpte en person i Polen lovlig virksomheten sin til Dariusz Jakubowski x '; DROP TABLE brukere; SELECT '1 med det formål å hindre operasjonene til roboter for innsamling av spammere .

Relaterte elementer

• Kodeinnsprøytning
• Skripting på tvers av nettsteder
• Metasploit-prosjektet
• OWASP Åpne Web Application Security Project
• Ukontrollert formatstreng
• w3af
• Sikkerhet for nettapplikasjoner
• Ekstern XML-enhet

Eksterne lenker

• SQL Injection Knowledge Base , av Websec.
• Blind Sql Injection - Regular Expressions Attack Blind Sql Injection med Regular Expressions Attack
• WASC Threat Classification - SQL Injection Entry , av Web Application Security Consortium.
• Hvorfor SQL-injeksjon ikke vil forsvinne , av Stuart Thomas.
• SQL Injection Attacks by Example , av Steve Friedl
• SQL Injection Prevention Cheat Sheet , av OWASP.
• SQL Injection Tutorial , av BTS.
• sqlmap: automatisk SQL-injeksjon og databaseovertakelsesverktøy
• SDL Raske sikkerhetsreferanser på SQL-injeksjon av Bala Neerumalla.
• Backdoor Web-server som bruker MySQL SQL Injection Arkivert 2. april 2013 på Internet Archive . Av Yuli Stremovsky
• Defacing nettsted med SQL-injeksjon av sploitswiki
• Angripende nettapp med SQL-injeksjon av Abhinav Sejpal