Re: isKindofClass with NSData and NSKeyUnarchiver
Re: isKindofClass with NSData and NSKeyUnarchiver
- Subject: Re: isKindofClass with NSData and NSKeyUnarchiver
- From: Jens Alfke <email@hidden>
- Date: Fri, 28 May 2010 13:40:31 -0700
> On May 28, 2010, at 2:25 AM, Philip Vallone wrote:
>> This is a relative question, which depends on how the data is coming and going. My question comes from the following situation. Suppose I have a GKSession that is passing information via Bluetooth. The sender can send any type of information (NSString, UIImage etc...). The receiver needs to know how to handle this data. If there is a better way... Then how?
Wait, are you archiving and unarchiving data over a network? That’s a bad idea unless you’re extremely careful. The problem is that a malicious peer can send you an archive that expands into any codable object, not just the types you were expecting; this can be exploited to do Bad Things in your process, like crashing and possibly worse.
It would be safer and easier to send property lists instead. The property list decoder is safe in that it will only ever output a known set of classes. You just have to watch out that your code never takes type types of incoming data for granted, otherwise it can throw assertion failures if it gets the wrong data. So instead of
NSString *cmd = [message objectForKey: @“command”];
you have to do something like
id cmd = [message objectForKey: @“command”];
if (![cmd isKindOfClass: [NSString class]])
return NO; // reject the message as invalid
My MYUtilities library has a macro called $castIf that makes this really easy:
NSString *cmd = $castIf(NSString, [message objectForKey: @“command”]);
It returns nil if the object isn’t of the required class.
Yes, checking classes at runtime is often a bad-code smell. But it’s not avoidable when working with untrusted data and untyped data structures like plists. You have to code defensively on the assumption that any message you receive might be corrupt or malicious.
—Jens_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden