Cookie Tossing

Reading time: 5 minutes

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.

Dit kan gevaarlik wees aangesien die aanvaller dalk in staat is 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...)
• 'n Voorbeeld hiervan kan hier gevind word waar die aanvaller sy cookie in spesifieke afdelings stel wat 'n slagoffer sal gebruik om toegang tot sy git repos te autoriseer, maar vanaf die aanvaller se rekening aangesien hy sy koekies in die nodige eindpunte sal stel.
• As die cookie nie verander na aanmelding nie, kan die aanvaller net 'n cookie fixe (session-fixation), wag totdat die slagoffer aanmeld en dan daardie cookie gebruik om as die slagoffer aan te meld.
• Soms, selfs al verander die sessie koekies, 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 mag 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 koekies met dieselfde naam ontvang wat gedeeltelik die dieselfde omvang beïnvloed (domein, subdomeine en pad), sal die blaaiert beide waardes van die cookie stuur wanneer albei geldig is vir die versoek.

Afhangende van wie die mees 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.

Beskerming Bypass

Moglike beskerming teen hierdie aanval sou wees dat die webbediener nie versoeke met twee koekies 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 overflow veroorsaak en dan, sodra die legitieme cookie verwyder is, die kwaadwillige een stel.

Cookie Jar Overflow

Nog 'n nuttige bypass kan wees om die naam van die cookie URL te kodeer aangesien sommige beskermings vir 2 koekies met dieselfde naam in 'n versoek kyk en dan die bediener die name van die koekies sal dekodeer.

Cookie Bomb

'n Cookie Tossing aanval kan ook gebruik word om 'n Cookie Bomb aanval uit te voer:

Cookie Bomb

Verdedigings

Gebruik die voorvoegsel __Host in die cookie naam

• As 'n cookie naam hierdie voorvoegsel het, sal dit slegs aanvaar word in 'n Set-Cookie riglyn as dit as Secure gemerk is, 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 aan die apex domein kan afdwing aangesien hierdie koekies as "domein-gesluit" beskou kan word.

Verwysings

• @blueminimal
• https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers
• https://github.blog/2013-04-09-yummy-cookies-across-domains/
• Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities