26Aug
Selv om du bare har løst fulgt hendelsene til hackergruppene Anonymous og LulzSec, har du sikkert hørt om at nettsider og tjenester blir hacket, som de beryktede Sony hackene. Har du noen gang lurt på hvordan de gjør det?
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 "tjenestenekt"( noen ganger kalt et "distribuert denial of service" eller DDoS) angrep skjer når et system, i dette tilfellet en webserver, mottar så mange forespørsler om gangen at serverressursene er overbelastede, låser systemet bareopp og avsluttes. 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 "DDD-angrepets" brutale kraft 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 trojanere 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 bruk av zombie-datamaskiner er ikke bare i sin effektivitet, men også i sin anonymitet da angriperen ikke egentlig trenger å bruke datamaskinen i det hele tatt for å utføre angrepet.
SQL Injection Attack
Hva er det?
Et "SQL injection" -angrep 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øre angrepet
Når du logger inn på et nettsted og oppgir brukernavn og passord, kan du søke etter spørsmål som følgende:
SELECT UserID FROM Brukere WHERE UserName = 'myuser' og passord= '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 Brukere WHERE UserName = '[user]' og passord = '[pass]'
Ved første øyekast dettekan 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 Brukere WHERE UserName = 'myuser' - 'og passord =' feilpass '
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 utføres spørringen ovenfor av databasen som:
SELECT UserID FROM Brukere 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 applikasjonskoding og er helt forebyggbar( som vi vil dekke i et øyeblikk), men omfanget av skaden som kan gjøres, avhenger av oppsettet av databasen. For at en webapplikasjon skal kunne kommunisere med backenddatabasen, må søknaden gi et innlogging til databasen( merknad, dette er annerledes enn en brukerlogging 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 "brukeren" - "," 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 sikkerhetsregnskap osv. Det er viktig å merke seg at enkelte webprogrammer kan trenge denne typen tillatelse, såDet er ikke automatisk en dårlig ting at full kontroll er gitt.
For å illustrere skaden som kan gjøres i denne situasjonen, vil vi bruke eksemplet som er gitt i tegneserien ovenfor ved å skrive inn følgende i brukernavnfeltet: "Robert"; DROP TABLE Users; - ".Etter enkel substitusjon blir autentiseringsspørsmålet:
SELECT UserID FROM Brukere WHERE UserName = 'Robert';DROP TABLE Brukere; - 'OG Passord =' feilpass '
Merk: Semikolonen 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 Brukere WHERE UserName = 'Robert'
DROP TABLE Brukere
Så akkurat som det 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 en SQL-injeksjonsangrep
Som vi nevnte flere ganger tidligere, er det enkelt å forebygge et SQL-injeksjonsangrep. 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.
Hvis du for eksempel vil se opp "O'neil" i en database, kan du ikke bruke enkel substitusjon fordi det enkelte 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 '- / feilpass :
VELG BrukerID FRA Brukere WHERE Brukernavn =' myuser \ '-' OG Passord = 'feilpass'
Fordi det enkelte sitatet etter myuser er rømt( noe som betyr at det regnes som en del av måletverdi), 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 Brukere; - / feilpass :
VELG BrukerID FRA Brukere WHERE UserName = 'Robert \';DROP TABLE Brukere; - 'OG Passord =' feilpass '
Ved å bare slippe det enkle sitatet etter Robert, er både semikolonet og bindestrekene inneholdt i søkeordet UserName, så databasen vil bokstavelig talt søke etter "Robert"; DROP TABLE Users;- "i stedet for å slette tabellen.
I sammendrag
Mens webangrep utvikler seg og blir mer sofistikert eller fokuserer på et annet inngangspunkt, 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.
Enkelte 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.