iOS：减少漏洞和攻击的安全措施

简介 ：iOS平台在硬件和软件上均提供了高级安全功能。 它是由Apple设计的，以安全为核心。 但是，iOS用户担心为iOS应用程序提供的安全级别。 Micro Focus静态代码分析器可以跟踪这些应用程序的主要威胁，从而确定安全漏洞。

开发人员可以通过确定这些漏洞的根本原因，关联它们并确定结果的优先级来安全地进行编码。 这是一份快速指南，它分析了一些常见漏洞（称为问题陈述）并提供了克服威胁的快速解决方案。

1. 问题陈述 ：该应用程序有遭受中间人（MITM）攻击和其他基于网络的攻击的风险。

说明 ：在iOS 9中，Apple引入了应用程序传输安全性（ATS），此安全性功能默认情况下要求使用SSL / TLS对应用程序的所有连接进行加密。 它阻止任何应用程序发起的“未保护”连接，其中包括不使用具有最强TLS版本和密码套件的HTTPS的连接。 部分或全部禁用ATS可能会使应用程序遭受网络攻击或MitM攻击。

统计数据显示，目前应用商店中约有63％的应用使用NSAllowsArbitraryLoads键选择退出ATS，如下所示：

NSAllowsArbitraryLoads =真

解决方案 ：如果应用程序的ATS策略将NSAllowsArbitraryLoads设置为YES ，则通过添加所需的豁免和域来修改策略，以便能够将NSAllowsArbitraryLoads设置为NO 。 如果没有，您的应用程序迟早会被阻止。

使用NSURLSession和NSURLConnection时，默认情况下启用ATS。 诸如NSAllowsArbitraryLoads — NSAllowsArbitraryLoadsForMedia — NSAllowsArbitraryLoadsInWebContent — NSExceptionMinimumTLSVersion之类的某些键会触发附加的App Store审查并要求理由。

ATS实施用于安全网络连接的最佳做法，例如TLS 1.2和转发保密性。 将来会进行更新以反映Apple的网络最佳做法。

2. 问题陈述： TLS / SSL的弱版本可能具有以下一个或多个属性：

–无法抵御MITM攻击

–用于认证和加密的密钥相同

–弱消息身份验证控制

–无法防止TCP连接关闭

这些可能使攻击者可以拦截，修改或篡改敏感数据。

说明 ：传输层安全性（TLS）和安全套接字层（SSL）协议提供了一种保护机制，以确保在客户端和Web服务器之间传输的数据的真实性，机密性和完整性。 TLS和SSL都经过了修订，导致定期的版本更新。 每个新修订版都旨在解决以前版本中发现的安全漏洞。 使用不安全版本的TLS / SSL会削弱数据保护的强度，并且可能使攻击者能够泄露，窃取或修改敏感信息。 SSLv2，SSLv23和SSLv3协议包含一些使其不安全的缺陷，因此不应将其用于传输敏感数据。

解决方案 ：要解决此问题， 请使用自定义NSURLSessionConfiguration的NSURLSession 建立了。 TLSMinimumSupportedProtocol可以是kTLSProtocol1 ， kTLSProtocol11或kTLSProtocol12 。 默认值为SSL 3.0。 此配置属性根据以下给定的配置来确定会话中任务的最低支持TLS协议版本：

NSURLSessionConfiguration * config = [NSURLSessionConfiguration defaultSessionConfiguration];

config.TLSMaximumSupportedProtocol = kTLSProtocol12;

config.TLSMinimumSupportedProtocol = kTLSProtocol1;

3. 问题陈述 ：将未经验证的输入发送到JSON可能会使攻击者将任意元素或属性注入JSON实体。

说明 ：应用程序通常使用JSON来存储数据或发送消息。 在存储数据时，JSON通常被视为缓存的数据，并且可能包含敏感信息。 在发送消息时，JSON通常与RESTful服务结合使用，并且可以用于传输敏感信息，例如身份验证凭据。

如果应用程序从未经验证的输入构造JSON，则可以更改JSON文档和消息的语义。 在相对温和的情况下，攻击者可能能够在解析JSON文档或请求时插入导致应用程序引发异常的多余元素。 在更严重的情况下，例如涉及JSON注入的情况，攻击者可能能够插入无关的元素，从而允许对JSON文档或请求中的业务关键值进行可预测的操纵。 在某些情况下，JSON注入可能导致跨站点脚本编写或动态代码评估。

解决方案 ：

注入攻击 ：要理解和避免注入攻击，需要讨论非结构化数据和结构化数据。 从安全的角度来看，非结构化数据或结构较弱的数据可能会出现问题。 它是一种混合方案，其中部分数据具有可变长度。 严格的结构化数据具有固定的格式，该格式定义了应将每条信息存储在何处。 例如，商店库存的一种简单数据格式可以指定应有4个字节（包含记录号），然后是100个字节的人类可读描述。 尽管每个字节的解释取决于其在数据中的位置，但只要避免溢出任何固定大小的缓冲区，并进行适当的检查以确保这些值有意义，则安全风险通常相对较低。

混合数据的危险：混合两种类型的数据是有风险的，在读取数据以及构造供以后使用的数据时必须考虑这些风险。

例如，考虑以下JSON数据片段：

{“ mydict”：{“ key1”：“振动模式”，“ key2”：“强度”}}

在字典中添加单词时，会出现如下所示的恶意条目：术语：key3

定义：需要更多模式”，“意外”：“您不应输入的内容

JSON文件的结果如下所示：

{“ mydict”：{“ key1”：“振动模式”，“ key2”：“强度”，“ key3”：“需要更多模式”，“意外”：“您不应该输入的内容”}}

由于空格在JSON中不重要，因此会将这两个术语添加到字典中，并且软件不会检查第二个术语的礼貌。

取而代之的是，软件应该对数据进行引用-在输入内容中扫描在封闭内容中具有特殊含义的字符，并对其进行修改或标记，以使它们不会被解释为特殊字符。

例如，在引号中加引号（\）来保护引号，如下所示：

{“ mydict”：{“ key1”：“振动模式”，“ key2”：“强度”，“ key3”：“需要更多模式\”，“意外”：\“您不应输入的内容”}}

现在，当解析器读取JSON时，它将正确读取key3的定义为“需要更多模式。”，“意外”：“您不应该输入的内容”。 因此，未定义意外单词，因为它只是key3定义的一部分。

SQL注入 ：最常见的注入攻击类型是SQL注入，这是一种利用SQL语法注入任意命令的技术。 考虑以下SQL语句：

插入用户（名称，描述）值（“ David Williams”，“真诚的人”。）；

此示例包含指令（INSERT语句本身）和数据（要插入的字符串）的混合。 天真的软件可以通过简单的字符串连接来手动构造查询。 这种方法很危险，特别是如果数据来自不受信任的来源时。 这是因为，如果用户名或描述包含双引号，则不受信任的源将提供命令数据而不是有价值的数据。

为了解决这个问题，SQL语言提供了注释运算符—，这使SQL Server忽略了其余的行。 例如，假设用户输入以下文本作为他或她的用户名：

丹麦人”，“某人”）； DROP TABLE用户； –

结果命令将变为：

插入用户（名称，描述）值（“ dane”，“某人”）； DROP TABLE用户； —“，“真心的好人。”）；

因此，数据库会插入用户，但是会忠实地删除所有用户帐户以及保存这些用户帐户的表，从而使服务无法正常工作。

4. 问题陈述 ：在建立SSL连接时，通过Network类中的setValidatesDomainName :(）建立的连接未验证服务器证书。 这使应用程序容易受到MitM攻击。

说明 ：建立SSL连接时，服务器身份验证被禁用。 当尝试使用NSURLRequest的实现连接到受SSL保护的服务器时，如果请求的服务器的证书是自签名的（因此未验证），则不会看到警告或错误。 结果，该应用程序现在可能会通过断开的SSL连接泄漏敏感的用户信息，这等效于信任所有证书。 代码将NSURLConnectionDelegate配置为接受任何HTTPS证书，并忽略SSL。

解决方案 ：解决方案将是证书固定。 为了加强安全性，应用程序应执行额外的身份检查。 然后，应用程序应在连接时获取服务器的身份，并将其与应用程序中的硬编码进行比较。 要控制证书，请在打开服务器电源之前更新应用程序并将新的将来的证书添加到我们的密码集中。 Google会定期轮换其SSL证书，例如每月一次。

5. 问题陈述： WebInspect已检测到对服务器上较弱的TLS / SSL密码的支持。

说明 ：TLS / SSL保护机制的强度由身份验证，加密和哈希算法（统称为密码套件）确定，该算法被选择用于通过TLS / SSL通道传输敏感信息。 大多数Web服务器都支持一系列强度各异的密码套件。 如果配置错误，则可以操纵Web服务器以选择弱密码套件。 使用弱密码或长度不足的加密密钥可能会使攻击者破坏保护机制，执行MITM攻击并窃取或修改敏感信息。

解决方案 ：建议包括更新Web服务器配置，以始终选择最强的加密密码。

还可以执行SSL服务器测试。 这是一项免费的在线服务，可对公共Internet上任何SSL Web服务器的配置进行深入分析。

除此之外，名为Charles的HTTP代理/ HTTP监视器/反向代理使开发人员能够查看其计算机与Internet之间的所有HTTP和SSL / HTTPS通信。 这包括请求，响应和HTTP标头（其中包含cookie和缓存信息）。

6. 问题陈述 ：WebInspect已检测到目标服务器在密码套件中使用的小素数p为1024位或更小的Diffie-Hellman组。 因此，服务器可能容易受到窃听和/或MitM攻击。

说明 ：Diffie-Hellman密钥交换是一种流行的加密算法，它允许Internet协议就共享密钥达成共识并协商安全连接。 它是许多协议（包括HTTPS，SSH，IPsec，SMTPS和依赖TLS的协议）的基础。 部署Diffie-Hellman密钥交换时，有几个弱点。

Logjam攻击是弱点之一，它使MITM攻击者可以将易受攻击的TLS连接降级为512位出口级加密。

来自州级对手的威胁。 数百万的HTTPS，SSH和VPN服务器使用相同的素数进行Diffie-Hellman密钥交换。 从业者认为，只要为每个连接生成新的密钥交换消息，这都是安全的。 但是，数字字段筛选中的第一步-断开Diffie-Hellman连接的最有效算法-仅取决于此素数。 第一步之后，攻击者可以迅速断开各个连接。

该计算是针对用于TLS的最常见的512位素数进行的，并证明了Logjam攻击可用于将连接降级到支持DHE_EXPORT的TLS服务器的80％。 进一步估计，一个学术团队可以突破768位素数，而一个民族国家可以突破1024位素数。 打破Web服务器使用的最常见的1024位素数，将允许被动窃听与前100万个HTTPS域中的18％的连接。 第二个主要因素是允许被动解密与66％的VPN服务器和26％的SSH服务器的连接。 对已发布的NSA漏洞的仔细阅读表明，该机构对VPN的攻击与这种突破是一致的。

解决方案 ：要运行服务器，请禁用对导出密码套件的支持，并使用2048位Diffie-Hellman组。 使用SSH并将服务器和客户端安装升级到最新版本的OpenSSH，该版本首选Elliptic-Curve Diffie-Hellman密钥交换。

要运行浏览器，请安装浏览器的最新版本，并经常检查更新。 Google Chrome（包括Android浏览器），Mozilla Firefox，Microsoft Internet Explorer和Apple Safari都在部署针对Logjam攻击的修复程序。

7. 问题陈述 ：存储且未受保护的私人信息（例如明文文件中的密码）危及系统安全。

说明 ：让我们考虑一下，私人信息存储在不受保护的iOS属性列表（plist）文件App-Info.plist中。

私有数据可以通过多种方式进入程序：

–直接以密码或个人信息的形式来自用户。

–应用程序从数据库或其他数据存储区访问。

–间接来自合作伙伴或其他第三方。

–从移动数据存储中检索，包括地址簿，快照照片，地理位置，配置文件（包括plist），存档的SMS消息等。

解决方案 ：私有数据应存储在安全的服务器中。

结论：

为了有效利用iOS内置的广泛安全措施，定期检查安全做法至关重要。

本文讨论了使用iOS及其解决方案的一些常见漏洞。 它主要处理MITM攻击，基于网络的攻击，注入攻击以及避免/纠正它们的方法。

谢谢！

很高兴有机会与您分享这篇文章，希望您喜欢它 。 😊 感谢您的阅读。 🎉

如果您喜欢这篇文章，请在掌声下支持我 。 谢谢您的宝贵时间，并确保关注我或在 below 下方发表您的评论