26Aug
Selvom du kun har løst fulgt begivenhederne i 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 "distributed denial of service" eller DDoS) angribes, når et system, i dette tilfælde en webserver, modtager så mange forespørgsler på et tidspunkt, at serverressourcerne er overbelastede, låser systemet simpelthenop 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 DDoS-angreb kan bedst forklares med et eksempel.
Forestil dig, at en million mennesker( angriberne) kommer sammen 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 være i stand til at håndtere en million opkald på én 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ørelse af angrebet
På grund af DDoS-angrebets brute kraft skal du have masser af computere, som alle koordineres til angreb på samme tid. Revision af vores callcenter eksempel, ville dette kræve, at alle angriberne begge ved at ringe klokken 9 og faktisk ringe på det tidspunkt. Mens dette princip helt sikkert vil fungere, når det kommer til at angribe en webserver, bliver det meget lettere, 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 sovende og lejlighedsvis "hjemme telefon" for instruktioner. En af disse instruktioner kan f.eks. 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 dens anonymitet, da angriberen slet ikke skal bruge deres computer til at udføre angrebet.
SQL Injection Attack
Hvad er det?
Et "SQL injection" -angreb( SQLI) -angreb 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ørelse af angrebet
Når du logger ind på et websted og indtaster dit brugernavn og adgangskode, kan webapplikationen udføre en forespørgsel som følgende:
SELECT UserID FROM Brugere WHERE UserName = 'myuser' og kodeord= 'mypass';
Bemærk: Strengeværdier i en SQL-forespørgsel skal vedlægges i enkelt citater, hvorfor de vises omkring de indtastede værdier.
Så kombinationen af det indtastede brugernavn( myuser) og password( mypass) skal matche en post i Bruger-tabellen for at en UserID skal returneres. Hvis der ikke er nogen match, returneres ingen 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 øjekastkan 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 at bruge simpel substitution i vores skabelon forespørgsel, ville vi få dette:
SELECT UserID FROM Brugere WHERE UserName = 'myuser' - 'OG Password =' wrongpass '
En nøgle til denne erklæring er inkluderingen af de to bindestreger( -).Dette er begyndelsen kommentar token for SQL-sætninger, så alt hvad der vises efter de to bindestreger( inklusive) vil blive ignoreret. I det væsentlige udføres ovenstående forespørgsel af databasen som:
SELECT UserID FRA Brugere WHERE UserName = 'myuser'
Den klare udeladelse 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.
Hvilke skader kan gøres?
Et SQL-indsprøjtningsangreb er forårsaget af 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 backenddatabasen, 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, at 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 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 er ikke automatisk en dårlig ting, at fuld kontrol gives.
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:
SELECT UserID FROM Users WHERE Brugernavn = 'Robert';DROP TABLE Brugere; - 'OG Password =' wrongpass '
Bemærk: Semikolonen er i en SQL-forespørgsel bruges til at angive slutningen af en bestemt sætning og begyndelsen af en ny sætning.
Som udføres af databasen som:
VÆLG BrugerID FRA Brugere WHERE UserName = 'Robert'
DROP TABLE Brugere
Så lige så har vi brugt et SQLI-angreb for at slette hele brugerens tabel.
Selvfølgelig kan meget værre ske, da angriberen, afhængigt af tilladte SQL-tilladelser, kan ændre værdier, dump tabeller( eller hele databasen selv) til en tekstfil, oprette nye login-konti eller endda kapre hele databaseinstallationen.
Forebyggelse af en 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 blindt stoler på brugerindgangen, som vi gjorde, da vi udførte simpel substitution i vores skabelonforespørgsel ovenfor.
Et SQLI-angreb er let imødegået af det, der kaldes sanitizing( eller escaping) dine input. Sanitize-processen er faktisk ret trivial, da alt det i det væsentlige gør, er at håndtere alle inline single quote( ') tegn på passende vis, så de ikke kan bruges til for tidligt at afslutte en streng inde i en SQL-sætning.
Hvis du f.eks. Ville 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 saniteret 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 brugerindgangen er sanitiseret.
myuser '- / wrongpass :
Vælger brugerID FRA Brugere WHERE Brugernavn =' myuser \ '-' OG Password = 'wrongpass'
Fordi det enkelte citat efter myuser er undslippet( hvilket betyder, at det anses for at være en del af måletværdi), vil databasen bogstaveligt søge efter brugernavnet for "myuser" - ".Da stregerne er inkluderet i strengværdien og ikke selve SQL-sætningen, betragtes de som en del af målværdien i stedet for at blive fortolket som en SQL-kommentar.
Robert ';DROP TABLE Brugere; - / wrongpass :
VÆLG BrugerID FRA Brugere 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 søgeordet UserName, så databasen vil bogstaveligt talt søge efter "Robert"; DROP TABLE Users;- "i stedet for at udføre tabellen slette.
I opsummering
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-værktøjer" designet til at udnytte dem.
Visse typer angreb, som DDoS, kan ikke nemt undgås, mens andre, såsom 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 trufne forholdsregler.
