15 5月

对近期AFNetworking安全漏洞引发担忧的回应

文 / Alamofire Software Foundation(由Mattt Thompson创立)

Mattt Thompson:毕业于卡内基·梅隆大学(Carnegie Mellon University),获哲学及语言学学士学位。著名的iOS网络通信类库AFNetworking的作者,此外,他还开发了Postgres.app、ASCIIwwdc和Nomad等热门开源项目。

原文链接:https://gist.github.com/AlamofireSoftwareFoundation/f784f18f949b95ab733a

前一段时间,大量关于AFNetworking存在安全漏洞的消息被公之于众,大约1000种应用程序被指称,由于SSL存在Bug,导致这些应用程序容易遭到攻击。这些文章对此存在一些错误的,带有误导性的说法。

我们对此做出回应来澄清和纠正这些说法。

背景信息

就此事,对于那些不熟悉AFNetworking的人,这里有一些与其相关的细节需要了解。

  • AFNetworking是一个第三方的开源库,置于苹果内置框架之上,提供便利的功能。
  • AFSecurityPolicy是AFNetworking的组件之一,根据应用程序设置的规则处理验证挑战(authentication challenge)。包括通过HTTPS连接时,对服务端返回的X.509证书的评估。
  • 证书锁定(certificate pinning)是一项信息安全技术,它在标准TLS评估的基础上做了改进,通过服务器显式地发送证书来匹配包含在客户端的凭证(credentials)。AFNetworking从版本1.2.0开始一直提供证书锁定技术。
  • 中间人攻击(Man-in-the-Middle Attack, MitM)是在客户端和服务器之间插入攻击者本身,使两边都认为自己和对方在直接通信。
  • 这样的一种攻击方式在客户端和服务器之间会涉及某个不可信的Wi-Fi接入点。没有对响应进行恰当地验证,攻击者就可以拦截通讯信息,用户凭证或其他敏感信息因而会遭到泄露。
  • AFNetworking官方文档强烈建议应用程序要通过HTTPS进行通信,并且使用证书或公钥锁定技术来弱化MitM这种攻击行为。工程中所包含的示例代码遵循了这些建议,在应用程序中展示了证书锁定的使用方式。

事件的时间表

收拾心情,整理思绪。下面是与这一事件相关事件的时间表:

  • 2015年2月12日,AFNetworking 2.5.1发布。这一版本包含了一个补丁,修改了证书的安全策略验证方式,将SSLPinningMode修改为AFSSLPinningModeNone。验证挑战过程中,服务器的证书默认是不会被验证的,除非客户端存在与众不同的配置行为,比如使用SSL pinning这样的证书绑定技术。
  • 2015年3月12日,我们从这个GitHub Issue开始意识到上述的修改行为所造成的影响。
  • 2015年3月26日,来自Minded Security Research的Simone Bovi和Mauro Gentile发表了一篇博文,详细说明了AFNetworking 2.5.1潜在的MitM方面的漏洞。
  • 同样在2015年3月26日,AFNetworking 2.5.2发布。这个版本恢复了先前的证书安全策略评估方式。如果安全策略将validatesDomainName设置为YES,那么SSLPinningMode将会被修改为AFSSLPinningModeNone。
  • 2015年4月20日,AFNetworking 2.5.3发布了,该版本做了额外的修改。对所有的安全策略默认设置validatesDomainName为YES。
  • 2015年4月21日,GitHub上新开了一个Issue,要求完善AFNetworking的文档和与安全相关的功能特性。我们正就此积极努力地对参考材料做全面彻底的修改。
  • 还是在2015年4月20日,来自SourceDNA的Nate Lawson发表了一篇博文,宣称某个工具可以识别苹果商店中使用了AFNetworking2.5.1的应用程序。包括来自Ars Technica的Dan Goodin在内的许多记者,在其公布的文章中都引用了该博文并提及了博文的作者。这些公开发布的内容都没有就AFNetworking维护人员的解决方案进行整理而置评。
  • 2015年4月24日,SourceDNA在其后续发布的博文中声称,存在更多带有安全漏洞的应用程序,来自Ars Technica的Dan Goodin随后也发表了一篇带有相同效果的文章。需要强调的是,没有任何一篇公开发表的文章对AFNetworking维护人员的解决方案进行整理而置评。

AFNetworking用户力所能及的事情

下面是AFNetworking用户需要了解的力所能及的事情:

如果应用程序通过HTTPS通信,却没有启用SSL pinning技术的话,应用程序就可能容易受到所报道的MitM攻击。

AFSecurityPolicy的官方文档中的内容:

将固定的SSL证书( pinned SSL)添加到应用程序中,可以帮助应用避免中间人攻击以及存在的其他漏洞。大力鼓励应用程序在处理用户数据或财务信息的时候,所有通信途径都通过HTTPS协议,配置并启用SSL pinning技术。

无论在什么时候,遵循这些建议的应用程序都不应该存在上述安全漏洞。

如果应用使用HTTPS进行通信,并且启用了SSL pinning技术,就不容易遭到所说的MitM攻击

很大一部分应用程序使用AFNetworking是通过推荐的步骤启用了SSL证书或public key pinning机制的,这些应用程序不太不容遭到上面说的MitM攻击。

如果使用的是先前的版本AFNetworking,我们强烈推荐您升级到版本2.5.3

AFNetworking 2.5.1和2.5.2包含的默认配置不适合产品级应用程序——特别是如果不进行额外的配置,就不会提供必要的TLS评估。

AFNetworking 2.5.3默认配置更加安全,即使不使用SSL pinning也会进行域名验证。

如果使用NSURLConnection或NSURLSession代替AFNetworking的话,你仍然需要检查验证挑战的实现方式

苹果内置的NSURLConnection和NSURLSession,还有Security框架所提供的API,都具有对凭证验证的安全实现方式。但是,像任何API一样,某个应用程序的安全性取决于这些API的使用方法。

是否使用AFNetworking本身并不能保证你的应用程序能够灵活应对MitM那样的攻击。是否能够灵活应对攻击完全取决于应用程序使用可用API的方法。在产品环境下,测试应用程序的健壮性和网络安全性最终是开发人员的职责。

如果你要对某个安全漏洞进行吐槽,请发送电子邮件到security@alamofire.org吧!

我们会尽快回应并提出解决方案。

如果你想为AFNetworking更出色而做出贡献,那就在GitHub上提交一个Issue和Pull Request吧!

AFNetworking是开源项目,这意味着每个人都有机会为其更出色而贡献力量,欢迎提交IssuePull Request

对负责任的安全研究和新闻工作的看法

对于终端用户来说,安全研究人员在软件安全方面起着核心作用。研究人员与软件开发人员共同努力,通过遵循既定的负责任的漏洞披露(responsible disclosure),可以快速修复漏洞。同时,将当前用户的风险降到最低。

然而,我们对一些研究人员的做法和一些对AFNetworking的披露感到失望。作为人尽皆知的话题,信息安全从未如此重要。安全研究人员和记者拥有独特的机会来让读者了解这些事实。但不幸的是,这样的披露方式常常通过制造恐惧来增加点击量,而不是客观详实的报道。

尚未有确切的方法可以表明多少应用程序受此问题的影响;这些对安全问题严重程度的揣测摧毁了对问题准确和适度的回应。同样地,根据揣测提出的权利主张对企业和其客户也帮助甚少。

事实上,编写安全的软件一直以来都是一项巨大的挑战。这需要多学科的工程师们一起合作完成。这是一个极其重要的任务,最好由理性且富有责任心的人参与。

作为软件维护人员,我们有很多事情可以做得更好,并积极采取措施来完善自身的组织和流程。从今天起,我们期待与信息安全社区的成员紧密合作,负责任地寻找并解决任何安全漏洞。

对负责任的开源项目维护工作的看法

我们真诚地向使用AFNetworking的开发者和iOS整个开发者社区表示歉意。

作为著名开源项目的维护者,我们有责任提供与高标准相契合的软件,该软件将作为应用程序不可或缺的一部分。我们却没有对应该尽快更新的版本做出回应。我们未能向您有效传达至关重要的安全信息。这所有的一切,我们表示真诚的歉意并负全责。

在未来的几周内,我们将推出重组后的AFNetworking及其相关项目,以确保稳定的通信顺利进行。从用户的角度看,这意味着更加频繁地发布版本,更高的透明度,处理问题与合并请求过程中更多的反馈。我们为此而感到兴奋。

http://www.csdn.net/article/2015-05-12/2824671-AFNetworking

11 5月

应用下载的价值究竟在什么地方?

文 / Scott Stanchak:《纽约时报》移动业务营销总监。此前,他负责Avis Budget Group公司移动营销及产品策略。他还是Winery Passport这款热门应用的创建者,在其站点BakBurner.com撰写了移动营销的相关文章。

原文链接:http://venturebeat.com/2015/02/14/the-value-of-a-download/

下载的价值有多大?

对于我来说,下载没有太大的价值,但是给下载贴上价签以后,它的价值就产生了。

自从我在大公司负责移动营销工作开始,我遇到过许多人,他们把应用的下载量作为应用是否成功的唯一指标。这大概是因为“下载”这个词语与移动应用程序关联最紧密。但除非你的应用程序是付费下载,否则很大的安装量并不代表这些用户完成了你所期望的行动。

我非常清楚下载量和下载速度都会对应用商店排名结果产生影响。这是图表意义上的成功。然而,如果不在市场营销和拓展宣传中投入资金以保持地位,这样的排名常常是难以为继的。如果把钱花在这些地方的话,你要相信,这些钱会生出更多钱的愿景定会实现。

即使是为那些大量廉价的下载花钱做铺天盖地的广告,用来驱动其在应用商店的排名,这样的做法都比单纯的下载更能实现我们所期望的行动。提升排名背后的目的则是使下载量实现连续的增长,这会有更多的益处,非常有可能引出有意图的行动(intended action)。

行动(Action

你的“行动”是什么?这是我在做演示或与他人谈论移动营销问题时常问的一个问题。

在《纽约时报》任职期间,我主要的行动是订阅。在Avis Budget Group公司,我的行动是预定出租车。在Winery Passport公司工作的时候,我的行动是让用户通过一个应用来付费验证他们的护照。多年来,我在营销活动中花费的每一块钱都是在寻找用户的意图,这其中包括订阅者的意图,租客和买方的意图。

无论你的行动是什么,它必须带有一个指定的值。原因很简单:确定投资回报率(Return On Investment, ROI)。我提到的所有这些行动显然都是货币上的价值。但还存在很多并未对我们的产品或服务付费的用户。

工作中观察到所期望的简单行动可能是不同的——登记,电子邮件注册,还有额外的文章阅读等等。总体上了解用户在每个场景中的价值所在,不仅有助于解释递增的营销利润,而且如果这些简单行动没有达到目的,那么这种认识对理解ROI也比较关键。

测量你的行动

几年前,你对应用安装活动唯一可以测量的数据就是点击率。除此之外,你还会从Apple,Google或者其他第三方分析工具得到支持数据,但这些数据并没有与用户间交流的活动。从而无法将特定的点击下载与应用中的事件相联系。

谢天谢地,那些日子已经一去不复返了。第三方公司提出了解决方案,可以测量所有营销活动,不仅是点击,还有用户行动和其间的许多其他事件(event)。

它是这样工作的:当用户点击一个活动后,他们的设备ID将被这些第三方公司的某一家存下来。当同用户再次启动应用的时候,SDK(Software Development Kit)就会读取设备ID,并验证这个设备ID是否与某个活动关联过。如果关联过,就即刻建立起了一对一的关系。你可以追踪该用户对应用的使用状况,包括这些用户是否进行过购买的行动。

未使用这些第三方公司的工具在应用商店对应用进行追踪,应用是不会有市场的。无论是否花钱动用了媒体,或者本身就是媒体。这就像网站上被推荐的资源,有其价值所在,而在这些资源如果在手机上,则会更有价值。

通过移动应用程序成功测得用户有意图的行动,你将能够做出更明智的决定,进而会调整活动的开支,还会对网络的部署进行调整。这会使你获得更高的投资回报率,意味着花同样的钱会获得更大的下载量和更多有行动的用户。

就像漏斗,顶部较小,但底部的回报会更大。这就是作为底部的下载最为有价值的地方。

01 5月

我们需要计划,但需要评估吗?

文 / Johanna Rothman:帮助管理人员和团队解决问题并交付产品。她最近的一本著作是Manage your Project Portfolio: Increase Your Capacity and Finish More Projects。你还可以在jrothman.com阅读博文及她的著作。

原文链接:http://java.dzone.com/articles/we-need-planning-do-we-need?mz=123873-agile

我在撰写项目管理著作的过程中,领教了对大量的工作进行评估的难处。

Essays on EstimationManage It这两本书中,我推荐了几种评估方法,每种方法都表明,对于一个工程或项目,不存在一个绝对的计划日期。

你能做些什么呢?有下面几种选择:

  1. 计划和再计划。要决定对当前的工程或项目投资多少。请参见(图示中)工程/项目进展。还要决定你打算对工程/项目投资多久。
  2. 按照预定日期工作。如果你以迭代的方式或增量的方式进行开发,预定日期就最合适不过了。如果经常有内部版本发布的话,你可以看到工程/项目的进展和重新制定的计划(如果使用瀑布模型进行开发的话,就不太可能满足你想要的所有功能,也无法避免不想看到的缺陷。而如果你以迭代或增量的方式开发的话,就可以按照要达到的目标去完善计划。注意,我说的是完善计划,而不是评估计划)。
  3. 对三种不同情况的评估:任何事情都顺利的情况,正常情况和最不利的情况。这是著名的PERT(计划评审技术,Program Evaluation an Review Technique)估计。
  4. 用百分比给所做的评估一个信心值。你认为在某个特定日期前后能够发布,那么对这个评估有几分把握?这种情况再计划一下最好不过了,那样你可以更新信心值了。

这里的每一项表明所做的计划带有不确定性。工程或项目规模越大,表现出的不确定性明显。

如果你使用敏捷(agile)方法的话,可能根本就不需要进行评估。这些年来,我管理了许多工程和项目。从来没有人过问项目的成本和对进度的评估。有时候只是告诉我那些预期目标,那些目标是如此地乐观,以至于我不得不对其进行总体的评估(gross estimate),用来解释为什么不能满足这个日期要求。

然而,除了总体的评估外,我并不相信其他方式。我相信敏捷方法的路线图(roadmap)。建立项目迭代增量,观察项目进度,并且可以决定下一步做什么,这都是不错的点子。

RoadMapForProduct

当你看到这幅路线图的时候,就会了解每个月如何为内部版本做计划了。

对于内部版本,每一个人都可以看到工程或项目的进度。

另外,我们按季度发布的外部版本。此时你的工程或项目也许无法按季度向客户发布。但这应该是商务上的决定,而不是由你决定的,因为此时工程或项目未达到预期标准而不能发布。如果你没有采用敏捷方法推进项目的话,可能就无法按季度发布。但我姑且认为你会用敏捷方法进行开发的。

AgileRoadmapForProduct
在单季度的视图中,你可以看到“最简可行产品”(Minimum Viable Product, MVP)。

在这里,特别是在项目的开端。你可能需要将MVP换成MIFS(Minimum Indispensable Feature Set)。

如果总是出现这么小的“Story”的话,那就可以统计他们的数量,而不是评估这些“Story”,这样做会更加接近事实。特别是在项目初期,你就不用花时间去评估,也就不用开发相应的产品。

在工程或项目的初期,你对于存在的风险和陷阱了解得最少,甚至连MVP和MIFS都不了解。但是,如果肯向用户发布一些东西,你就可以得到自己所需的反馈。

反馈会告诉你什么:

  • 这些“Story”是否数量太多而无法统计?如果是这样的话,你创建的任何评估就都是错误的。
  • 是否提交了有价值的工作?如果是这样的话,公司将会对此继续进行投资。
  • 是否正在为最具价值的任务工作成果?在工程/项目进行的过程中,其价值所在会发生变化。有时你实现此功能可能在价值上逊色于彼功能。有的时候,你会意识到你正在实现的功能其实已经被实现了。
  • 是否要停下来?如果我们提前完成了项目发布的要求,那很棒!如果还没有做好发布的准备,我们要做些什么呢?

这都是我做评估的心得体会。如果你只拿出一套评估方案,那些经理是不会相信你的。他们会向你施压,说些“少花钱多办事”那样不合常理的话。他们会这样讲:“如果我们裁掉测试的话,你可以进度更快,对吗”?(对此类言论的回应是:“NO!在技术层面所亏欠或产生的债务越少,我们才能进行得越快”。)

但是你确实需要对项目的路线图做规划,包括所积压的工作。如果没有一个路线图,展示人们所期待的东西,这些人就不会相信你,觉得你很假。由于团队所提交的内容并不是每一项都是产品负责人期待的东西,因此你要重新计划路线图。不过没关系的,尽早从反馈中得知团队力所能及之事就很赞。

向要求做评估的人提出的两个问题:

  1. 在团队停下来之前,你愿意为这个工程/计划投入多少资金?
  2. 这个工程/项目对你有多大价值?

如果你为最有价值的工程/项目工作,那还做什么评估呢?你需要了解的是在项目进行中公司打算在这个项目上投多少资金。如果所做的不是最有价值的工程/项目,你也要知道公司打算对其投资多少。或者你要有一个预定日期,有了这个日期,你可以用迭代法或增量法逐步发布版本,直到完成目标。

这就是对评估的风险管理,还有再计划。没错儿,我就是一位“0评估”粉丝,因为我们划分的粒度越小,就越容易明白如何进行计划和再计划。

我们需要计划和再计划。如果使用迭代法和增量法的话,我认为不需要事无巨细的评估。