[STUT] CSRF (Cross-Site Request Forgery)
|
23-02-2013, 15:21
(Denne besked var sidst ændret: 28-05-2013, 00:38 af Doctor Blue.)
|
|||
|
|||
[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 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:
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 |
|||
19-03-2013, 12:38
|
|||
|
|||
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
|
|||
23-03-2013, 01:47
|
|||
|
|||
RE: [STUT] CSRF(Cross-Site Request Forgery)
Meget interessant læsning. Tak for det..
Don't learn to hack, hack to learn
|
|||
13-04-2013, 20:35
|
|||
|
|||
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. |
|||
14-04-2013, 11:34
|
|||
|
|||
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?
|
|||
09-05-2013, 22:33
|
|||
|
|||
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
|
|||
22-05-2013, 20:10
|
|||
|
|||
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. |
|||
23-05-2013, 01:49
|
|||
|
|||
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: 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
|
|||
23-05-2013, 20:09
(Denne besked var sidst ændret: 23-05-2013, 20:15 af dagGi.)
|
|||
|
|||
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!) |
|||
|
User(s) browsing this thread: 1 Gæst(er)