Denne side bruger cookies
Dette forum bruger cookies. Hvis du er registreret, bruges de til at huske hvem du er logget ind som. Hvis ikke, gemmer vi dit sidste besøgstidspunkt. Besøgstidspunktet bruges bl.a. til at holde øje med, hvilke tråde du allerede har læst. Cookies er små tekstdokumenter, som bliver gemt i din browser og udgør ingen sikkerhedsrisiko. Tryk "Mere Information" nedenfor, for en liste over de cookies vi sætter. Du har mulighed for at fravælge cookies ved at klikke på knappen "Blokér Cookies" i bunden af denne boks.

En ikke-personhenførbar cookie vil blive gemt i din browser, uanset dit valg (Medmindre du ikke foretager et). Således undgår du at blive spurgt igen. Du kan til enhver tid ændre dit valg via linket i bunden af siden.

Tråd bedømmelse:
  • 0 Stemmer - 0 Gennemsnit
  • 1
  • 2
  • 3
  • 4
  • 5
[STUT] CSRF (Cross-Site Request Forgery)
23-02-2013, 15:21 (Denne besked var sidst ændret: 28-05-2013, 00:38 af Doctor Blue.)
#1
[STUT] CSRF (Cross-Site Request Forgery)
NOTE: Det her er kun til uddannelsesmæssige formål alene. Der tages intet ansvar for forkert brug af dette.


Indholdsfortegnelse
  1. Teori
  2. Finde sårbarheden
  3. Udnyttelse af sårbarheden
  4. Ekstra referencer



1. Teori
CSRF(Coss-site request forgery) udtales oftest ”Sea-Surf”. Dette angreb består i, at der er en side som kan modtage nogle anmodninger fra en bruger. F.eks. søgefunktion, login, skifte kodeord, skifte navn. Hackeren kan her smede en falsk anmodning og videregive linket skjult i f.eks billeder til brugeren, og brugeren vil afgive disse anmodninger til siden uden selv at vide det, fordi siden blot benytter brugerens cookie til at autentificere at det er brugeren der kommer med forespørgslen. Hackeren kan med dette benytte sidens funktioner såsom skift kodeord, skift navn osv.


2. Finde sårbarheden

For at finde en sårbarhed skal du først finde et mål.
I dette eksempel vil vi finde en side hvor brugeren har mulighed for at skifte sit kodeord. Lad os sige at brugeren hedder ash.
Ash er medlem af denne fiktive side som hedder pokemontarget.com
På pokemontarget.com kan man have en profil.
Pokemontarget.com har også muligheden for at skifte sit kodeord.
For når man skal skifte det, beder den blot om det nye kodeord og så er der en ok knap. Denne form kunne også være til at skifte sit brugernavn eller meget andet.
Formen i dette eksempel ser sådan her ud:
<form action=”changepassword.php” method=”get”>
<input type=”text” name=”newpassword” value=”Indtast dit nye kodeord”>
<input type=”submit” name=”submit” value=”change password”>
</form>
Denne kunne du have fundet på alle slags sider da sidens html er frit tilgængeligt og et lille højreklik med ”Vis kildekode” ville have afsløret dette.


Formen sender simpelt et kodeord til et php script der tjekker din cookie og ser om det er dig. Hvis det er, opdatere dit kodeord i databasen. Simple stuff!

Det første problem som du noterer, er at der ikke bliver medsendt noget unikt men alle blot kunne genskabe denne request.
Dit næste skridt ville så være at tjekke om siden holder øje med henviseren(referrer). Dette er den side du kom fra da du klikkede ind på linket. Dette kan du let tjekke ved blot at gå til www.google.dk og derefter afprøve anmodningen.
www.pokemontarget.com/changepassword.php?newpassword=1234
Her ville din referrer være www.google.dk, da du kom fra www.google.dk
Hvis dit kodeord skifter alligevel har du fundet en CSRF sårbarhed.

3. Udnyttelse af sårbarheden

For at udnytte denne CSRF sårbarhed som du lige har fundet skal du smede din egen anmodning, som navnet nok indikere. Dette vil sige at du først skal finde ud af hvordan denne anmodning ville se ud.
Og i almindelig format ville den se sådan her ud
www.pokemontarget.com/changepassword.php?newpassword=newpasswordhere
Men hvad nu hvis du lavede den om til:
www.pokemontarget.com/changepassword.php?newpassword=1234
og sendte dette til brugeren ash ?
Hvis ash åbnede det ville hans kodeord blive ændret til 1234. Det ville det fordi at siden benytter ash's cookie og tror at ash selv har klikket skift kodeord.

Du kan nu logge ind med hans brugernavn og hans nye kodeord. Dette kunne være mange andre ting man kunne. Poste ting på forums eller meget andet som har requests.

Selvfølgelig ville man ikke kunne sende www.pokemontarget.com/changepassword.php?newpassword=1234 til ash sådan der, da han hurtigt ville finde linket mistænksomt. Men der er mange muligheder for at gemme sit link. F.eks kan man gemme det i billeder eller ved at videreredigere til linket når de besøger din side.
Man kan også lave et HTML IMG element.
<img src=”www.pokemontarget.com/changepassword.php?newpassword=1234”>

Her ville ash browser forsøge at loade billedet og sende forespørgslen og hans kodeord ville blive skiftet.
Dette er et meget simpelt eksempel. cPanel havde engang nogle CSRF sårbarheder(Se mere i ekstra referencer) der, hvis de var udnyttet korrekt, kunne lede til at udføre vilkårlige kommandoer. Dette er blot for at understrege at dette er en meget alvorlig sårbarhed.

I kan altid prøve at kigge rundt på sider og se hvordan det fungererer. I kan også kigge på hvordan MyBB håndterer det og laver unikke anmodninger. Det er selvfølgelig også tilladt at kigge dette forum igennem, så længe alle fundne sårbarheder rapporteres til admin :)



4. Ekstra referencer
Find alle beskeder fra denne bruger
Citer denne besked i et svar
19-03-2013, 12:38
#2
RE: [STUT] CSRF(Cross-Site Request Forgery)
Rigtig god guide! Har ikke hørt om CSRF før, men det lyder som en ond metode - især når det er slavens egen fejl der koster ham hans bruger. Tak for guiden! Keep it up! :)
"The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards." — Gene Spafford
Find alle beskeder fra denne bruger
Citer denne besked i et svar
23-03-2013, 01:47
#3
RE: [STUT] CSRF(Cross-Site Request Forgery)
Meget interessant læsning. Tak for det..
Don't learn to hack, hack to learn
Find alle beskeder fra denne bruger
Citer denne besked i et svar
13-04-2013, 20:35
#4
RE: [STUT] CSRF(Cross-Site Request Forgery)
Det er yderst sjældent jeg finder denne sårbarhed, men den er helt sikkert alvorlig. :)
Mange tak for læsningen.
Find alle beskeder fra denne bruger
Citer denne besked i et svar
14-04-2013, 11:34
#5
RE: [STUT] CSRF(Cross-Site Request Forgery)
Er der INGEN måde man kan gøre det på, hvis man skal indtaste sit nuværende password?
Find alle beskeder fra denne bruger
Citer denne besked i et svar
09-05-2013, 22:33
#6
RE: [STUT] CSRF(Cross-Site Request Forgery)
(14-04-2013, 11:34)Malmoc Skrev: Er der INGEN måde man kan gøre det på, hvis man skal indtaste sit nuværende password?

Tror desværre ikke det er muligt :/
Følg mig på twitter: https://twitter.com/Morph3s
Find alle beskeder fra denne bruger
Citer denne besked i et svar
22-05-2013, 20:10
#7
RE: [STUT] CSRF(Cross-Site Request Forgery)
Jeg vil lige gøre opmærksom på en upræcished i guiden:

I HTML-eksemplet er metoden POST frem for GET. Med POST kan man (normalt) ikke direkte linke til det på den måde, og man kan ikke sætte det ind i et billede.

Det betyder dog ikke at POST beskytter tilstrækkeligt, som en udbredt misforståelse fortæller - Man kan let forfalske en POST-forspørgsel, bl.a. ved at lave et HTML-dokument med formen.

Så vidt jeg forstod, da jeg satte mig ind i det for et års tid siden, er der 3 måder at beskytte imod det rimeligt effektivt:
1) At vedhæfte et unikt token, som angriberen ikke kan gætte sig til eller se.
2) At vedhæfte noget via JavaScript, som man ikke kan tilføje i URLen eller fra en form udenfor det angribende domæne. En cookie er så vidt jeg ved en af mulighederne, og så vidt jeg har forstået bruger Google noget andet header halløj.
3) At kræve password ved ændring.

Men derudover, super med opmærksomhed på CSRF. Det var en af de sidste begræber, jeg stødte på indenfor websikkerhed, og rigtig mange sider har problemer med det på POST-niveau, så vidt jeg ved.
Find alle beskeder fra denne bruger
Citer denne besked i et svar
23-05-2013, 01:49
#8
RE: [STUT] CSRF(Cross-Site Request Forgery)
(22-05-2013, 20:10)Mivalpuff Skrev: Jeg vil lige gøre opmærksom på en upræcished i guiden:

I HTML-eksemplet er metoden POST frem for GET. Med POST kan man (normalt) ikke direkte linke til det på den måde, og man kan ikke sætte det ind i et billede.

Det betyder dog ikke at POST beskytter tilstrækkeligt, som en udbredt misforståelse fortæller - Man kan let forfalske en POST-forspørgsel, bl.a. ved at lave et HTML-dokument med formen.

Så vidt jeg forstod, da jeg satte mig ind i det for et års tid siden, er der 3 måder at beskytte imod det rimeligt effektivt:
1) At vedhæfte et unikt token, som angriberen ikke kan gætte sig til eller se.
2) At vedhæfte noget via JavaScript, som man ikke kan tilføje i URLen eller fra en form udenfor det angribende domæne. En cookie er så vidt jeg ved en af mulighederne, og så vidt jeg har forstået bruger Google noget andet header halløj.
3) At kræve password ved ændring.

Men derudover, super med opmærksomhed på CSRF. Det var en af de sidste begræber, jeg stødte på indenfor websikkerhed, og rigtig mange sider har problemer med det på POST-niveau, så vidt jeg ved.

Havde ikke set at jeg havde brugt POST istedet for GET. Sorry :)
Men +1 for alt det andet. Du har helt ret :)
Følg mig på twitter: https://twitter.com/Morph3s
Find alle beskeder fra denne bruger
Citer denne besked i et svar
23-05-2013, 20:09 (Denne besked var sidst ændret: 23-05-2013, 20:15 af dagGi.)
#9
RE: [STUT] CSRF(Cross-Site Request Forgery)
referer headeren skal man aldrig stole på.
man plejer at løse det ved at lave en (unik) token til formen.
F.ex: <input type="hidden" name="token" value="somehash" />
det kan man kun bryde med et info leak (sjælden) eller en xss fejl (men xss giver også "fuld" client-side adgang, så det kan man ikke beskytte sig imod med security-by-design. der må man lære at filtrere sin inputs!)
Find alle beskeder fra denne bruger
Citer denne besked i et svar
« Ældre | Nyere »




User(s) browsing this thread: 1 Gæst(er)