Hvordan Hackere overtager websteder med SQL Injection og DDoS
Selvom du kun har løst fulgt begivenhederne fra hackergrupperne Anonymous og LulzSec, har du sikkert hørt, om websteder og tjenester bliver hacket, som de berygtede Sony hacks. Har du nogensinde spekuleret på, hvordan de gør det?
Der er en række værktøjer og teknikker, som disse grupper bruger, og mens vi ikke forsøger at give dig en manual til at gøre det selv, er det nyttigt at forstå, hvad der sker. To af de angreb du konstant hører om dem bruger er "(Distributed) Denial of Service" (DDoS) og "SQL Injections" (SQLI). Sådan fungerer de.
Billede af xKCD
Denial of Service Attack
Hvad er det?
En "benægtelse af tjeneste" (undertiden kaldet "distribueret benægtelse af tjeneste" eller DDoS) angribes, når et system, i dette tilfælde en webserver, modtager så mange anmodninger på et tidspunkt, at serverressourcerne er overbelastede, låser systemet simpelthen og lukker ned. Målet og resultatet af et vellykket DDoS-angreb er, at webstederne på målserveren ikke er tilgængelige for legitime trafikanmodninger.
Hvordan virker det?
Logistik af et DDoS-angreb kan bedst forklares med et eksempel.
Forestil dig, at en million mennesker (angriberne) mødes med målet om at hæmme virksomhed Xs forretning ved at tage deres callcenter ned. Angrebene koordinerer således, at de tirsdag kl. 9 vil alle ringe til firma Xs telefonnummer. Mest sandsynligt vil Company Xs telefonsystem ikke kunne klare en million opkald på en gang, så alle indkommende linjer vil blive bundet af angriberne. Resultatet er, at legitime kundeopkald (dvs. dem, der ikke er angriberne) ikke kommer igennem, fordi telefonsystemet er bundet op med at håndtere opkald fra angriberne. Så i virkeligheden taber firma X potentielt tab, fordi de berettigede anmodninger ikke er i stand til at komme igennem.
Et DDoS-angreb på en webserver fungerer præcis på samme måde. Fordi der er næsten ingen måde at vide, hvilken trafik der kommer fra legitime anmodninger mod angribere, indtil webserveren behandler anmodningen, er denne type angreb typisk meget effektiv.
Udfør angrebet
På grund af DDoS-angrebets brutale kraft må du have masser af computere, som alle koordineres til angreb på samme tid. Ved at revidere vores callcenter eksempel ville dette kræve, at alle angriberne begge ved at ringe kl. 9 og faktisk ringe på det tidspunkt. Selvom dette princip helt sikkert vil fungere, når det kommer til at angribe en webserver, bliver det betydeligt nemmere, når zombiecomputere, i stedet for egentlige bemandet computere, udnyttes.
Som du sikkert ved, er der masser af varianter af malware og trojanere, som en gang på dit system ligger dvale og lejlighedsvis "telefon hjem" for instruktioner. En af disse instruktioner kan for eksempel være at sende gentagne anmodninger til Company Xs webserver kl. 9.00. Så med en enkelt opdatering til hjemstedet for de respektive malware kan en enkelt angriber øjeblikkeligt koordinere hundredtusinder af kompromitterede computere til at udføre et massivt DDoS-angreb.
Skønheden ved at udnytte zombiecomputere er ikke kun i dens effektivitet, men også i sin anonymitet, da angriberen slet ikke skal bruge deres computer til at udføre angrebet.
SQL Injection Attack
Hvad er det?
Et SQLI-angreb (SQL injection) er en udnyttelse, der udnytter dårlige webudviklingsmetoder og typisk kombineret med defekt databasesikkerhed. Resultatet af et vellykket angreb kan variere fra at udgive en brugerkonto til et fuldstændigt kompromis af den respektive database eller server. I modsætning til et DDoS-angreb er et SQLI-angreb helt og nemt forhindret, hvis en webapplikation er korrekt programmeret.
Udfør angrebet
Når du logger ind på et websted og indtaster dit brugernavn og adgangskode, for at teste dine legitimationsoplysninger, kan webprogrammet udføre en forespørgsel som følgende:
VÆLG BrugerID FRA Brugere WHERE UserName = "myuser" OG Password = "mypass";
Bemærk: Strengeværdier i en SQL-forespørgsel skal vedlægges i enkelt citater, og derfor vises de omkring de indtastede værdier.
Så kombinationen af det indtastede brugernavn (myuser) og adgangskoden (mypass) skal matche en post i Bruger-tabellen for at en UserID skal returneres. Hvis der ikke er nogen kamp, returneres der ikke nogen UserID, så loginoplysningerne er ugyldige. Mens en bestemt implementering kan afvige, er mekanikerne ret standard.
Så lad os nu se på en forespørgsel om skabelonautentificering, som vi kan erstatte de værdier brugeren indtaster på webformularen:
SELECT UserID FROM Users WHERE Brugernavn = "[bruger]" og kodeord = "[pass]"
Ved første øjekast kan det virke som et retfærdigt og logisk trin for nemt at validere brugere, men hvis en simpel substitution af de indtastede værdier udføres på denne skabelon, er den modtagelig for et SQLI-angreb.
Antag for eksempel "myuser" - "er indtastet i brugernavn feltet og" wrongpass "er indtastet i adgangskoden. Ved hjælp af simpel substitution i vores skabelon forespørgsel, ville vi få det her:
SELECT UserID FROM Users WHERE Brugernavn = "myuser" - 'OG Password = "wrongpass"
En nøgle til denne erklæring er inklusion af de to bindestreger (-). Dette er begyndelsen kommentar token for SQL-sætninger, så alt efter de to bindestreger (inklusive) vil blive ignoreret. I det væsentlige udføres ovenstående forespørgsel af databasen som:
VÆLG BrugerID FRA Brugere WHERE UserName = "myuser"
Den skarpe undladelse her er manglen på adgangskontrollen. Ved at inkludere de to bindestreger som en del af brugerfeltet, slog vi helt igennem adgangskodekontroltilstanden og kunne logge ind som "myuser" uden at kende den respektive adgangskode. Denne handling med at manipulere forespørgslen for at producere utilsigtede resultater er et SQL-indsprøjtningsangreb.
Hvilken skade kan gøres?
Et SQL-indsprøjtningsangreb skyldes uagtsom og uansvarlig applikationskodning og er fuldstændig forhindret (som vi dækker om et øjeblik), men omfanget af den skade, der kan gøres, afhænger af opsætningen af databasen. For at en webapplikation skal kunne kommunikere med backend-databasen, skal applikationen levere et login til databasen (Bemærk, det er anderledes end en bruger login til selve webstedet). Afhængigt af hvilke tilladelser webapplikationen kræver, kan denne respektive databasekonto kræve alt fra læs / skrive-tilladelse i eksisterende tabeller til fuld databaseadgang. Hvis dette ikke er klart nu, bør nogle få eksempler bidrage til at give klarhed.
Baseret på ovenstående eksempel kan du se det ved at indtaste, for eksempel, "youruser" - "," admin "-" eller et andet brugernavn, kan vi straks logge ind på webstedet som bruger uden at kende adgangskoden. Når vi er i systemet, ved vi ikke, at vi faktisk ikke er brugeren, så vi har fuld adgang til den respektive konto. Databasetilladelser giver ikke et sikkerhedsnet for dette, fordi et websted normalt skal have mindst læs / skriveadgang til sin respektive database.
Lad os nu antage, at hjemmesiden har fuld kontrol over sin respektive database, som giver mulighed for at slette poster, tilføje / fjerne tabeller, tilføje nye sikkerhedskonti mv. Det er vigtigt at bemærke, at nogle webapplikationer kunne have brug for denne form for tilladelse, så det Det er ikke automatisk en dårlig ting, der giver fuld kontrol.
For at illustrere den skade, der kan gøres i denne situation, vil vi bruge eksemplet som angivet i tegneserien ovenfor ved at indtaste følgende i brugernavn feltet: "Robert"; DROP TABLE Users; - ". Efter simpel substitution bliver autentiseringsspørgsmålet:
VELG BrugerID FRA Brugere WHERE UserName = "Robert"; DROP TABLE Brugere; - 'OG Password = "wrongpass"
Bemærk: Semikolonen er i en SQL-forespørgsel bruges til at angive slutningen af en bestemt erklæring og begyndelsen af en ny erklæring.
Som udføres af databasen som:
SELECT UserID FROM Users WHERE Brugernavn = "Robert"DROP TABLE brugere
Så lige så har vi brugt et SQLI-angreb for at slette hele bruger-tabellen.
Selvfølgelig kan meget værre ske, da angriberen, afhængigt af tilladte SQL-tilladelser, kan ændre værdier, dumpe tabeller (eller hele databasen selv) til en tekstfil, oprette nye login-konti eller endda kapre hele databaseplaceringen.
Forebyggelse af et SQL-indsprøjtningsangreb
Som vi nævnte flere gange tidligere, er et SQL-indsprøjtningsangreb let forhindret. Et af de kardinale regler for webudvikling er, at du aldrig stoler på brugerens input, som vi gjorde, da vi udførte simpel substitution i vores skabelonforespørgsel ovenfor.
Et SQLI-angreb er nemt imødegået af det, der kaldes rensning (eller undslippe) dine input. Sanitize-processen er faktisk ret triviel, da alt det i det væsentlige gør, er at håndtere alle inline single quote (') tegn på passende vis, således at de ikke kan bruges til for tidligt at afslutte en streng inde i en SQL-sætning.
For eksempel, hvis du ønskede at søge "O'neil" i en database, kunne du ikke bruge simpel substitution, fordi det enkelte citat efter O'en ville få snoren til at slutte tidligt. I stedet skal du sanitere det ved at bruge den respektive databasens flugtegn. Lad os antage, at escape-karakteren for et inline-enhedsnotat er præfacing hvert citat med et \ symbol. Så "O'neal" ville blive sanitized som "O \ 'neil".
Denne enkle handling af sanitet forhindrer stort set et SQLI-angreb. For at illustrere, lad os se vores tidligere eksempler og se de resulterende forespørgsler, når brugerens input er sanitiseret.
myuser'-- / wrongpass:
VÆLG BrugerID FRA Brugere WHERE UserName = "myuser \" - 'OG Password = "wrongpass"
Fordi det enkelte citat efter myuser er undslapet (hvilket betyder, at det betragtes som en del af målværdien), vil databasen bogstaveligt søge efter Brugernavn af "Myuser '-". Da stregerne er inkluderet i strengværdien og ikke selve SQL-sætningen, vil de blive betragtet som en del af målværdien i stedet for at blive fortolket som en SQL-kommentar.
Robert '; DROP TABLE Users;-- / wrongpass:
VÆLG UserID FROM Users WHERE UserName = "Robert \"; DROP TABLE Brugere; - 'OG Password = "wrongpass"
Ved simpelthen at undslippe det enkelte citat efter Robert er både semikolon og bindestreger indeholdt i brugernavnetes søgestreng, så databasen lettere vil søge efter "Robert"; DROP TABLE Users; - " i stedet for at udføre tabellen slette.
I Sammenfatning
Mens webangreb udvikler sig og bliver mere sofistikeret eller fokuserer på et andet indgangssted, er det vigtigt at huske at beskytte mod prøvede og sande angreb, der har været inspiration for flere frit tilgængelige "hacker tools" designet til at udnytte dem.
Visse typer angreb, såsom DDoS, kan ikke nemt undgås, mens andre, som f.eks. SQLI, kan. Den skade, der kan gøres ved disse typer angreb, kan imidlertid variere alt fra en ulempe til katastrofale afhængig af de forholdsregler, der træffes.
