有微澜的夜 發表於 2023-3-31 14:21:51

一文详解NSSecureCoding真的安全吗

<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li>NSSecureCoding</li><ul class="second_class_ul"><li>NSCoding的用法</li><li>NSSecureCoding的用法</li><li>NSSecureCoding的致命缺点</li></ul><li>结语</li><ul class="second_class_ul"></ul></ul></div><p class="maodian"></p><h2>NSSecureCoding</h2>
<p><strong>NSSecureCoding</strong> 可能很多人都没用过，但是 <strong>NSCoding</strong> 大家应该都不陌生；你可以简单的理解为 <strong>NSSecureCoding</strong> 是 <strong>NSCoding</strong> 的安全版本。</p>
<p>为什么 <strong>NSSecureCoding</strong> 比 <strong>NSCoding</strong> 更安全呢？如果你上网搜索这2者的区别，大部分的回答都是 <strong>NSSecureCoding</strong> 比 <strong>NSCoding</strong> 更安全，为什么更安全呢？没说(每次看到这类博主的回答真的很无语，NSSecureCoding 比 NSCoding 更安全还用你说吗？单词都能看出来，既然发一篇文章来说明那起码得解释为什么更安全吧。)。</p>
<p>在说 <strong>NSSecureCoding</strong> 之前，我们先回忆一下 <strong>NSCoding</strong> 的用法。</p>
<p class="maodian"></p><h3>NSCoding的用法</h3>
<div class="jb51code"><pre class="brush:cpp;">@interface Person : NSObject&lt;NSCoding&gt;
@property (nonatomic, copy) NSString *name;
@end
@implementation Person
- (instancetype)initWithCoder:(NSCoder *)coder {
    self = ;
    if (!self) return nil;
    self.name = ;
    return self;
}
- (void)encodeWithCoder:(nonnull NSCoder *)coder {
    ;
}
@end
</pre></div>
<p>第1步遵守 <strong>NSCoding</strong> 协议，第2步实现协议内的 <code>initWithCoder:</code> 和 <code>encodeWithCoder:</code> 这2个方法。</p>
<p>使用代码如下：</p>
<div class="jb51code"><pre class="brush:cpp;">Person *per = [ init];
per.name = @"name1";
NSData *archiver = ;
Person *per2 = ;
</pre></div>
<p>利用 NSKeyedArchiver 的 <code>archivedDataWithRootObject:</code> 类方法进行归档，使用 NSKeyedUnarchiver 的 <code>unarchiveObjectWithData:</code> 类方法进行解档。</p>
<p>是不是很简单，我们再来看看 <strong>NSSecureCoding</strong> 的用法。</p>
<p class="maodian"></p><h3>NSSecureCoding的用法</h3>
<div class="jb51code"><pre class="brush:cpp;">@interface Person : NSObject&amp;lt;NSSecureCoding&amp;gt;
@property (nonatomic, copy) NSString *name;
@end
@implementation Person
- (instancetype)initWithCoder:(NSCoder *)coder {
    self = ;
    if (!self) return nil;
    self.name = ;
    return self;
}
- (void)encodeWithCoder:(nonnull NSCoder *)coder {
    ;
}
+ (BOOL)supportsSecureCoding {
    return YES;
}
@end
</pre></div>
<p>除了把协议名从 <strong>NSCoding</strong> 换成了 <strong>NSSecureCoding</strong>，主要增加了一个类方法 <code>supportsSecureCoding</code>(<code>如果你遵守了NSSecureCoding协议的话，那么这个方法必须返回YES</code>)，还有解档方法从 <code>decodeObjectForKey:</code> 换成了 <code>decodeObjectOfClass:forKey:</code>。</p>
<p>使用代码如下：</p>
<div class="jb51code"><pre class="brush:cpp;">Person *per = [ init];
per.name = @"name1";
NSData *archiver = ;
Person *per2 = ;
</pre></div>
<p>归档方法由 <code>archivedDataWithRootObject:</code> 改成了 <code>archivedDataWithRootObject:requiringSecureCoding:error:</code>，解档方法由 <code>unarchiveObjectWithData:</code> 改成了 <code>unarchivedObjectOfClass:fromData:error:</code>。</p>
<p>从整体上来看 <strong>NSSecureCoding</strong> 比 <strong>NSCoding</strong> 其实就多了1个Class类型的参数，安全性也体现在这个参数上。</p>
<p>你可以从这篇文档上获得 <strong>NSSecureCoding</strong> 的详细描述：developer.apple.com/documentati&hellip; 。</p>
<p>简单总结一下就是在使用 <strong>NSCoding</strong> 协议时，你需要先解码然后才能判断类型是否正确，代码如下：</p>
<div class="jb51code"><pre class="brush:cpp;">id obj = ;
if (!]) { /* ...fail... */ }
</pre></div>
<p>这样做有很多缺点，首先你在验证类型的时候，这个对象已经构造完成了，如果这是一个集合类的话，那么这个对象可能已经插入到集合中了，如果类型不准确可能还需要移除；这样效率会很低。</p>
<p><strong>NSSecureCoding</strong> 的做法就是把 Class 作为参数传递进去，Apple会在解码前验证类型是否一致。</p>
<p>看起来 <strong>NSSecureCoding</strong> 确实比 <strong>NSCoding</strong> 更安全了，但是它却有一个致命的缺点。</p>
<p class="maodian"></p><h3>NSSecureCoding的致命缺点</h3>
<p>我们把数据存储到本地的时候，自然也希望下次读取的是上次我们存储的值，而不是一个被修改过的值，我在测试 <strong>NSSecureCoding</strong> 的时候，发现归档文件居然能被篡改，而且程序还能正常读取到被篡改后的值而没有任何异常，当然，这个问题 <strong>NSCoding</strong> 同样也有。</p>
<p>具体过程如下：</p>
<div class="jb51code"><pre class="brush:cpp;">NSData *archiver = ;
;
</pre></div>
<p>第一步将归档数据保存到本地。</p>
<p>这是我保存到本地后的文件 <code>archiver</code>，正常情况下确实不管用什么软件要么打开失败要么乱码，但是如果你把文件后缀改为 .plist 的话，然后用Xcode打开就能看到文件的大致信息，具体包含类名、父类、属性名以及属性值，如下图所示：</p>
<p style="text-align:center"><img alt="" src="https://img.jbzj.com/file_images/article/202303/20230331085353023.jpg" /></p>
<p>掌握了类名、属性名之后，攻击者只需要模仿它创建1个和它同名的类，然后随意修改属性值，保存为归档文件后替换APP路径下的归档文件，就可以达到修改APP内数据的目的。</p>
<p>我在本地测试了一下，确实可以用这种方式修改APP内部数据。</p>
<p class="maodian"></p><h2>结语</h2>
<p>当然，我这里的Model比较简单，现实情况下Model可能会嵌套Model甚至更复杂，我没有测试这些更复杂的情况；不过还是想提醒一下大家，如果是保存一些敏感或重要数据，建议采用加密或其他方式。</p>
<p>吐槽一下：Apple为什么不在归档的时候把APP的唯一信息包含进去(例如包名等等)，然后在解码之前先验证一下；然后再把.plist后缀这个问题修复一下，我可能会考虑使用它。</p>
<p>以上就是一文详解NSSecureCoding真的安全吗的详细内容，更多关于NSSecureCoding安全解析的资料请关注琼殿技术社区其它相关文章！</p>
                           
                            <div class="art_xg">
                              <b>您可能感兴趣的文章:</b><ul><li>详解在swift中实现NSCoding的自动归档和解档</li><li>iOS开发中多线程的安全隐患总结</li><li>iOS开发避免安全隐患的要点总结</li><li>iOS安全防护系列之字符串及系统函数隐藏详解</li></ul>
                            </div>

                        </div>
                        <!--endmain-->
頁: [1]
查看完整版本: 一文详解NSSecureCoding真的安全吗