Cookies som en fare: På tværs af site anmodning forfalskning

Tobias Schüring Senest opdateret den 21. januar 2020
7 Min.
CSRF-angreb (Request Forgery) på tværs af websteder i WordPress er blandt de ældste angreb nogensinde.

CSRF, vises denne forkortelse igen og igen i sikkerheds- og vedligeholdelsesopdateringerne til WordPress - Det er kernen. Metoden bag det er nu en gammel hat og udnytter de rigelige cookies af en internetbruger. Heldigvis er det dog ret nemt at beskytte dig mod anmodning om forfalskning på tværs af websteder. Alt hvad du behøver er lidt tid og opmærksomhed.

Du vil helt sikkert bruge en lang række tjenester, hvor der er mulighed for at forblive logget ind, selv efter at du forlader webstedet. Hvis du derefter besøger webstedet igen, behøver du ikke at indtaste dine loginoplysninger igen, men vil blive logget direkte ind. Dette er naturligvis godt for brugeren, fordi det sparer irriterende formularudfyldning, ligesom en adgangskodestyring eller et såkaldt enkelt tegn på.

I baggrunden sker følgende: Når du logger ind på siden for første gang, gemmer webstedet en cookie i din browser. Det er en lille tekstfil, der kan gemme specifikke oplysninger. I tilfælde af login er dette en tilfældigt genereret tegnstreng.

Ved dit næste besøg på hjemmesiden kontrollerer serveren denne tegnstreng, og hvis den kan finde den relevante modpart, logger den automatisk ind. Forresten er dette også grunden til, at du vil blive logget ud overalt, når du tømmer din browsercache. Denne proces sletter også alle cookies.

Et CSRF-angreb er kernen i mistilliden

Du bemærker allerede: I et tilsvarende angreb narrer angriberen tjenesten, som læser cookies noget. Jeg vil forklare præcis, hvordan dette sker i to eksempler nedenfor.

Faren ved denne manipulation er, at en tredjepart, dvs. angriberen, foretager ændringer på din Facebook-profil, for eksempel på dine vegne. Anmodning om forfalskning på tværs af websteder er også ofte afhængig af phishing. Også her bliver tillid relevant – og det er din tillid til f.eks. afsenderne af e-mails.

CSRF-angreb (Cross Site Request Forgery) på WordPress kan forebygges på grund af sund fornuft.

Hvor sårbar er WordPress ?

Du har sandsynligvis ikke hørt udtrykket Cross-Site Request Forgery så ofte som du Brute Force Angreb eller scripting på tværs af websteder. Der er en grund til dette: Den non-profit organisation OWASP (Open Web Application Security Project) offentliggør regelmæssigt en liste over de ti mest kritiske sårbarheder i webapplikationer. På den foreløbige liste for 2017 rangerer CSRF som nummer 8 ud af 10. pladsen i 2007 og 2010, angrebet rangerede stadig som nummer 5, i 2013 faldt det til en 8. plads.

Dette skyldes sandsynligvis til dels, at CSRF-angreb er næsten lige så gamle som selve internettet. Professionelle udviklere er nu uddannet i at sikre deres kode mod det. Sikkerhedsrisici håndteres derfor nemt og hurtigt.

På WordPress du er også på vagt. For eksempel blev sikkerhedsopdatering 4.7.5 udgivet i maj, som ryddede op i seks sårbarheder, der kunne have forårsaget hackere til at angribe via cross-site scripting eller cross-site Request Forgery. Scripting på tværs af websteder anses dog ofte for at være meget farligere.

Desuden har spørgsmålet om anmodning om forfalskning på tværs af websteder en tendens til at være mere Plugin - og applikationsudviklere, der er mere relevante end for webdesignere, bureauer og SMV'er. Fordi beskyttelse mod EFSR er også et spørgsmål om programmering. relevant, kunne FSRF f.eks. Plugin Køb.

Men hvordan fungerer det hele nu?

Anatomien af anmodning om forfalskning på tværs af websteder

Den grundlæggende idé bag et CSRF-angreb er relativt enkel og sker normalt i to trin:

  1. Hackeren får offeret til at indlæse en kompromitteret side eller klikke på et link, for eksempel ved at foregive at være en administrator eller udnytte menneskelig nysgerrighed. Med andre ord spiller phishing en vigtig rolle i denne type angreb.
  2. Når du indlæser eller klikker på de manipulerede links eller sider, udfører offerets browser en HTTP-anmodning, uden at offeret bemærkede det.

To relativt enkle eksempler illustrerer, hvordan et sådant angreb fungerer.

Lad os antage justus ønsker at overføre Bob over siden www.bank.de 100 €, og Skinny er på lokke til at udføre en CSRF angreb. Skinny kan nu for eksempel være ansvarlig for sit angreb. Brug metoden GET eller POST.

I øvrigt kommer følgende eksempler fra følgende kilder:

Anmodningsforfalskning på tværs af websteder ved GET-metoden

Metoden GET anmoder om en ressource fra en server, f.eks. De nødvendige parametre for opkaldet føjes blot til URL-adressen. Og som vi allerede ved fra SQL-injektioner, er en URL relativt let at manipulere.

Justus logger ind for at www.bank.de og indtaster alle de nødvendige data. Følgende (helt fiktive) input overføres til serveren:

HENT http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny konstruerer nu en webadresse, der overfører € 100.000 til sin egen konto i stedet. Det ser sådan ud:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Selvfølgelig skal Justus også udføre handlingen skjult bag det falske link. Derfor sender Skinny Justus en e-mail med et falsk link. HTML-koden kan f..B eks.

">Hvad kan ikke løse dette puslespil er ikke en rigtig detektiv!

Eller han sender ham en e-mail, der indeholder en "usynlig" (fordi 0 af 0 pixels) billede. Når du forsøger at indlæse billedet, får browseren adgang til URL-adressen, uden at Justus endda lægger mærke til det:

Når Justus ringer til linket – bevidst eller ubevidst, overføres parametrene til serveren, overførslen udløses, og 100.000 € forsvinder fra hans konto.

Selvfølgelig skal Justus klikke på linket, mens det er logget ind. Men hvis der desværre er en login cookie fra sin bank i sin browser, angrebet virker, selv om han ikke har åbnet siden.

Dette er præcis, hvad Cross-Site Request Forgery gør det lusket: offeret kan ikke engang være klar over, at cookien eksisterer.

Anmodningsforfalskning på tværs af websteder ved POST-metoden

GET-metoden kan bruges i links og er derfor særligt let at sprede. Dette spiller selvfølgelig i hænderne på angriberen, når det kommer til distribution. Nu kan udbydere dog sikre, at GET-anmodninger i princippet ikke modtager skrivetilladelse.

Der er stadig POST-metoden: Data overføres til en server, så den kan behandle den yderligere. Dataene er dog ikke en del af URL-adressen, men føjes til sidehovedet.

Lyder en smule omfangsrig, men du helt sikkert kender use case. Fordi formularer fungerer på den måde.

For vores angriber, Skinny, betyder det, at han er nødt til at gøre en større indsats, men kan stadig komme dertil.

Samme scenarie: Justus ønsker at overføre penge til Bob. Så han udfylder følgende formular på www.bank.de:

<form metode="POST" handling="geld_ueberweisen.php">      < inputtype ="tekst" navn="fra">      < inputtype ="tekst" navn="en">      < inputtype ="tekst" navn="betrag_in_euro">      < inputtype ="send">  form>

Dette sender kommandoen geld_ueberweisen.php, der ser sådan ud:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Som du kan se, kontrollerer koden cookien for at se, om Justus er logget ind. Kun hvis det er tilfældet, udføres overførslen.

Skinny nu indskud en usynlig form på en manipuleret hjemmeside, e.B.

<form metode="POST" handling="http://www.bank.de/geld_ueberweisen.php">      < input type="tekst" navn="fra" værdi="Justus" style="display: hidden">      < input type="text" name="an" value="Tynd" style="display: hidden">      < input type="text" name="betrag_in_euro" value="100000" style="display: hidden        <      >"    er ikke en rigtigdetektiv!" > formular>

Han sender linket til denne manipulerede hjemmeside til Justus. Han føler sig udfordret, klikker på knappen for at se puslespillet; og allerede han ubevidst udfører den funktion, geld_ueberweisen.php. Da dette finder en tilsvarende cookie i sin browser, vil 100.000 € blive overført til Skinny igen.

Angrib via omveje

Derfor er navnet Cross-SiteRequestForgery: Hackeren normalt sender kommandoen fra en anden side. For at angribe side A, det således indskud på side B ondsindet kode. Så lokker han den intetanende bruger her, så hans browser udfører koden.

Hvor farlige er CSRF-angreb (Cross Site Request Forgery) i WordPress ?

Sådan bekæmper du CSRF-angreb

Den gode nyhed: Cross-Site Request Forfalskning har været kendt i aldre. Udviklere kender risikoen og arbejder specifikt for at slippe af med det.

Den dårlige nyhed: Du kan ikke rigtig beskytte dig mod det på den tekniske side. Den WordPress -Core er nu relativt godt beskyttet, og som du kan se af de igangværende opdateringer, arbejder vi konstant på det. Som med andre typer angreb kommer de fleste sårbarheder med Plugins Derfor. Så du er nødt til at stole på, at udviklerne af de udvidelser, du bruger, gør et godt stykke arbejde.

Helt konkret betyder det:

  • Installer' ikke for mange Plugins og kun Plugins , som du virkelig har brug for
  • Pas på Plugins , som ikke er blevet opdateret af udviklerne i et stykke tid. Dette kan skjule uløste sikkerhedssvagheder.
  • Informer dig selv på forhånd om Plugins , som du installerer, e.B. om deres kompatibilitet med andre Plugins eller WordPress version, du bruger (så Plugin opdateringer).
  • Opdater din Plugins og WP-Core på regelmæssig basis. Fordi de kontinuerlige opdateringer er der for at lukke sådanne sårbarheder.
  • dig kritisk over for phishing
  • Hvis du er usikker: Se på det Plugin i WP-lageret. Hvordan mislykkes anmeldelserne, hvad var de største problemer i fortiden og har Plugin en fremtrædende sikkerhedsrisiko kan ikke lukkes?

Dom: CSRF er en gammel hat

Anmodningsforfalskning på tværs af websteder har eksisteret siden begyndelsen af den digitale tidsalder. Derudover sammenlignes sagsnumrene med f.eks. Brute Force Angreb ekstremt små.

Dette bekræftes også af OWASP's vurdering: Det antages,at angrebet er ret lavt spredt, let at opdage og kun alvorligt i meget specifikke tilfælde.

Ikke desto mindre er det godt at vide, hvordan angrebene fungerer. Fordi angrebene ofte kun virker takket være menneskelige fejl. Igen og igen åbner brugerne mails af nysgerrighed eller klikker på links, som de hellere ikke ville have åbnet.

Uanset om du er bruger eller bruger, er den bedste måde at beskytte dig mod anmodning om forfalskning på tværs af websteder at gøre det med forskning og en vis sund fornuft.

Som systemadministrator overvåger Tobias vores infrastruktur og finder alle justeringsskruer for at optimere vores serveres ydeevne. På grund af hans utrættelige indsats, er han ofte også Slack findes.

Lignende artikler

Kommentarer til denne artikel

Skriv svar på en

Din e-mailadresse vil ikke blive offentliggjort. Obligatoriske felter er markeret med *.