The list of things which the collection classes decode automagically is pretty small, limited I think to the primitives in XML/Binary document. But yes you can craft a document with an NSArray in it and subtypes and that will be decoded into strings and numbers. That means if you use NSArray() or other collection classes directly in your coding, you need to check what you got back. They are ‘securely’ decoded to the extent that Apple believes decoding them will not result in a buffer overflow etc, that’s all you get by default. Having found the guide I was looking for (“Working with Custom Classes” in the ‘Daemon and Services’ programming guide) you can see what NSSecureCoding was designed for and it’s not a stretch to understand why foundation classes were automatically whitelisted.
So your alternative, if you know what you want, is not to do that but to encode/decode the data yourself according to the rules you have. Just because you have an array in your object doesn’t mean you have to use the default array encoder, you can encode it as ‘count’ plus ‘object_0’, ‘object_1’ etc etc and you can specify the exact class for that object when you read it back in. If you implement your own logic all the way down you can make it as secure as you like, just don’t use the collection classes automatic encode/decode support. > On 16 Jul 2015, at 10:17, André Francisco <andre.frate...@hotmail.com> wrote: > > (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: r...@rols.org <mailto:r...@rols.org> > > Date: Thu, 16 Jul 2015 09:49:24 +0800 > > CC: cocoa-dev@lists.apple.com <mailto:cocoa-dev@lists.apple.com> > > To: andre.frate...@hotmail.com <mailto:andre.frate...@hotmail.com> > > > > > > > On 16 Jul 2015, at 08:30, André Francisco <andre.frate...@hotmail.com> > > > 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
