Det finnes en rekke verktøy og teknikker som disse gruppene bruker, og mens vi ikke prøver å gi deg en håndbok for å gjøre dette selv, er det nyttig å forstå hva som skjer. To av angrepene du konsekvent hører om dem bruker, er "(Distributed) Denial of Service" (DDoS) og "SQL Injections" (SQLI). Slik fungerer de.
Bilde av XKCD
Denial of Service Attack
Hva er det?
Et "tjenestenavn" (noen ganger kalt "distribuert tjenestenekt" eller DDoS) angir at når et system, i dette tilfellet en webserver, mottar så mange forespørsler om gangen at serverressursene er overbelastede, låses systemet bare opp og slår seg ned. Målet og resultatet av et vellykket DDoS-angrep er at nettsidene på målserveren ikke er tilgjengelige for legitime trafikkforespørsler.
Hvordan virker det?
Logistikken til et DDoS-angrep kan best forklares med et eksempel.
Tenk deg at en million mennesker (angriperne) kommer sammen med målet om å hindre selskap Xs virksomhet ved å ta ned sitt call center. Angrepene koordinerer slik at de tirsdag klokken 9.00 alle vil ringe til selskapets telefonnummer. Sannsynligvis vil selskapets telefonsystem ikke kunne håndtere en million samtaler samtidig, så alle innkommende linjer vil bli bundet av angriperne. Resultatet er at legitime kundeanrop (det vil si de som ikke er angriperne) ikke kommer gjennom fordi telefonsystemet er bundet opp med å håndtere anropene fra angriperne. Så i utgangspunktet mister selskapet X potensielt tap på grunn av at de legitime forespørsler ikke klarer å komme igjennom.
Et DDoS-angrep på en webserver fungerer akkurat på samme måte. Fordi det er nesten ingen måte å vite hvilken trafikk er hentet fra legitime forespørsler mot angripere til webserveren behandler forespørselen, er denne typen angrep vanligvis svært effektiv.
Utfør angrepet
På grunn av den "brute force" -arten til et DDoS-angrep, må du ha mange datamaskiner som alle koordineres for å angripe på samme tid. Ved å revidere vårt call center-eksempel vil dette kreve at alle angriperne begge vet å ringe klokka 9.00 og faktisk ringe på den tiden. Selv om dette prinsippet sikkert vil fungere når det gjelder å angripe en webserver, blir det betydelig lettere når zombie-datamaskiner, i stedet for faktiske bemannede datamaskiner, benyttes.
Som du sikkert vet, er det mange varianter av skadelig programvare og trojaner som, en gang på systemet, ligger i hvilemodus og av og til "telefon hjemme" for instruksjoner. En av disse instruksjonene kan for eksempel være å sende gjentatte forespørsler til selskapets X-server på 9 AM. Så med en enkelt oppdatering til hjemstedet til respektive malware, kan en enkelt angriper øyeblikkelig koordinere hundrevisusvis av kompromitterte datamaskiner for å utføre et massivt DDoS-angrep.
Skjønnheten ved å utnytte zombie-datamaskiner er ikke bare i sin effektivitet, men også i anonymitet da angriperen ikke faktisk trenger å bruke datamaskinen i det hele tatt for å utføre angrepet.
SQL Injection Attack
Hva er det?
Et SQLI-angrep (SQL Injection) er en utnyttelse som utnytter dårlige webutviklingsteknikker og, vanligvis kombinert med feil databasesikkerhet. Resultatet av et vellykket angrep kan variere fra å utgjøre en brukerkonto til et komplett kompromiss av den respektive databasen eller serveren. I motsetning til et DDoS-angrep, er et SQLI-angrep helt og enkelt forhindret hvis et webprogram er riktig programmert.
Utfør angrepet
Når du logger deg inn på et nettsted og skriver inn brukernavn og passord, kan du prøve å teste legitimasjonene dine, og det kan hende at et søk som følgende:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Merk: strengverdier i en SQL-spørring må være vedlagt i enkelt anførselstegn, og derfor vises de rundt de brukerdefinerte verdiene.
Så kombinasjonen av det angitte brukernavnet (myuser) og passordet (mypass) må samsvare med en oppføring i brukertabellen for at en UserID skal returneres. Hvis det ikke er noen kamp, blir ingen UserID returnert, slik at påloggingsinformasjonen er ugyldig. Mens en bestemt implementering kan variere, er mekanikken ganske standard.
Så nå, la oss se på en forespørsel om malautentisering, som vi kan erstatte verdiene brukeren kommer inn på webskjemaet:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
Ved første øyekast kan dette virke som et enkelt og logisk trinn for å enkelt validere brukere, men hvis en enkel substitusjon av de brukerdefinerte verdiene utføres på denne mal, er den utsatt for et SQLI-angrep.
For eksempel, anta at "myuser" - "er skrevet inn i brukernavnet og" feilpass "er oppgitt i passordet. Ved å bruke enkel substitusjon i vår mal forespørsel, ville vi få dette:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
En nøkkel til denne setningen er inkluderingen av de to bindestrekene
(--)
. Dette er begynnelsestoken for SQL-setninger, slik at alt som vises etter de to strekkene (inkluderende) vil bli ignorert. I hovedsak er ovennevnte spørring utført av databasen som:
SELECT UserID FROM Users WHERE UserName='myuser'
Den skarpe utelatelsen her er mangelen på passordkontrollen.Ved å inkludere de to bindestrekene som en del av brukerfeltet, overgikk vi helt passordkontrolltilstanden og kunne logge inn som "myuser" uten å vite det respektive passordet. Denne handlingen med å manipulere spørringen for å produsere utilsiktede resultater er et SQL-injeksjonsangrep.
Hvilken skade kan gjøres?
Et SQL-injeksjonsangrep er forårsaket av uaktsom og uansvarlig programkoding og er helt forebyggbar (som vi vil dekke i et øyeblikk), men omfanget av skadene som kan gjøres avhenger av databasens oppsett. For at en webapplikasjon skal kunne kommunisere med backenddatabasen, må søknaden gi innlogging til databasen (merknad, dette er annerledes enn en brukerinnlogging til selve websiden). Avhengig av hvilke tillatelser webapplikasjonen krever, kan denne respektive database-kontoen kreve alt fra lese / skrive-tillatelse i eksisterende tabeller bare til full databasetilgang. Hvis dette ikke er klart nå, bør noen eksempler bidra til å gi klarhet.
Basert på eksempelet ovenfor kan du se at ved å skrive inn, for eksempel,
'youruser'--', 'admin'--'
eller et annet brukernavn, kan vi umiddelbart logge inn på nettstedet som den brukeren uten å vite passordet. Når vi er i systemet, vet vi ikke at vi egentlig ikke er brukeren, så vi har full tilgang til den respektive kontoen. Databasetillatelser gir ikke et sikkerhetsnett for dette fordi et nettsted vanligvis må ha lese / skrive-tilgang til sin respektive database.
La oss nå anta at nettstedet har full kontroll over sin respektive database, som gir muligheten til å slette poster, legge til / fjerne tabeller, legge til nye sikkerhetskontoer, etc. Det er viktig å merke seg at enkelte webprogrammer kan trenge denne typen tillatelse, så det Det er ikke automatisk en dårlig ting at full kontroll er gitt.
For å illustrere skaden som kan gjøres i denne situasjonen, bruker vi eksemplet som er oppgitt i tegneserien ovenfor ved å skrive inn følgende i brukernavn-feltet:
'Robert'; DROP TABLE Users;--'.
Etter enkel substitusjon blir autentiseringsspørsmålet:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Merk: Semikolonet er i en SQL-spørring brukes til å indikere slutten av en bestemt setning og begynnelsen av en ny setning.
Som blir utført av databasen som:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Brukere
Så akkurat slik har vi brukt et SQLI-angrep for å slette hele bruker-tabellen.
Selvfølgelig kan mye verre gjøres, da angriperen, avhengig av de tillatte SQL-tillatelsene, kan endre verdier, dumpe tabeller (eller hele databasen selv) til en tekstfil, opprette nye påloggingsregnskap eller til og med kapre hele databasens installasjon.
Forhindre et SQL-injeksjonsangrep
Som vi nevnte flere ganger tidligere, er det enkelt å forhindre et injeksjonsangrep i SQL. En av de kardinale reglene for webutvikling er at du aldri stoler på brukerinngang som vi gjorde da vi utførte enkel substitusjon i vår mal forespørsel ovenfor.
Et SQLI-angrep er lett forstyrret av det som kalles rensing (eller rømming) dine innganger. Sanitize-prosessen er faktisk ganske triviell, da alt det egentlig gjør, er å håndtere alle inline-enkeltnoteringer (') tegn på riktig måte slik at de ikke kan brukes til å for tidlig avslutte en streng inne i en SQL-setning.
For eksempel, hvis du ønsket å lete opp "O'neil" i en database, kan du ikke bruke enkel substitusjon fordi det enkle sitatet etter O ville føre til at strengen slutter for tidlig. I stedet renser du det ved å bruke den respektive databasens fluktegn. La oss anta at fluktegnene for et inline-tilbud er prefacing hvert sitat med et symbol. Så "O'neal" ville bli sanitized som "O 'neil".
Denne enkle sanitetsbehandlingen forhindrer ganske mye et SQLI-angrep. For å illustrere, la oss gå tilbake til våre tidligere eksempler og se de resulterende spørringene når brukerinngangen er sanitert.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Fordi det enkle sitatet etter myuser er rømt (som betyr at det regnes som en del av målverdien), vil databasen bokstavelig talt søke etter Brukernavn av
'myuser'--'.
I tillegg, fordi bindestrekene er inkludert i strengverdien og ikke selve SQL-setningen, vil de bli vurdert som en del av målverdien i stedet for å bli tolket som en SQL-kommentar.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Ved å bare slippe det enkle sitatet etter Robert, er både semikolon og bindestreker inneholdt i Brukernavn-søkestrengen, så databasen vil bokstavelig talt søke etter
'Robert'; DROP TABLE Users;--'
i stedet for å utføre tabellen slett.
Oppsummert
Mens webangrep utvikler seg og blir mer sofistikert eller fokuserer på et annet inngangssted, er det viktig å huske å beskytte mot prøvde og sanne angrep som har vært inspirasjonen til flere fritt tilgjengelige "hackerverktøy" designet for å utnytte dem.
Visse typer angrep, som DDoS, kan ikke lett unngås mens andre, for eksempel SQLI, kan. Skaden som kan gjøres ved disse typer angrep kan imidlertid variere alt fra en ulempe til katastrofale avhengig av de forholdsregler som er truffet.
