一文详解NSSecureCoding真的安全吗

NSSecureCoding NSSecureCoding 可能很多人都没用过,但是 NSCoding 大家应该都不陌生;你可以简单的理解为 NSSecureC

NSSecureCoding

NSSecureCoding 可能很多人都没用过,但是 NSCoding 大家应该都不陌生;你可以简单的理解为 NSSecureCodingNSCoding 的安全版本。

为什么 NSSecureCodingNSCoding 更安全呢?如果你上网搜索这2者的区别,大部分的回答都是 NSSecureCodingNSCoding 更安全,为什么更安全呢?没说(每次看到这类博主的回答真的很无语,NSSecureCoding 比 NSCoding 更安全还用你说吗?单词都能看出来,既然发一篇文章来说明那起码得解释为什么更安全吧。)。

在说 NSSecureCoding 之前,我们先回忆一下 NSCoding 的用法。

NSCoding的用法

@interface Person : NSObject<NSCoding>
@property (nonatomic, copy) NSString *name;
@end
@implementation Person
- (instancetype)initWithCoder:(NSCoder *)coder {
    self = [super init];
    if (!self) return nil;
    self.name = [coder decodeObjectForKey:@"name"];
    return self;
}
- (void)encodeWithCoder:(nonnull NSCoder *)coder {
    [coder encodeObject:self.name forKey:@"name"];
}
@end

第1步遵守 NSCoding 协议,第2步实现协议内的 initWithCoder:encodeWithCoder: 这2个方法。

使用代码如下:

Person *per = [[Person alloc] init];
per.name = @"name1";
NSData *archiver = [NSKeyedArchiver archivedDataWithRootObject:per];
Person *per2 = [NSKeyedUnarchiver unarchiveObjectWithData:archiver];

利用 NSKeyedArchiver 的 archivedDataWithRootObject: 类方法进行归档,使用 NSKeyedUnarchiver 的 unarchiveObjectWithData: 类方法进行解档。

是不是很简单,我们再来看看 NSSecureCoding 的用法。

NSSecureCoding的用法

@interface Person : NSObject&lt;NSSecureCoding&gt;
@property (nonatomic, copy) NSString *name;
@end
@implementation Person
- (instancetype)initWithCoder:(NSCoder *)coder {
    self = [super init];
    if (!self) return nil;
    self.name = [coder decodeObjectOfClass:NSString.class forKey:@"name"];
    return self;
}
- (void)encodeWithCoder:(nonnull NSCoder *)coder {
    [coder encodeObject:self.name forKey:@"name"];
}
+ (BOOL)supportsSecureCoding {
    return YES;
}
@end

除了把协议名从 NSCoding 换成了 NSSecureCoding,主要增加了一个类方法 supportsSecureCoding(如果你遵守了NSSecureCoding协议的话,那么这个方法必须返回YES),还有解档方法从 decodeObjectForKey: 换成了 decodeObjectOfClass:forKey:

使用代码如下:

Person *per = [[Person alloc] init];
per.name = @"name1";
NSData *archiver = [NSKeyedArchiver archivedDataWithRootObject:per requiringSecureCoding:YES error:nil];
Person *per2 = [NSKeyedUnarchiver unarchivedObjectOfClass:Person.class fromData:archiver error:nil];

归档方法由 archivedDataWithRootObject: 改成了 archivedDataWithRootObject:requiringSecureCoding:error:,解档方法由 unarchiveObjectWithData: 改成了 unarchivedObjectOfClass:fromData:error:

从整体上来看 NSSecureCodingNSCoding 其实就多了1个Class类型的参数,安全性也体现在这个参数上。

你可以从这篇文档上获得 NSSecureCoding 的详细描述:developer.apple.com/documentati…

简单总结一下就是在使用 NSCoding 协议时,你需要先解码然后才能判断类型是否正确,代码如下:

id obj = [decoder decodeObjectForKey:@"myKey"];
if (![obj isKindOfClass:[MyClass class]]) { /* ...fail... */ }

这样做有很多缺点,首先你在验证类型的时候,这个对象已经构造完成了,如果这是一个集合类的话,那么这个对象可能已经插入到集合中了,如果类型不准确可能还需要移除;这样效率会很低。

NSSecureCoding 的做法就是把 Class 作为参数传递进去,Apple会在解码前验证类型是否一致。

看起来 NSSecureCoding 确实比 NSCoding 更安全了,但是它却有一个致命的缺点。

NSSecureCoding的致命缺点

我们把数据存储到本地的时候,自然也希望下次读取的是上次我们存储的值,而不是一个被修改过的值,我在测试 NSSecureCoding 的时候,发现归档文件居然能被篡改,而且程序还能正常读取到被篡改后的值而没有任何异常,当然,这个问题 NSCoding 同样也有。

具体过程如下:

NSData *archiver = [NSKeyedArchiver archivedDataWithRootObject:per requiringSecureCoding:YES error:nil];
[archiver writeToFile:@"/archiver" atomically:YES];

第一步将归档数据保存到本地。

这是我保存到本地后的文件 archiver,正常情况下确实不管用什么软件要么打开失败要么乱码,但是如果你把文件后缀改为 .plist 的话,然后用Xcode打开就能看到文件的大致信息,具体包含类名、父类、属性名以及属性值,如下图所示:

掌握了类名、属性名之后,攻击者只需要模仿它创建1个和它同名的类,然后随意修改属性值,保存为归档文件后替换APP路径下的归档文件,就可以达到修改APP内数据的目的。

我在本地测试了一下,确实可以用这种方式修改APP内部数据。

结语

当然,我这里的Model比较简单,现实情况下Model可能会嵌套Model甚至更复杂,我没有测试这些更复杂的情况;不过还是想提醒一下大家,如果是保存一些敏感或重要数据,建议采用加密或其他方式。

吐槽一下:Apple为什么不在归档的时候把APP的唯一信息包含进去(例如包名等等),然后在解码之前先验证一下;然后再把.plist后缀这个问题修复一下,我可能会考虑使用它。

以上就是一文详解NSSecureCoding真的安全吗的详细内容,更多关于NSSecureCoding安全解析的资料请关注好代码网其它相关文章!

您可能有感兴趣的文章
Swift好代码教程之集合类型详解

Swift好代码教程之控制流详解

Swift好代码教程之基本运算符详解

深入理解Swift语言中的闭包机制

Swift好代码教程之基础数据类型详解