NSSecureCoding是否真的安全

这篇文章主要介绍“NSSecureCoding是否真的安全”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“NSSecureCoding是否真的安全”文章能帮助大家解决问题。

NSSecureCoding 可能很多人都没用过，但是 NSCoding 大家应该都不陌生；你可以简单的理解为 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<NSSecureCoding>@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:。

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

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

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

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

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

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内部数据。

关于“NSSecureCoding是否真的安全”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注编程网行业资讯频道，小编每天都会为大家更新不同的知识点。