迈克菲CTO谈iPad数据泄漏事件：我有一台iPad

　　迈克菲首席技术官George Kurtz

　　2010年6月10日

　　我有一台iPad，实际上是两台，对此我感到很自豪。我的电子邮件地址也有很多人知道，而且经常有人向我发出请求，想要知道我的邮件地址。我猜他们一定发现像这样得到我的邮件地址不费吹灰之力。所以，前两天iPad泄露现有11.4万用户信息时，为什么会引起那么大的骚动?

　　让我们来看看到底发生了什么。一个名为Goatse Security的黑客团伙发现了AT&T网站的一个安全漏洞，窃取了用户的ICC-ID(Integrated Circuit Card ID，IC卡识别码)并取得了与之相连的电子邮件地址。接下来，他们利用一段PHP代码反复向AT&T网站提供大量ICC-ID，然后取得相关电子邮件地址。就这样，他们得到了预计11.4万ICC-ID及其相关电子邮件地址。

　　我觉得大家都会觉得这是个问题，而且是个普遍存在的问题。在我们Foundstone的安全顾问服务中(www.foundstone.com )，经常会遇到我们称之为“信息公开”漏洞的问题。通过搜集用户或企业的这些信息，可以全面了解其正在使用的技术或用户行为。同时借助社会工程技术，就可以有效的获取一些原本无法得到的企业资源。

　　然而，这样的漏洞根本不算是最严重的漏洞。我们发现主要问题在于在Web应用程序的身份认证系统存在故障。也就是说，用户会话需要避免横向权限升级，因为横向权限升级将允许攻击者得到另一用户信息。所以，与其说这是iPad的漏洞问题，不如说是我们在进行应用安全评估时经常遇到的普通问题。

　　鉴于这个漏洞利用了一个Web应用程序缺陷，我认为应该总结一下在应用安全评估时最常见的5个问题。

　　授权失败

　　恶意认证用户可以接触它本无权接触的信息。通常这样会导致权限升级。如果权限升级发生在同级别的用户中，则被称为“横向权限升级”。如果用户可以将权限升级至更高级别用户，即为“纵向权限升级”。在AT&T事件里，结果只是信息泄露，而没有权限升级。

　　跨站点脚本 (XSS)

　　跨站点脚本攻击需要攻击者在应用程序的数据领域中输入恶意代码(通常是Java脚本)，而这些数据领域对该应用程序的其他用户而言也是可见的。当受害用户浏览该数据领域时，该Java脚本就在该用户浏览器中运行，并执行一些对攻击者有用的功能。反向XSS攻击通常用来进行钓鱼攻击。

　　跨站点请求伪造 (XSRF)

　　跨站点请求伪造攻击(也叫XSRF，CSRF，或者会话控制)允许恶意用户执行对攻击者选定的用户会话的操作，从而泄露用户信息。这类攻击利用了HTTP无状态的弱点。

　　密码重置功能

　　通常来说，应用程序允许用户在忘记密码的情况下重置密码。密码提醒/重置程序通常很容易成为被攻击的对象。很多情况下，攻击者首先列出所有具有同样特征的有效用户名。一旦这些用户名中有一个被辨认出来，那么密码问题的答案都可以猜出来。一般情况下，在密码重设页面没有输入次数的限制。而且用户在社交网站上设置的一些问题的答案也可能被攻击者猜中。

　　SQL注入

　　SQL注入允许攻击者在关系数据库里执行任意SQL语句。通常，漏洞出现通常都是源于应用程序SQL查询的不安全构造。即使在数据验证很少或没有的情况下，应用程序也会信任攻击者提供输入的信息，执行任意的恶意SQL语句。成功的SQL注入攻击可以泄露基础操作系统信息。

　　建议

　　尽管现在是“应用程序101”，我们仍然可以在每一份应用程序安全测评报告中看到几乎所有的5个问题。下面是几条建议：

　　授权失败

　　会话应该使用基础框架提供的会话容器。为了避免横向权限升级，应用程序需要对以下三点进行三次确认：

　　需确认的授权内容：

　　主体：例如用户或群组

　　操作：例如CRUD —— 创建、读取、更新、删除

　　客体：例如数据因素(账号、购物卡ID等)

　　跨站点脚本 (XSS)

　　为了避免诸如跨站点脚本等数据验证攻击，我们建议采取“深层防御”策略，包括输入验证和输出消毒。

　　阻止数据验证攻击的第一步就是要验证输入来防止接受任何在该应用程序中或数据终端(也就是浏览器)中有特殊意义的语句。我们推荐的输入验证方式是“默认拒绝”，只接受含有预期值(也就是白名单)的输入。日常输入验证必须始终检查数据长度、范围、类型和格式。

　　消毒应用程序HTML中的恶意语句与防止跨站点脚本攻击(XSS)同等重要。比如，“<”应编码为“<”;尽管对于用户来说，这是“少于”的意思，但是它不会被用户浏览器解释为HTML标签的起始点。

　　跨站点请求伪造 (XSRF)

　　要防止XSRF攻击，一种有效而又不唐突的方法就是在每一个可以改变某些外在状态的表格中引入一个“随机数”，或者一次性口令。每次用户加载表格，一个不同的“随机数”就被插入表格中的一个隐藏区域内。当表格提交后，应用程序检查该随机数是否有效，然后再运行所请求的操作。“随机数”可以是现有会话的标识信息，这种信息一般都会附加在每个请求之后。不过，只有当目标应用程序不存在任何XSS漏洞的情况下，这种方法才能有效。

　　另外一些更加不唐突的避免XSRF的方法包括使用“Captchas”、对重要操作重新授权、或使用独立授权密码。这些方法很有效，但也会给用户带来额外负担。从用户界面角度来看，这些方法并不常用。

　　密码重置功能

　　密码重置功能的推荐方法是：

　　1. 这种方法需要用户输入用户名。把下面信息传递给终端用户，“如果用户名与系统中的现有账户吻合，一封写有下一步说明的电子邮件将发至账户所有者的注册电子邮件地址。”

　　2. 这封电子邮件必须含有唯一的、带有时间限制的链接(比如，24小时内有效)，而且只能由用户点击一次。

　　3. 点击链接后，用户将看到几个问题。

　　4. 成功回答问题后，用户将被允许修改其密码，同时对应用程序进行授权。

　　SQL注入

　　防止SQL注入攻击需要采取“深层防御”策略。第一步是使用阻止XSS攻击中提到的白名单方法进行输入验证。

　　除此之外，还需要使用与动态SQL相反的参数查询用。参数查询可以将查询与数据分离，支持数据库引擎在数据缺失情况下决定运行查询的最佳方法。数据将由查询执行计划在运行时间内使用，保证查询执行计划不会被恶意数据修改。

　　结束语

　　我猜这个应用程序漏洞之所以得到如此关注，是因为，毕竟我们所谈论的是苹果。围绕苹果产品的炒作，比如对iPhone和iPad的炒作，令人震惊。然而事实是，这种漏洞其实并不是什么新闻，而是每天都在我们身边发生。

　　现在，很多应用程序并没有经过全面测试便推向市场。考虑到很多企业目前面临的市场压力，这种现象就变得一点都不奇怪。所以，尽管我认为这个漏洞并不像媒体渲染的那样严重，但是它还是让我们看到一个好的安全程序和生命周期研发操作是成功的关键。

　　在上面提到的最常见的5种Web应用程序漏洞中，很多都可以通过计划和安全测试来消除。你所面临的最大挑战就是说服你的老板，让他相信这些漏洞确实存在。不过我想现在你又多了一种有力武器来达到目的。