RE: NSSecureCoding with containers (or, is NSArray lying?)
RE: NSSecureCoding with containers (or, is NSArray lying?)
- Subject: RE: NSSecureCoding with containers (or, is NSArray lying?)
- From: André Francisco <email@hidden>
- Date: Thu, 16 Jul 2015 02:17:41 +0000
- Importance: Normal
(I'm new to the mailing list and I'm not sure whether I should reply just to Roland or everyone. Please correct me if I'm doing this wrong. I'm replying to both)
This seems far from ideal, and I'm actually surprised about NSArray's behaviour. The fact that it decodes a set of classes known to implement NSSecureCoding is wrong, IMO, for two reasons. Actually three, but I forgot about the last one while typing :)
1) The fact that the contained class implements NSSecureCoding does not mean that I'm expecting it. By what I understand from what you are saying, I can encode an array of NSString's and get NSNumber's back (ie., a substitution attack). It's not just about NSString being securely encoded, I must be expecting strings. This can easily crash an app if I get a type that I'm not expecting, even if it implements NSSecureCoding.
2) It limits the classes which can be stored. I guess this could be easily fixed with inspection. Does the class that I'm decoding implement NSSecureCoding? The result would pretty much be the same, just not limited to Apple's subset. I could encode arrays of my own objects.
Anyway, based on all my research, SO comments, and especially this conversation, I have been becoming more and more convinced that there doesn't exists a real solution. NSSecureCoding doesn't seem so secure anymore :\
> Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
> From: email@hidden
> Date: Thu, 16 Jul 2015 09:49:24 +0800
> CC: email@hidden
> To: email@hidden
>
>
> > On 16 Jul 2015, at 08:30, André Francisco <email@hidden> wrote:
> >
> > Hi all,
> > I posted a question at SO (http://stackoverflow.com/questions/31307331/how-to-use-nssecurecoding-with-id-objects) and despite the bounty it still didn't get any answers. I am not confident that it will either.
> > The problem is when implementing NSSecureCoding with a collection (or container) given that the type of contained objects is not known. I would assume that secure coding is not possible in this situation. However, classes such as NSArray do implement NSSecureCoding, so as I stated earlier, either there's a work around or NSArray is lying.
> > I've been putting some effort into this issue in the last few days, so far with no success. But it's been boggling me. So which one is it, can containers/collections implement actual secure coding?
> > Best to you all,André.
> > _______________________________________________
>
>
> I’m sure there used to be an SDK guide about this but I can’t find it and Google can’t find it. It included a section on how container types worked with NSSecureCoding. It was in the XPC section I thought.
>
> Anyway they do work. Try it. Make an NSArray of normal stuff, like NSString, NSNumber, encode it, decode it with decodeObjectForClasses, with no classes. You’ll fail on the array. Add the NSArray to the list of allowed classes and .. it works. So, you think, NSArray will blindly decode anything so it’s no-longer secure.
>
> Add an object of a custom class which implements secure coding into the array, and it will start failing again. NSArray, and the other collection types, allow elements of known secure system types, like NSString, but fail at anything outside that. You have to add all the custom classes you will have in any of the collections at any level into your decodeObjectWithClasses() list before the collection classes will work.
>
> Hence, as long as you know all the possible things which could be encoded in your list and they all support secure coding and you list them all in your decode code, you’re fine. That’s really the point, your code says what objects it expects/will accept and that enforces the secure aspect all the way down as you can’t have a class you didn’t expect and every one of the classes you do expect will be securely decoded.
_______________________________________________
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