Re: isKindofClass with NSData and NSKeyUnarchiver
Re: isKindofClass with NSData and NSKeyUnarchiver
- Subject: Re: isKindofClass with NSData and NSKeyUnarchiver
- From: Philip Vallone <email@hidden>
- Date: Fri, 28 May 2010 19:40:04 -0400
Hi,
> 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.
How is it possible using GKSession to be introduced to a malicious peer.? I am creating a GKSession object and connecting via GKPeerPickerController. A hand shack is made between the the two peers. Once both peers accept the connection, the session is stored along with the peer id. This information can be checked before any information is received. Isn't this secure enough?
Thanks,
Phil
On May 28, 2010, at 4:40 PM, Jens Alfke wrote:
>
>> 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