Selvom du kun løst har fulgt begivenhederne i hackergrupperne Anonymous og LulzSec, har du sandsynligvis hørt om hackede websteder og tjenester, 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 selvom vi ikke prøver at give dig en manual til at gøre dette selv, er det nyttigt at forstå, hvad der foregår. To af de angreb, du konsekvent hører om dem ved hjælp af er "(Distribueret) Denial of Service" (DDoS) og "SQL Injections" (SQLI). Sådan fungerer de.
Billede af xkcd
Denial of Service Attack
Hvad er det?
Et "denial of service" -angreb (undertiden kaldet "distribueret denial of service" eller DDoS) opstår, når et system, i dette tilfælde en webserver, modtager så mange anmodninger ad gangen, at serverressourcerne er overbelastede, systemet låses simpelthen op 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?
Logistikken for et DDoS-angreb kan bedst forklares med et eksempel.
Forestil dig, at en million mennesker (angriberne) mødes med det mål at hæmme virksomhed X's forretning ved at nedtage deres callcenter. Angriberne koordinerer, så de alle sammen ringer til virksomhed Xs telefonnummer tirsdag kl. 9 om morgenen. Mest sandsynligt vil Company Xs telefonsystem ikke være i stand til at håndtere en million opkald på én gang, så alle de indgående linjer bliver bundet af angriberne. Resultatet er, at legitime kundeopkald (dvs. dem, der ikke er angriberne) ikke kommer igennem, fordi telefonsystemet er bundet til at håndtere opkaldene fra angriberne. Så i det væsentlige mister Company X potentielt forretning på grund af de legitime anmodninger, der ikke er i stand til at komme igennem.
Et DDoS-angreb på en webserver fungerer nøjagtigt på samme måde. Da der næsten ikke er nogen måde at vide, hvilken trafik der kommer fra legitime anmodninger vs. angribere, indtil webserveren behandler anmodningen, er denne type angreb typisk meget effektiv.
Udførelse af angrebet
På grund af den “brutale kraft” af et DDoS-angreb, skal du have masser af computere alle koordineret til at angribe på samme tid. Når vi igen gennemgår vores eksempel på callcenter, ville det kræve, at alle angriberne begge ved at ringe kl. 9 om morgenen og faktisk ringe på det tidspunkt. Mens dette princip helt sikkert vil fungere, når det kommer til at angribe en webserver, bliver det betydeligt lettere, når zombiecomputere, i stedet for faktiske bemandede computere, bruges.
Som du sikkert ved, er der mange varianter af malware og trojanske heste, som en gang på dit system ligger i dvale og lejlighedsvis “ringer hjem” 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 den respektive malware hjemmeplacering kan en enkelt angriber øjeblikkeligt koordinere hundreder af tusinder af kompromitterede computere for at udføre et massivt DDoS-angreb.
Skønheden ved at bruge zombiecomputere ligger ikke kun i dens effektivitet, men også i dens anonymitet, da angriberen slet ikke behøver at bruge deres computer til at udføre angrebet.
SQL Injection Attack
Hvad er det?
Et "SQL-injektion" (SQLI) -angreb er en udnyttelse, der drager fordel af dårlige webudviklingsteknikker og typisk kombineret med defekt databasesikkerhed. Resultatet af et vellykket angreb kan variere fra at udgive sig for at være en brugerkonto til et komplet kompromis mellem den respektive database eller server. I modsætning til et DDoS-angreb kan et SQLI-angreb fuldstændigt og let forhindres, hvis en webapplikation er programmeret korrekt.
Udførelse af angrebet
Når du logger ind på et websted og indtaster dit brugernavn og din adgangskode, for at teste dine legitimationsoplysninger kan webapplikationen køre en forespørgsel som følgende:
VÆLG brugerID FRA brugere WHERE UserName = 'myuser' AND Password = 'mypass';
Bemærk: strengværdier i en SQL-forespørgsel skal være lukket i enkelt anførselstegn, hvorfor de vises omkring brugerens indtastede værdier.
Så kombinationen af det indtastede brugernavn (myuser) og password (mypass) skal matche en post i tabellen Brugere for at et UserID skal returneres. Hvis der ikke er noget match, returneres ingen UserID, så loginoplysningerne er ugyldige. Mens en bestemt implementering kan variere, er mekanikken ret standard.
Så lad os nu se på en skabelongodkendelsesforespørgsel, som vi kan erstatte de værdier, som brugeren indtaster på webformularen:
VÆLG brugerID FRA brugere WHERE UserName = '[user]' AND Password = '[pass]'
Ved første øjekast kan dette virke som et ligetil og logisk trin til let validering af brugere, men hvis en simpel erstatning af de brugerindtastede værdier udføres på denne skabelon, er den modtagelig for et SQLI-angreb.
Antag for eksempel, at “myuser’–” er indtastet i feltet brugernavn, og “forkert adgang” indtastes i adgangskoden. Ved hjælp af simpel erstatning i vores skabelonforespørgsel ville vi få dette:
VÆLG brugerID FRA brugere WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
En nøgle til denne erklæring er inkluderingen af de to bindestreger
(--)
. Dette er startkommentar-token for SQL-sætninger, så alt, der vises efter de to bindestreger (inklusive), ignoreres. I det væsentlige udføres ovenstående forespørgsel af databasen som:
VÆLG brugerID FRA brugere WHERE UserName = 'myuser'
Den åbenlyse udeladelse her er manglen på adgangskontrol. Ved at medtage de to bindestreger som en del af brugerfeltet, gik vi helt uden om adgangskontroltilstanden og kunne logge ind som “myuser” uden at kende den respektive adgangskode. Denne handling ved at manipulere forespørgslen til at producere utilsigtede resultater er et SQL-injektionsangreb.
Hvilken skade kan der gøres?
Et SQL-injektionsangreb er forårsaget af uagtsom og uansvarlig applikationskodning og kan forhindres fuldstændigt (hvilket vi vil dække om et øjeblik), men omfanget af den skade, der kan gøres, afhænger af databaseopsætningen. For at en webapplikation kan kommunikere med backend-databasen, skal applikationen levere et login til databasen (bemærk, dette er anderledes end et brugerlogin til selve webstedet). Afhængigt af hvilke tilladelser webapplikationen kræver, kan denne respektive databasekonto kun kræve alt fra læse- / skrivetilladelse i eksisterende tabeller til fuld databaseadgang. Hvis dette ikke er klart nu, kan et par eksempler hjælpe med at skabe klarhed.
Baseret på ovenstående eksempel kan du se det ved at indtaste for eksempel
"dinbruger" - "," admin "-"
eller ethvert andet brugernavn, kan vi øjeblikkeligt logge ind på webstedet som den bruger uden at kende adgangskoden. Når vi først er i systemet, ved vi ikke, at vi faktisk ikke er den bruger, så vi har fuld adgang til den respektive konto. Databasetilladelser giver ikke et sikkerhedsnet til dette, fordi et websted typisk skal have mindst læse- / skriveadgang til sin respektive database.
Lad os antage, at webstedet har fuld kontrol over sin respektive database, som giver mulighed for at slette poster, tilføje / fjerne tabeller, tilføje nye sikkerhedskonti osv. Det er vigtigt at bemærke, at nogle webapplikationer muligvis har brug for denne type tilladelse, så det er ikke automatisk en dårlig ting, at der gives fuld kontrol.
For at illustrere den skade, der kan ske i denne situation, bruger vi eksemplet i tegneserien ovenfor ved at indtaste følgende i brugernavnsfeltet:
"Robert '; DROP TABLE Brugere; -".
Efter simpel erstatning bliver godkendelsesforespørgslen:
VÆLG brugerID FRA brugere WHERE UserName = 'Robert'; DROP TABLE Brugere; - 'AND Password =' wrongpass '
Bemærk: semikolonet er i en SQL-forespørgsel bruges til at betegne slutningen af en bestemt sætning og begyndelsen af en ny sætning.
Hvilket bliver udført af databasen som:
VÆLG brugerID FRA brugere WHERE UserName = 'Robert'DROP TABLE Brugere
Så bare sådan har vi brugt et SQLI-angreb til at slette hele tabellen Brugere.
Selvfølgelig kan meget værre gøres, da angriberen afhængigt af de tilladte SQL-tilladelser kan ændre værdier, dumpe tabeller (eller hele selve databasen) til en tekstfil, oprette nye login-konti eller endda kapre hele databaseinstallationen.
Forebyggelse af et SQL-injektionsangreb
Som vi nævnte flere gange tidligere, kan et SQL-injektionsangreb let forhindres. En af de vigtigste regler for webudvikling er, at du aldrig stoler blindt på brugerinput, som vi gjorde, da vi udførte en simpel erstatning i vores skabelonforespørgsel ovenfor.
Et SQLI-angreb modvirkes let af det, der kaldes at desinficere (eller undslippe) dine input. Desinficeringsprocessen er faktisk ganske triviel, da alt, hvad det i det væsentlige gør, er at håndtere ethvert indbygget enkelt citat (') tegn passende, så de ikke kan bruges til at afslutte en streng for tidligt inde i en SQL-sætning.
Hvis du f.eks. Vil slå op "O'neil" i en database, kunne du ikke bruge simpel erstatning, fordi det enkelte citat efter O ville få strengen til at slutte for tidligt. I stedet renser du det ved hjælp af den respektive databases escape-karakter. Lad os antage, at flugttegnet for et indbygget enkelt citat forud for hvert citat med et \ symbol. Så "O’neal" ville blive renset som "O \ 'neil".
Denne enkle sanitetshandling forhindrer stort set et SQLI-angreb. For at illustrere, lad os besøge vores tidligere eksempler og se de resulterende forespørgsler, når brugerindgangen er renset.
myuser '-
/
forkert pas
:
VÆLG brugerID FRA brugere WHERE UserName = 'myuser \' - 'AND Password =' wrongpass '
Da det enkelte citat, efter at min bruger er undsluppet (hvilket betyder, at det betragtes som en del af målværdien), vil databasen bogstaveligt talt søge efter brugernavnet på
"myuser '-".
Da bindestregerne er inkluderet i strengværdien og ikke selve SQL-sætningen, betragtes de derudover som en del af målværdien i stedet for at blive fortolket som en SQL-kommentar.
Robert '; DROP TABLE Brugere; -
/
forkert pas
:
VÆLG brugerID FRA brugere WHERE UserName = 'Robert \'; DROP TABLE Brugere; - 'AND Password =' wrongpass '
Ved blot at slippe for det enkelte citat efter Robert er både semikolon og bindestreger indeholdt i UserName-søgestrengen, så databasen bogstaveligt talt søger efter
"Robert '; DROP TABLE Users; -"
i stedet for at udføre tabellen skal du slette.
Sammenfattende
Mens webangreb udvikler sig og bliver mere sofistikerede eller fokuserer på et andet indgangspunkt, er det vigtigt at huske at beskytte mod afprøvede og sande angreb, som har været inspirationen til adskillige frit tilgængelige "hacker-værktøjer" designet til at udnytte dem.
Visse typer angreb, såsom DDoS, kan ikke let undgås, mens andre, såsom SQLI, kan. Imidlertid kan den skade, der kan gøres ved disse typer angreb, variere alt fra en ulejlighed til katastrofal afhængigt af de forholdsregler, der er truffet.
