Bilde av

xkcd

Denial of Service Attack Hva er det?

Et "tjenestenekt" (noen ganger kalt "distribuert tjenestenekt" 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 bare opp og slår seg av. Målet og resultatet av et vellykket DDoS-angrep er at nettstedene på målserveren ikke er tilgjengelige for legitime trafikkforespørsler.

Hvordan virker det?

Logistikken til et DDoS-angrep kan best forklares med et eksempel.

Forestill 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 kan komme igjennom.

Et DDoS-angrep på en webserver fungerer akkurat på samme måte. Fordi det er nesten ingen måte å vite hvilken trafikk som kommer 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 "brute tvinge "naturen 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, finnes det mange varianter av skadelig programvare og trojaner som , en gang på systemet, ligge 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 den respektive skadelig programvare, kan en enkelt angriper øyeblikkelig koordinere hundrevisusvis av kompromitterte datamaskiner for å utføre et massivt DDoS-angrep.

Det er ikke bare i sin effektivitet å gjøre bruk av zombie-datamaskiner, men også Også i anonymiteten da angriperen ikke faktisk trenger å bruke datamaskinen i det hele tatt for å utføre angrepet.

SQL Injection Attack

Hva er det?

Et "SQL-injeksjon" (SQLI) angrep er en utnytte 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 på et nettsted og skriver inn brukernavn og passord, for å teste din legitimasjonsinformasjon webapplikasjonen kan utføre en spørring som følgende:

VELG BrukerID FRA 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 brukerverdiene.

Så kombinasjonen av det angitte brukernavnet (myuser) og passordet (mypass) må samsvare med en oppføring i Brukertabell for at en UserID skal returneres. Hvis det ikke er noen kamp, ​​blir ingen UserID returnert, slik at påloggingsinformasjonen er ugyldig. Selv om en bestemt implementering kan variere, er mekanikken ganske standard.

Så nå, let's se på en forespørsel om malautentisering, som vi kan erstatte verdiene brukeren kommer inn på webskjemaet:

SELECT UserID FROM Users WHERE UserName = " [bruker] "og passord =" [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 malen, er det 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 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 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ørsmålet 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 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 det ved å skrive inn for eksempel

"user" - "," 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 evnen å slette poster, legge til / fjerne tabeller, legge til nye sikkerhetskontoer 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.Så å illustrere skaden som kan gjøres i denne situasjonen, vil vi bruke eksemplet som er oppgitt i tegneserien ovenfor ved å skrive inn følgende i brukernavnfeltet:

"Robert"; DROP TABLE Brukere; - ".

Etter enkel substitusjon blir autentiseringsspørsmålet:SELECT UserID FROM Users 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 slik har vi brukt et SQLI-angrep for å slette hele bruker-tabellen.

Selvfølgelig kan mye verre gjøres, fordi angriperen, avhengig av de tillatte SQL-tillatelsene, kan endre verdier, dumpe tabeller (eller hele databasen selv) til en tekstfil, opprette nye påloggningskontoer eller til og med kapre hele databasen installasjonen.

Forhindre et SQL-injeksjonsangrep

Som vi nevnte flere ganger tidligere, er et SQL-injeksjonsangrep enkelt å forebygge. 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 blir enkelt forstyrret av det som kalles sanitizing (eller escaping) dine innganger. Sanitize-prosessen er faktisk ganske triviell, da alt det i hovedsak handler, håndterer noen inline-enkeltattest (') 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 å Lookup "O'neil" i en database, kan du ikke bruke enkel substitusjon fordi det eneste 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 se på våre tidligere eksempler og se de resulterende spørringene når brukerinngangen er sanitisert.

myuser -

/

feilpass : SELECT UserID FROM Users WHERE UserName = " myuser "- 'og passord =" feilpass " fordi det enkle sitatet etter myuser er rømt (det betyr at det regnes som en del av målverdien), vil databasen bokstavelig talt søke etter brukernavnet på

" myuser " - ".

I tillegg, fordi bindestrekene er inkludert i strengverdien og ikke selve SQL-setningen, blir de vurdert som en del av målverdien i stedet for å bli tolket som en SQL-kommentar.Robert '; DROP TABLE Brukere; -/

feilpass : SELECT UserID FROM Brukere WHERE UserName = "Robert "; DROP TABLE Brukere; - 'OG Passord = "feilpass" Ved å bare slippe det enkle sitatet etter Robert, er både semikolon og bindestreker inneholdt i søkeordet UserName, så databasen vil bokstavelig talt søke etter

"Robert" ; DROP TABLE Brukere; - "

i stedet for å utføre tabellen slett.I sammendragMens 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.

Hvordan gjenoppretter du data fra et microSD-kort som ikke kan leses?

Vi har alle vært der og har en lagringsenhet av noe slag opplevd en feil, og lar våre dyrebare data være i fare. Men hva gjør du når enheten er et microSD-kort? Dagens SuperUser Q & A-post kommer til redning for en leser i nød. Dagens Spørsmål og svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

(how-to)

Slik konverterer du eldre dokumenter til Word 2013

Har du nylig oppgradert til Word 2013? Dokumenter opprettet i tidligere versjoner av Word er kompatible med Word 2013, men de nye funksjonene i Word 2013 vil ikke være tilgjengelige i de eldre dokumentene dine, med mindre du konverterer dem til den nyeste versjonen. Hvis du har dokumenter fra tidligere versjoner av Word som Du må henvise til eller endre, kanskje du vil konvertere dem til den nyeste versjonen.

(how-to)