Billede af

xkcd

Betydning af serviceangreb Hvad er det?

Et "benægtelse af tjeneste" (undertiden kaldet "distribueret benægtelse" eller DDoS) angreb opstår, når et system, i dette tilfælde en webserver, modtager så mange forespørgsler ad gangen, at serverressourcerne er overbelastede, låser systemet simpelthen op og lukkes. Målet og resultatet af et succesfuldt DDoS-angreb er, at webstederne på målserveren ikke er tilgængelige for legitime trafikforespørgsler.

Hvordan virker det?

Logistik af et DDoS-angreb kan bedst forklares med et eksempel.

Forestil dig, at en million mennesker (angriberne) mødes med målet om at hæmme virksomhed Xs forretning ved at tage deres call center 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 angriberne, indtil webserveren behandler anmodningen, er denne type angreb typisk meget effektiv.

Udfør angrebet

På grund af "brute force "karakter af et DDoS-angreb, skal du have masser af computere, som alle koordineres til at angribe på samme tid. Revision af vores callcenter eksempel ville kræve, at alle angriberne begge ved at ringe klokken 9 og faktisk ringe på det tidspunkt. Selvom 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 egentlige bemandet computere, udnyttes.

Som du sikkert ved, er der mange varianter af malware og trojanere, som , en gang på dit system, ligge sovende og lejlighedsvis "telefon 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 hjemstedet for den 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å også i sin anonymitet, da angriberen slet ikke skal bruge computeren til at udføre angrebet.

SQL Injection Attack

Hvad er det?

Et SQL-injektion er en udnytte, der udnytter dårlige webudviklingsteknikker 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 fuldstændigt og let forhindret, hvis en webapplikation er korrekt programmeret.

Udfør angrebet

Når du logger ind på et websted og indtast dit brugernavn og adgangskode, for at teste din legitimationsoplysninger webapplikationen kan udføre en forespørgsel som følgende:

SELECT UserID FROM Brugere WHERE UserName = "myuser" OG Password = "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 adgangskoden (mypass) skal matche en post i Brugere bord for at en UserID skal returneres. Hvis der ikke er nogen match, returneres ingen UserID, så loginoplysningerne er ugyldige. Selv om en bestemt implementering kan afvige, er mekanikerne ret normale.

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 UserName = " [bruger] "og password =" [pass] "

Ved første øjekast kan det 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 det modtagelige for et SQLI-angreb.

Antag for eksempel, at "myuser" - "er indtastet i brugernavnet 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 ovennævnte forespørgsel af databasen som:SELECT UserID FROM Users WHERE Brugernavn = "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.

Hvilken skade kan gøres?

Et SQL-indsprøjtningsangreb skyldes uagtsom og uansvarlig applikationskodning og er fuldstændig forhindret (som vi vil dække i 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 eksempler være med til at give klarhed.

På baggrund af ovenstående eksempel kan du se det ved at indtaste for eksempel

"brugeren" - "," 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 webstedet har fuld kontrol over sin respektive database, som giver evnen at slette poster, tilføj / fjern tabeller, tilføj nye sikkerhedskonti osv. 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, der giver fuld kontrol.Så til illustrere det skader, 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 Brugere; - ".

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 erklæring og begyndelsen af ​​en ny sætning.

Hvilket udføres af databasen som:

SELECT UserID FROM Users WHERE Brugernavn = "Robert"

DROP TABLE Brugere

Så lige så har vi brugt et SQLI-angreb for at slette hele bruger-tabellen.

Selvfølgelig kan meget værre ske, da angriberen, afhængigt af tilladte SQL-tilladelser, kan ændre værdier, dumpe tabeller (eller hele databasen selv) til en tekstfil, oprette nye login-konti eller endda kapre hele databaseinstallationen.

Forebyggelse af et SQL-indsprøjtningsangreb

Som vi nævnte flere gange tidligere, er det let at forebygge et SQL-indsprøjtningsangreb. En af de kardinale regler for webudvikling er, at du aldrig blindt stoler på brugerinddata, som vi gjorde, da vi udførte simpel substitution i vores skabelonforespørgsel ovenfor.

Et SQLI-angreb er let imødegået af, hvad der kaldes rensning (eller undslippe) dine input. Sanitetsprocessen er faktisk ret triviel, da alt det i det væsentlige gør, er at håndtere alle inline single citationstegn (') tegn på en sådan måde, at de ikke kan bruges til for tidligt at afslutte en streng inde i en SQL-sætning.

Hvis du f.eks. lookup "O'neil" i en database, kunne du ikke bruge simpel substitution, fordi det enkelte citat efter O'en ville få snoren til for tidligt at ende. 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 sanitiseret som "O 'neil".

Denne enkle sanitetshandling 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 : SELECT UserID FROM Brugere WHERE UserName = " myuser "- 'og password =" wrongpass " fordi det enkelte citat efter myuser er undgået (hvilket betyder at det anses for at være en del af målværdien), vil databasen bogstaveligt søge efter brugernavnet på

- ".

Da stregerne også er inkluderet i strengværdien og ikke selve SQL-sætningen, vil de blive betragtet som en del af målværdien i stedet for at blive fortolket som en SQL-kommentar.Robert '; DROP TABLE Brugere; -/

wrongpass : SELECT UserID FRA Brugere WHERE UserName = "Robert "; DROP TABLE Brugere; - 'OG Password = "wrongpass" Ved simpelthen at undslippe det enkelte citat efter Robert er både semikolonet og bindestregerne indeholdt i brugernavnetes søgestreng, så databasen vil bogstaveligt talt søge efter

"Robert" ; DROP TABLE Brugere; - "

i stedet for at udføre tabellen slette.I SammenfatningMens webangreb udvikler sig og bliver mere sofistikeret eller fokuserer på et andet indgangspunkt, er det vigtigt at huske at beskytte mod sande angreb, der har været inspiration for flere frit tilgængelige "hacker-værktøjer", der er udformet til at udnytte dem.

Visse typer angreb, såsom DDoS, kan ikke nemt undgås, mens andre, som f.eks. 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 forholdsregler, der træffes.

Automatisk login til Windows 8 med Microsoft eller Local Account

Med Windows 8 er der nu to måder at logge ind på din computer: via en Microsoft-konto, der synkroniserer dine indstillinger og apps på tværs af Windows 8-pc'er og via en lokal konto, der har været standard siden begyndelsen. For min computer hjemme har jeg altid fjernet ethvert kodeord og sat det op, så computeren ville logge ind automatisk.Da je

(How-to)

Lav en super skjult mappe i Windows uden nogen ekstra software

Næsten alle ved, hvordan man laver en "skjult" mappe i Windows, men så igen ved næsten alle andre, hvordan man laver explorer vise skjulte mapper . Lad os tage et kig på, hvordan man laver en mappe så skjult, kun du ved det. Alle, der har brugt Windows i et stykke tid, ved, at de kan højreklikke på en fil eller mappe og redigere dens egenskaber, mere dets attributter til at gøre det til en såkaldt "skjult" fil eller mappe.

(how-to)