这篇文章主要介绍“NSSecureCoding是否真的安全”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“NSSecureCoding是否真的安全”文章能帮助大家解决问题。
NSSecureCoding 可能很多人都没用过,但是 NSCoding 大家应该都不陌生;你可以简单的理解为 NSSecureCoding 是 NSCoding 的安全版本。
在说 NSSecureCoding 之前,我们先回忆一下 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 的用法。
@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]]) { /* ...fail... */ }
这样做有很多缺点,首先你在验证类型的时候,这个对象已经构造完成了,如果这是一个集合类的话,那么这个对象可能已经插入到集合中了,如果类型不准确可能还需要移除;这样效率会很低。
NSSecureCoding 的做法就是把 Class 作为参数传递进去,Apple会在解码前验证类型是否一致。
看起来 NSSecureCoding 确实比 NSCoding 更安全了,但是它却有一个致命的缺点。
我们把数据存储到本地的时候,自然也希望下次读取的是上次我们存储的值,而不是一个被修改过的值,我在测试 NSSecureCoding 的时候,发现归档文件居然能被篡改,而且程序还能正常读取到被篡改后的值而没有任何异常,当然,这个问题 NSCoding 同样也有。
具体过程如下:
NSData *archiver = [NSKeyedArchiver archivedDataWithRootObject:per requiringSecureCoding:YES error:nil]; [archiver writeToFile:@"/archiver" atomically:YES];
第一步将归档数据保存到本地。
这是我保存到本地后的文件 archiver
,正常情况下确实不管用什么软件要么打开失败要么乱码,但是如果你把文件后缀改为 .plist 的话,然后用Xcode打开就能看到文件的大致信息,具体包含类名、父类、属性名以及属性值,如下图所示:
掌握了类名、属性名之后,攻击者只需要模仿它创建1个和它同名的类,然后随意修改属性值,保存为归档文件后替换APP路径下的归档文件,就可以达到修改APP内数据的目的。
我在本地测试了一下,确实可以用这种方式修改APP内部数据。
关于“NSSecureCoding是否真的安全”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注亿速云行业资讯频道,小编每天都会为大家更新不同的知识点。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。