[asp.net] serialize object to cookie en security

[AB.NET]

Ik heb een dictionairy object opgeslagen in een cookie door hem te serializen.

Nu kan een client dit object natuurlijk aanpassen door de cookie te bewerken. Hierdoor zou het object ander waardes kunnen krijgen. Dit is geen probleem in mijn toepassing.

Kunnen er nog andere security problemen opduiken tijdens het deserializen door dat er op de client met de/het cookie is gerommeld.


en offtopic vraag 2: is het de cookie of het cookie

[Gerco]

Alle eventuele problemen die kunnen optreden komen doordat de client de inhoud van je cookie kan aanpassen. Als je 100% zeker weet dat dit geen security problemen kan opleveren (waarom heb je de cookie dan?) is het mogelijk veilig.

Bedenk je overigens wel dat het voor de client ook mogelijk is om een heel ander object in de cookie te zetten dan jij erin gestopt hebt. Afhankelijk van je deserialisatiecode kan dat natuurlijk een probleem zijn.

Je kan nog een hash van de gegevens plus een salt toevoegen in de cookie om te kunnen controleren of de gebruiker het cookie gewijzigd heeft, dan ben je er gelijk vanaf. Een andere optie is om je serialized data te encrypten en dan in de cookie te zetten. De cookie is dan betekenisloos voor de client, maar je server kan het nog wel lezen.

[ Voor 33% gewijzigd door Gerco op 14-08-2009 13:13 ]

[roy-t]

moeilijk bij engelse woorden, maar zelf vind ik het cookie mooier

[gorgi_19]

Encrypted cookie is een mogelijkheid, maar wat wil je uiteindelijk bereiken?

[AB.NET]

Ok, een voorbeeld praat makkelijker.

Stel ik serialize de inhoud van een winkelmandje naar een cookie. Als de client het cookie gaat aanpassen, krijgt hij andere producten in zijn winkelmandje. Big deal, geen security problemen.

Kan de client de cookie zo aanpassen dat ik op de server een exception krijg tijdens het deserializen, compleet andere objecten terugkrijg, of zelfs code kan laten uitvoeren.

Mijn vermoeden is dat alleen die inhoudt van het object kan worden aangepast. Maar het lijkt me niet verstandig om security beslissingen te baseren op alleen mijn vermoeden.

Een encrypted cookie is natuurlijk een optie, maar in dit geval niet nodig. Ik wil graag weten wat de mogelijke problemen zijn, en daar rekening mee houden, lijkt me verstandiger als alles maar te encrypten zonder te weten wat de risico's zijn.

[ Voor 17% gewijzigd door AB.NET op 14-08-2009 13:27 ]

[Gerco]

AB.NET schreef op vrijdag 14 augustus 2009 @ 13:25:
Kan de client de cookie zo aanpassen dat ik op de server een exception krijg tijdens het deserializen, compleet andere objecten terugkrijg, of zelfs code kan laten uitvoeren.

Natuurlijk kan dat (een exception forceren of een ander type object in de cookie zetten). Of dat een probleem is is natuurlijk niet zomaar te zeggen zonder je code te kennen. Code uitvoeren is misschien ook mogelijk, afhankelijk van wat er op je server staat en of daar een eval() achtige functie beschikbaar is.

[ Voor 6% gewijzigd door Gerco op 14-08-2009 13:43 ]

[Verwijderd]

Zou het geen beter idee zijn om de inhoud van een winkelmandje aan de kant van de server te houden, zodat je geen rekening hoeft te houden met manipulatie en bij het inladen van de pagina het winkelmandje van de gebruiker weer in te lezen in de huidige sessie?

[jmzeeman]

Wat er mogelijk is is afhankelijk van wat je serialized en welke serializer je daar voor gebruikt. Voor alle gevallen geldt dat alleen de inhoud van een object kan worden gedeserialized, er kan geen code worden toegevoegd. Wel kunnen er in sommige situaties (afhankelijk van de serializer die je gebruikt) andere objecten worden aangemaakt als je zou verwachten. Maar ik zou geen enkele klasse weten die alleen door aangemaakt te worden iets gevaarlijks kan doen.

Als je een generic dictionary gebruikt en hem deserialized met een XmlSerializer die je initialiseert met het type van de generic dictionary kan er niks anders worden geserialized als de objecten die jij wil.

[Woy]

jmzeeman schreef op maandag 17 augustus 2009 @ 13:51:
Wat er mogelijk is is afhankelijk van wat je serialized en welke serializer je daar voor gebruikt. Voor alle gevallen geldt dat alleen de inhoud van een object kan worden gedeserialized, er kan geen code worden toegevoegd. Wel kunnen er in sommige situaties (afhankelijk van de serializer die je gebruikt) andere objecten worden aangemaakt als je zou verwachten. Maar ik zou geen enkele klasse weten die alleen door aangemaakt te worden iets gevaarlijks kan doen.

Als je een generic dictionary gebruikt en hem deserialized met een XmlSerializer die je initialiseert met het type van de generic dictionary kan er niks anders worden geserialized als de objecten die jij wil.

Er zijn wel situaties denkbaar dat er wat ongewenst kan gebeuren, maar met een klein beetje controle zal dat wel meevallen.

Stel dat je winkelwagen een Start methode ( ja ik weet het, dat is niet echt logisch ) hebt die je via reflection aanroept, dan kan een kwaadwillende zorgen dat er in plaats van een Winkelwagen object een Process object aangemaakt word, en dus iets op je server uitvoeren. Met een simpele controle of je wel een Winkelwagen object gedeserialised hebt is dat probleem al weer verholpen ( Of je moet ook nog een EvilWinkelwagenFromHell class hebben ), want het deserialisatie proces zelf zal inderdaad geen code uitvoeren.

[Voutloos]

De aanpak van D32 verdient imo de voorkeur. Eenvoudiger, veiliger en je kan nog wat stats over je winkelmandjes verzinnen.

[jmzeeman]

Woy schreef op maandag 17 augustus 2009 @ 13:56:
[...]

Er zijn wel situaties denkbaar dat er wat ongewenst kan gebeuren, maar met een klein beetje controle zal dat wel meevallen.

Stel dat je winkelwagen een Start methode ( ja ik weet het, dat is niet echt logisch ) hebt die je via reflection aanroept, dan kan een kwaadwillende zorgen dat er in plaats van een Winkelwagen object een Process object aangemaakt word, en dus iets op je server uitvoeren. Met een simpele controle of je wel een Winkelwagen object gedeserialised hebt is dat probleem al weer verholpen ( Of je moet ook nog een EvilWinkelwagenFromHell class hebben ), want het deserialisatie proces zelf zal inderdaad geen code uitvoeren.

Ik wist dat ik er bij moest zetten "Tenzij je zelf zo'n klasse schrijft". Ik weet er zelf ook nog wel een: een object met een memorystream als property die in zijn eigen code voor elke actie de memorystream via reflection als assembly laad en vervolgens deze code aanroept.

Het punt is dat je altijd zelf de code moet hebben toegevoegd die iets evils mogelijk maakt. Zo lang je gewoon normale dingen in je winkelwagentje/product klassen stopt zoals producten, aantallen en namen kan er niks gebeuren.

[Woy]

jmzeeman schreef op maandag 17 augustus 2009 @ 14:06:
[...]


Ik wist dat ik er bij moest zetten "Tenzij je zelf zo'n klasse schrijft". Ik weet er zelf ook nog wel een: een object met een memorystream als property die in zijn eigen code voor elke actie de memorystream via reflection als assembly laad en vervolgens deze code aanroept.

Het punt is dat je altijd zelf de code moet hebben toegevoegd die iets evils mogelijk maakt. Zo lang je gewoon normale dingen in je winkelwagentje/product klassen stopt zoals producten, aantallen en namen kan er niks gebeuren.

Mijn eerste voorbeeld is nog niet eens zo gek bedacht.

C#:

object deserialized = DeserializeObject();
deserialized.GetType().GetMethod( "Run" ).Invoke( deserialized, null );

Ik zou het geen goede code willen noemen, maar kan me zomaar voorstellen dat er mensen zijn die dit soort dingen doen. Het is niet voor niks dat er zo vaak topics zijn met de strekking: "Is er in taal x ook een Eval".

[matthijsln]

Een cookie is trouwens max 4k, lijkt me dat je daar zo overheen zit (ik neem aan dat je ook nog iets als base64 encoding gebruikt...). En het kost ook elke keer weer netwerkverkeer bij elk request.

Zulke dingen sla je gewoon op in je sessie, server side.