Cookie Tossing
Beskrywing
As 'n aanvaller 'n subdomein of die domein van 'n maatskappy kan beheer of 'n XSS in 'n subdomein vind, sal hy in staat wees om hierdie aanval uit te voer.
Soos aangedui in die Cookies Hacking afdeling, wanneer 'n cookie aan 'n domein (dit spesifiseer) gestel word, sal dit in die domein en subdomeine gebruik word.
Daarom, sal 'n aanvaller in staat wees om 'n spesifieke cookie aan die domein en subdomeine te stel deur iets soos document.cookie="session=1234; Path=/app/login; domain=.example.com"
Dit kan gevaarlik wees aangesien die aanvaller in staat mag wees om:
Die cookie van die slagoffer aan die aanvaller se rekening te fixe sodat as die gebruiker nie opgemerk nie, hy die aksies in die aanvaller se rekening sal uitvoer en die aanvaller mag interessante inligting verkry (kyk na die geskiedenis van die soeke van die gebruiker op die platform, die slagoffer mag sy kredietkaart in die rekening stel...)
As die cookie nie verander na aanmelding nie, kan die aanvaller net 'n cookie fixe (sessie-fiksasie), wag totdat die slagoffer aanmeld en dan daardie cookie gebruik om as die slagoffer aan te meld.
Soms, selfs al verander die sessie cookies, gebruik die aanvaller die vorige een en hy sal ook die nuwe een ontvang.
As die cookie 'n aanvanklike waarde stel (soos in flask waar die cookie die CSRF token van die sessie kan stel en hierdie waarde sal gehandhaaf word nadat die slagoffer aanmeld), kan die aanvaller hierdie bekende waarde stel en dit dan misbruik (in daardie scenario kan die aanvaller dan die gebruiker dwing om 'n CSRF versoek uit te voer aangesien hy die CSRF token ken).
Net soos om die waarde te stel, kan die aanvaller ook 'n nie-geoutentiseerde cookie wat deur die bediener gegenereer is, verkry, die CSRF token daaruit verkry en dit gebruik.
Cookie Bestelling
Wanneer 'n blaaiert twee cookies met dieselfde naam gedeeltelik die samelewing (domein, subdomeine en pad) beïnvloed, sal die blaaiert beide waardes van die cookie stuur wanneer albei geldig is vir die versoek.
Afhangende van wie die meest spesifieke pad het of watter een die oudste een is, sal die blaaiert eers die waarde van die cookie stel en dan die waarde van die ander een soos in: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
Meeste webwerwe sal net die eerste waarde gebruik. Dan, as 'n aanvaller 'n cookie wil stel, is dit beter om dit te stel voordat 'n ander een gestel word of dit met 'n meer spesifieke pad te stel.
Boonop is die vermoë om 'n cookie in 'n meer spesifieke pad te stel baie interessant aangesien jy die slagoffer kan laat werk met sy cookie behalwe in die spesifieke pad waar die kwaadwillige cookie gestel sal word.
Beskerming Bypass
Mogelijke beskerming teen hierdie aanval sou wees dat die webbediener nie versoeke met twee cookies met dieselfde naam maar twee verskillende waardes sal aanvaar nie.
Om die scenario te omseil waar die aanvaller 'n cookie stel nadat die slagoffer reeds die cookie ontvang het, kan die aanvaller 'n cookie oorgang veroorsaak en dan, sodra die legitieme cookie verwyder is, die kwaadwillige een stel.
Cookie Jar OverflowNog 'n nuttige bypass kan wees om die naam van die cookie URL te kodeer aangesien sommige beskermings kyk vir 2 cookies met dieselfde naam in 'n versoek en dan sal die bediener die name van die cookies dekodeer.
Cookie Bomb
'n Cookie Tossing aanval kan ook gebruik word om 'n Cookie Bomb aanval uit te voer:
Cookie BombVerdedigings
Gebruik die voorvoegsel __Host in die cookie naam
__Host in die cookie naamAs 'n cookie naam hierdie voorvoegsel het, sal dit net aanvaar word in 'n Set-Cookie riglyn as dit gemerk is as Veilig, van 'n veilige oorsprong gestuur is, nie 'n Domein attribuut insluit nie, en die Pad attribuut op / gestel is.
Dit voorkom dat subdomeine 'n cookie na die apex domein kan dwing aangesien hierdie cookies as "domein-geslote" beskou kan word.
Verwysings
Last updated
