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 hierdie aanval kan uitvoer.
Soos aangedui is in die Koekies Hakafdeling, wanneer 'n koekie na 'n domein ingestel word (dit spesifiseer), sal dit in die domein en subdomeine gebruik word.
Daarom sal 'n aanvaller in staat wees om 'n spesifieke koekie na die domein en subdomeine te stuur deur iets soos document.cookie="session=1234; Path=/app/login; domain=.example.com"
Dit kan gevaarlik wees omdat die aanvaller dalk in staat sal wees om:
Die koekie van die slagoffer na die aanvaller se rekening te fikseer sodat as die gebruiker nie agterkom nie, sal hy die aksies in die aanvaller se rekening uitvoer en die aanvaller mag interessante inligting verkry (kyk na die geskiedenis van die soektogte van die gebruiker 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 fikseer (sessie-fiksasie), wag totdat die slagoffer aanmeld en dan daardie koekie gebruik om aan te meld as die slagoffer.
Soms, selfs as die sessiekoekies verander, kan die aanvaller die vorige een gebruik en hy sal ook die nuwe een ontvang.
As die koekie 'n aanvanklike waarde instel (soos in flask waar die koekie die CSRF-token van die sessie kan instel en hierdie waarde sal behou word nadat die slagoffer aanmeld), kan die aanvaller hierdie bekende waarde instel en dit dan misbruik (in daardie scenario kan die aanvaller dan die gebruiker 'n CSRF-versoek laat uitvoer omdat hy die CSRF-token ken).
Net soos die waarde instel, kan die aanvaller ook 'n ongeverifieerde koekie wat deur die bediener gegenereer is, kry, die CSRF-token daaruit kry en dit gebruik.
Koekie Volgorde
Wanneer 'n webblaaier twee koekies met dieselfde naam ontvang wat gedeeltelik dieselfde omvang beïnvloed (domein, subdomeine en pad), sal die blaaier beide waardes van die koekie stuur wanneer beide geldig is vir die versoek.
Afhanklik van wie die spesifiekste pad het of watter een die oudste een is, sal die blaaier die waarde van die koekie eerste instel en dan die waarde van die ander een soos in: Cookie: iduser=MeerSpesifiekEnOuderKoekie; iduser=MinderSpesifiek;
Meeste webwerwe sal net die eerste waarde gebruik. Dus, as 'n aanvaller 'n koekie wil instel, is dit beter om dit in te stel voordat 'n ander een ingestel word of om dit met 'n meer spesifieke pad in te stel.
Verder is die vermoë om 'n koekie in 'n meer spesifieke pad in te stel baie interessant omdat jy die slagoffer in staat sal stel om met sy koekie te werk behalwe in die spesifieke pad waar die bose koekie ingestel sal word voordat dit gestuur word.
Beskerming deurloop
Moontlike beskerming teen hierdie aanval sou wees dat die webbediener nie versoek met twee koekies met dieselfde naam maar twee verskillende waardes sal aanvaar nie.
Om die scenario te deurloop waar die aanvaller 'n koekie instel nadat die slagoffer reeds die koekie ontvang het, kan die aanvaller 'n koekie-oorvloed veroorsaak en dan, sodra die wettige koekie uitgevee is, die bose een instel.
pageCookie Jar Overflow'n Ander nuttige deurloop kan wees om die naam van die koekie URL-kodeer aangesien sommige beskermings vir 2 koekies met dieselfde naam in 'n versoek sal kyk en dan sal die bediener die name van die koekies ontkodeer.
Koekiebom
'n Koekie Gooi-aanval kan ook gebruik word om 'n Koekiebom-aanval uit te voer:
pageCookie BombVerdediginge
Gebruik die voorvoegsel __Host in die koekienaam
__Host in die koekienaamAs 'n koekienaam hierdie voorvoegsel het, sal dit slegs aanvaar word in 'n Set-Cookie-aanwysing as dit gemerk is as Veilig, van 'n veilige oorsprong af gestuur is, nie 'n Domeinatribuut insluit nie, en die Padatribuut op / ingestel is
Dit voorkom dat subdomeine 'n koekie na die apex-domein dwing aangesien hierdie koekies as "domein-gesluit" beskou kan word
Verwysings
Last updated