[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSSecureCoding....
From: |
Matt Rice |
Subject: |
Re: NSSecureCoding.... |
Date: |
Sat, 9 Nov 2019 13:04:10 +0000 |
On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald
<richard@frithmacdonald.me.uk> wrote:
>
>
>
> > On 9 Nov 2019, at 11:40, Gregory Casamento <greg.casamento@gmail.com> wrote:
> >
> > Does anyone have any clue how we are going to tackle NSSecureCoding?
>
> I don't really understand it.
>
> The basic principle of it is simple: make hacking of archives by an attacker
> harder by preventing the attacker from substituting different classes into
> the archive.
>
> This uses a new -decodeObjectOfClass:forKey: method to decode objects of a
> specific class (easy to implement), plus a trivial method/property
> -supportsSecureCoding to say whether a class does secure coding or not.
>
> So the alterations are simple, but extensive and time consuming to implement
> (we'd need to retrofit/add this to decoding of most classes).
>
> My problem with it is that it's hard to see how it can work when it comes to
> collections ... yet the Apple documentation says that (for instance) NSSet
> supports secure coding.
> That should mean that an NSSet decodes its contents with
> -decodeObjectOfClass:forKey: specifying the class of each object the set
> holds.
> However, a set holds arbitrary values (any class), so presumably it would
> have to decode its contents using NSObject as the class, effectively that's
> the same as using -decodeObjectForKey: and allows unconstrained alteration of
> the set contents by an attacker, defeating the whole point of secure coding.
> It suggests to me that having arbitrary collection classes claim to implement
> NSSecureCoding would be misleading/wrong.
>
> So presumably I'm missing/misunderstanding something about this.
Weird problem, but interesting I suppose,
It looks like (according to this stack overflow)
https://stackoverflow.com/questions/24376746/nssecurecoding-trouble-with-collections-of-custom-class
if you use decodeObjectOfClasses:forKey: and the set of Class objects
passed to 'decodeObjectOfClasses:' contains *both* the collection
class,
and the classes of the objects which form the contents, it seems like
you can limit it to a specific set of 'subject' classes...