Koekie 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 Koekie Hacking afdeling, wanneer 'n koekie aan 'n domein (wat 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 koekie van die slagoffer aan die aanvaller se rekening te fixe sodat as die gebruiker nie oplet nie, hy die aksies in die aanvaller se rekening sal uitvoer en die aanvaller mag interessante inligting verkry (kyk na die geskiedenis van die gebruiker se soektogte op die platform, die slagoffer mag sy kredietkaart in die rekening stel...)
• As die koekie nie verander na aanmelding nie, kan die aanvaller net 'n koekie fixe (sessie-fixasie), wag totdat die slagoffer aanmeld en dan daardie koekie gebruik om as die slagoffer aan te meld.
• Soms, selfs al verander die sessie koekies, gebruik die aanvaller die vorige een en sal hy ook die nuwe een ontvang.
• As die koekie 'n aanvanklike waarde stel (soos in flask waar die koekie 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-geverifieerde koekie wat deur die bediener gegenereer is, verkry, die CSRF-token daaruit haal en dit gebruik.

Koekie Bestelling

Wanneer 'n blaaier twee koekies met dieselfde naam ontvang wat gedeeltelik die same scope (domein, subdomeine en pad) beïnvloed, sal die blaaier albei waardes van die koekie 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 blaaier eers die waarde van die koekie 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 koekie 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 Omseiling

Mogelijke 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 koekie stel nadat die slagoffer reeds die koekie ontvang het, kan die aanvaller 'n koekie oorgang veroorsaak en dan, sodra die legitieme koekie verwyder is, die kwaadwillige een stel.

Cookie Jar Overflow

Nog 'n nuttige omseiling kan wees om die naam van die koekie 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.

Koekie Bom

'n Koekie Tossing aanval kan ook gebruik word om 'n Koekie Bom aanval uit te voer:

Cookie Bomb

Verdedigings

Gebruik die voorvoegsel __Host in die koekie naam

• As 'n koekie 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 koekie aan die apex domein kan afdwing aangesien hierdie koekies as "domein-geslote" 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/
• Koekies Krummel: Ontsluiting van Web Sessie Integriteit Kw vulnerabilities