开发团队面临的三大安全挑战

应用安全不能只依靠防火墙,必须要在应用开发阶段采取适当的安全控制措施,使得应用在发布上线前就具备较好的安全性,避免人为失误造成安全隐患。

不少企业早就意识到了这一点,然而理想和现实之间还隔着几十个安全漏洞,尤其是那些采用敏捷或者精益开发模式的团队,在具体的实践过程中,几乎无可避免的会遭遇到下面几个挑战。

挑战1:一次性的安全检查无法匹配持续性的交付

为确保团队开发出来的应用具有足够的安全性,最常见的选择是对其进行全方位的安全渗透测试。无论这样的测试是由企业自己的安全团队执行,还是购买外部第三方服务,最终都会得到一份详细的安全报告,团队接下来需要做的就是基于这份报告所揭露的漏洞,对应用进行相应的调整,直到安全漏洞被修复为止。

持续交付是敏捷、精益开发团队的核心能力之一,这意味着团队可以做到每周甚至任意时刻发布产品,持续性的从真实环境中获取市场反馈,然后基于这些反馈对产品进行调整。一个可以参考的案例是,早在2014年的时候,亚马逊平均每秒有一次以上的产品部署,每天如此。

与此同时,安全渗透测试却没有这么高的“交付”速度。由于渗透测试的特殊性,虽然有大量的自动化漏洞扫描工具可以使用,但是一次全面、高质量的渗透测试依然需要人工参与,几天甚至一两周之后才能得到测试报告是普遍现象。

那么问题来了,一方面开发团队持续性的每周都有新功能上线和旧功能调整,另一方面渗透测试却没办法在这么短的时间里完成,它只能是阶段性、或者定期性的进行,例如每个季度测试一次。

这种情况下,开发团队该何去何从?如果要安全,那么就得等着做渗透测试,而且一旦发现安全漏洞还要花额外的时间去修复,产品发布必定会延期。如果要效率,那么就只能冒着风险发布,因为谁也不知道当前应用有没有安全漏洞,万一被黑客发现并且加以利用,后果不堪设想。

问题的关键在于,开发团队是在持续的发布应用到生产环境,然而渗透测试却是个相当耗时的一次性活动,它没办法跟上这么快的交付速度。

挑战2:缺乏自动化、自助化的支持,安全实践落地难

开发团队其实明白安全对于应用而言至关重要,也知道在开发过程中就应当通过运用各种安全最佳实践来主动消除安全问题,把安全风险降至最低。不过现状却是,不少安全实践要么无法落地实施,要么有流于形式的倾向。

一个真实的案例

一个开发团队在做完业务需求梳理后,立即进入了开发阶段。安全团队虽然在项目启动时提出过安全要求,例如要求团队采用威胁建模活动,识别出应用面临的安全威胁,并制定应对措施。然而由于该项目交付压力大,时间紧任务重,再加上团队成员对于威胁建模并不熟悉,最后这个活动被一拖再拖,直到应用开发完毕进行上线前的审批时,才发现没有做威胁建模,而此刻为了能让应用按时上线,只好回过头来临时补一份威胁建模的文档,仅用于应付安全部门的要求。这种情况下,安全威胁根本得不到全面的分析和应对,风险由此而生。

在项目前期的设计阶段是进行威胁识别的最佳时刻,开发团队只要在这时做一次威胁建模,就能识别出潜在的安全风险,并且在接下来的开发过程中采取适当的措施加以应对。但是开发团队却仿佛是懒癌晚期患者,硬是拖到上线前才把威胁建模补上,而此时它早已失去意义。

为何开发团队一边认同安全的重要性,一边却又对安全实践如此怠慢呢?本质原因在于,某些安全实践需要大量人工参与,或者对人员安全技能有很高的要求,与此同时又缺乏自动化、自助化的支持,因此在开发团队看来,这些实践的采纳成本太高,在面临交付压力的情况下选择性的忽略,或者认认真真的走个形式,就成了再正常不过的结果。

挑战3:高耸的部门墙让开发和安全团队难以进行高效的协作

随着敏捷、精益开发模式的普及,再加上DevOps转型的助推,不少企业已经开始组建全功能开发团队,团队中各个角色有着共同的目标,相互协作以更高的效率交付应用。但是安全团队却依然隶属于一墙之隔的安全部门。

别小看了这堵墙,说它是万恶之源有点太夸张,但它的存在确确实实阻碍了企业实现其业务价值最大化。墙的这边,开发团队竭尽所能的以最快的速度完成应用开发,以求尽快上线获取反馈;墙的另一边,安全团队只关心应用是否安全,至于是否急着上线,那不是他们关心的问题。但是他们都忽略了一个事实,那就是企业的成功需要两者共同高效的协作。

小结

敏捷、精益团队一方面要保持快速的交付速度,一方面还要提高应用的安全质量,看上去这是鱼和熊掌不可兼得的事情,然而事实上我们依然有办法解决这些挑战。

开发团队可以通过自动化,显著降低安全实践的实施难度和成本,把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队,也应当向着开发团队迈进一步,打通开发和安全部门之间的隔离,以更加紧密和高效协作的方式,共同确保应用具备更高的安全质量。


更多精彩洞见,请关注微信公众号:思特沃克

Share

避免CI成为一个安全隐患

背景

最近临时交接了一个客户测试环境和产品环境的维护工作。交接的客户资产包含:代码库、生产环境主机、测试环境主机、搭建在测试环境主机上的持续集成服务器以及对应的账号密码。这个持续集成服务器采用Jenkins搭建,并且可以用来部署测试环境和生产环境的应用。

不久,接到了客户的一个维护请求:把最新的生产环境数据同步到测试环境里。

这个维护任务需要通过SSH登录到测试环境主机上进行操作。测试主机是通过authorized_keys进行SSH认证的,只要你自己的ssh-key被添加到了主机上,就可以实现无密码登录。这样有两个好处:一方面维护人员无需使用密码,避免了生产环境密码的泄露。另一方面可以按需吊销不再使用的客户端,及时回收权限。所以我需要把自己的sshpublickey交给管理员,让他把我的key加到可访问列表里。

悲剧的是,前管理员告诉我,他的key因为更换电脑的关系没有及时更新。所以,他也无法登录主机。而且之前参与维护的其它管理员的key也都失效了,这意味着我们失去了对主机的控制。此时,我手上只有登录Jenkins的的用户名和密码,于是一个邪恶的想法就诞生了:

既然Jenkins可以执行脚本,那么我是否可以通过Jenkins把我的key注入进去?

于是我把ExecuteShell的Job变成了我的命令行,通过运行日志得知了宿主用户的文件目录信息。然后把自己的sshpublickey加到了登录列表里(此处省略敏感信息):

sudo sh -c“cp~/.ssh/authorized_keys~/.ssh/authorized_keys.bak”

sudo sh -c"echo‘{我的sshpublickey}’>>~/.ssh/authorized_keys"

It works !

我成功的登录了机器,但这却暴露了一个问题:持续集成服务器成为了一个安全隐患。

首先,持续集成服务器可以执行代码。这就意味着它有可能执行有害代码。

其次,持续集成服务器缺乏足够的用户鉴权,这很有可能导致未授权用户访问。

无权限控制的服务器+可以执行代码=裸奔的肉鸡

那么,如何构建一个更安全的持续集成服务器服务器?

rootless原则

“神操纵着万物,你感觉得到他,但永远看不见他。”——《圣经·希伯来书11:27》

在服务器的世界里,root用户就是神,拥有至高的权力和力量。如果有人获得了“神之力”,后果可能不堪设想。

无论是Web服务器、数据库服务器还是持续集成服务器。都是这个世界里的二等公民,权限和力量都应该受到约束。执行的时候应该受到控制。

此外,应该极力避免sudo的滥用,尤其是对那些从外部访问的用户。很多情况下,为了操作方便,很多用户都有sudo的权限。但这恰恰造成了低权限用户通过提升自己的访问权限进行有害操作。

在上述的故事里,因为没有对Jenkins的主机用户做有效隔离,导致了我可以用sudo注入自己的key获得机器的访问权限。

沙盒隔离原则

因为持续集成服务器会执行脚本或运行程序,而这些程序和脚本有可能是存在恶意代码的。所以,对应的任务应该在隔离的安全沙盒中执行,例如:受限的用户,受限的权限,受限的空间。

在上述的故事里,我就通过CI执行了一段不安全的脚本成功获得了登录主机的权限。

如果这些任务在隔离并受控的Docker容器里执行,那么会安全得多。

当然,也可以考虑采用TravisCI这样的第三方持续集成服务来保证安全性。

备份和备份核查原则

在上述故事里,因为缺乏有效的备份机制,导致了所有人都无法访问主机。此外,我在修改authorized_keys的时候先进行了备份。这样,如果我注入失败,还可以还原。

这里的备份,不光是对配置、数据的备份,还有岗位的备份。

如果管理员有备份,完全不会出现无法登陆的事情。

如果有备份QA服务器,完全可以不需要当前的QA服务器。

在做任何变更前,都应该做好备份以及还原的准备。因为任何变更都会带来“蝴蝶效应”。

但是,光备份是不够的。如果备份不能有效还原,那和没有备份没有什么区别。所以,要定时的进行备份恢复测试。确保备份在各种情况下可用。

多重要素身份验证原则

上述的持续集成服务器是暴露在互联网中的,任何一个人访问到这个站点,通过一定程度的密码破解,就可以获得这个持续集成服务器的访问控制权限。从而可以做出上述的操作。

所以,有了用户名和密码,并不一定是可信用户。还需要通过更多的手段,诸如手机短信验证码或者第三方认证集成来验证用户的身份。

关键操作手动验证原则

试想一下,如果在上述的例子中我并没有服务器的访问权限。而是通过提交未经审查的代码自动运行测试脚本。实际上也会造成同样的效果。

有时候我们会为了方便,让持续集成服务器自动触发测试。但是,恰恰是这种“方便”带来了额外的安全隐患。而这样的方便,不光方便了自己,也方便了恶意入侵者。

所以,不能为了方便而留下安全隐患。在关键操作上设置为手动操作,并通过一定机制保证关键操作的可靠性才是最佳实践。

构建安全CI的几个实践:

采用Sibling的方式在Docker里运行任务。

账户密码管理统一采用LDAP认证,如果过期则从外部修改。

CI的登录权限和其它的认证方式(比如GitHub、Okta等)集成起来。并用组限制登录。

对于生产环境的CI,通过更加细粒度的权限限制来隔离一些危险操作。

官方的安全指南

不少持续集成工具的官方都提供了最佳实践以及安全指南帮助我们构建持续集成服务器。请务必在构建持续集成服务器前阅读并理解这些安全实践和措施,并遵照安全最佳实践构建持续集成服务器:

Jenkins最佳实践:https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices

Jenkins官方安全指南:https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins

如果没有这些如果

上面提到了太多的如果。如果这些“如果”能发生在事前,这些问题就不会产生。持续集成本身是开发的最佳实践,但如果缺乏安全的意识,一味的追求方便和高效,则会带来很大的安全隐患。通过一些简单而基础的措施和手段,我们就能大大的降低风险。


更多精彩洞见,请关注微信公众号:思特沃克

Share

迁移中的企业科技新范式

过去说起IT,我们脑海里浮现的印象是散布在各处的计算机,严肃呆板的企业软件,还有幽深机房里一排排网络设备和线缆。今天,科技的迁移让企业在技术应用上远远超出了传统IT的范畴。新兴技术不再由硅谷的科技新贵们独揽,越来越融入到企业科技的范畴。我们看到,其中五个宏观板块的迁移趋势开始带来越来越明显的影响。

  • 演进中的交互
  • 增强人类效能
  • 平台的兴起
  • 安全
  • 机器人的崛起

演进中的交互

人机交互方式的快速演进,让我们从键盘加屏幕,快速走进了真正的多模交互方式。这种变化发自消费者领域,最近也逐渐融入到各种商业场景。

首先是语音。越来越多的人开始用语音给手机和汽车发出指令,用语音转换成文字来回微信、写邮件。在2015年,中国的智能语音市场达到46.8亿人民币的规模,跟前一年相比有53.1%的涨幅。从这个市场趋势中,我们可以预见语音的运用场景将越来越广泛。

以呼叫中心为例,传统的“Interactive Voice Response (IVR)”需要客户按下一个个菜单选择按钮、选择服务,听完冗长的语音提示,而智能呼叫转接“Intelligent Call Steering (ICS)”降低了错误转接的概率,提升了获取服务的速度。同时,声波纹识别能在保障一定安全水平的前提上,去除繁琐的身份验证。Standard Life Insurance通过ICS把错误转接的概率降低了66%,服务人员也不需要再把时间花在繁琐重复的转接工作上。都柏林机场使用语音技术为65%的来电提供自主服务,并期望在近期内把这个数字提高到80%,在提高客户满意度的同时,把每位服务人员的每个电话时长平均缩短了52秒,使得他们能够在不增加人手的情况下提升30%的工作效率。

装备了先进技术的智能客服未来可以第一时间识别出客户所使用的语言、客户的身份,并以自然的应答方式帮助客户准确找到所需服务。即使智能系统不能满足客户的需求,也能更准确地找到合适的人工服务,提升用户的体验。不像IVR菜单,虽然降低了人工的成本,却带来了糟糕的体验。

如果说智能客服代表的是电话或其它个人语音终端的服务场景,亚马逊的Echo则为我们提供了另一种可能。带有7支麦克风阵列和波束成型技术的远场语音能力,不管你在房间的什么位置,即使是正在播放音乐的环境下,也能让系统听到并听懂你的声音。国内类似的有京东和讯飞合作的产品 – 带有8支麦克风的叮咚。这种技术的发展,可能会导致商场、酒店、办公室里的交互体验出现革命性的变化。ThoughtWorks跟渣打银行合作的魔镜原型展示了这种可能性。这个原型产品集成了人脸识别技术和亚马逊的Alexa语音识别技术,在银行网点里通过跟镜子说话完成账户信息查询和转账交易。

除了语音,这两年最火热的新兴交互模式非AR/VR莫属了。虽然最近似乎出现一丝疲态,但正是在这种时候,VR/AR开始摆脱“Geek玩具”的地位,缓慢却坚定地渗透入真实的商业和工业场景。早在2011年,Topshop在其莫斯科的店里就部署了基于Kinect的智能试衣镜。体感探测装置将3D服装模型叠加在顾客的影像上,实现虚拟服装与客户体型的融合。另一个例子是家具宜家卖场。宜家观察到,有14%的客户在试图把带回家的家具放到预期的位置上时,却发现家具的大小并不合适。于是宜家制作了一个AR应用,可以让顾客用手机从目录里选择家具,以手机照相机的视角把家具放到预期的位置。虚拟家具的大小跟真实家具非常接近,客户可以准确地观察和评估家具在房间里的效果。

图片来源: http://newatlas.com/ikea-augmented-reality-catalog-app/28703/

虽然早在1990年,波音公司的研究员Thomas Caudell就已经提出了Augmented Reality (AR)增强现实,来描述电气工程师如何用头戴显示设备帮助处理复杂的布线线束。但直到最近,随着Google Glass和用在汽车挡风玻璃上的显示装置的应用,人们才开始认真考虑AR在商业领域的使用。虽然当前设备提供的精确度还远不能让人满意,随着算法的演进和传感器的改进,AR/VR带来的沉浸式体验将真正改变人与人之间、人与机器之间的交互模式。

增强人类效能

自打诞生以来,人工智能就被赋予了超越现实的期待和恐惧。这或许是因为人们总把人工智能跟科幻电影里的想象联系在一起。我们实际看到的,更多是人类的经验和直觉,加上机器处理海量数据的能力,人和机器将各展所长,发挥更大的效能。ThoughtWorks曾经为宝洁公司开发了一个产品原型,用算法优化帮助供应链计划人员提升了10倍以上的效率。这种计算能力如果结合IoT或其它智能设备,效能会更加显著。

我们可以想象一个场景。一位工程师在野外检查一台复杂的机器设备。他的AR眼镜扫过机器,眼前的屏幕立刻显示出设备的系统示意图。他可以选择使用设备的3D零件结构视图,并且配以相关的检查指令,呈现出一个完整的虚拟检修流程。后台的系统根据设备出厂记录,以及使用和维修的历史数据,推测出当前最有可能出现问题的组件和相关的原因信息。他还可以通过眼镜跟远方的其它工程师交流,共同诊断问题。如果发现了有问题的组件,则直接把组件信息传至工程车上的3D打印机,现场制作合适的备件。

这样的场景不仅仅是出于想象,绝大多数所需的技术都已具备。拖拉机、化学喷雾器等农业设备的制造商AGCO在世界各地都拥有生产设施。在AGCO的一个工厂里,一位带着Google Glass的拖拉机引擎的装配工人,可以通过眼镜扫描零件的序列号,直接得到相关的手册、图片或视频。她还可以通过语音指令跟工厂里的其他人沟通或留言。Peggy Gullick, AGCO的业务流程改进总监认为Google Glass改变了游戏规则,将质量检测的速度提升了20%,并且对于新员工的岗位培训也很有帮助。以前工厂中常用平板电脑来做类似的事情,但在工厂环境下,人们经常需要爬上爬下,而且需要用手操控其它工具或设备,平板电脑经常跌落损坏,因此需要一个能够解放人们双手、又非常方便智能的工具。

智能技术的进步不仅仅能够提升个人的工作效能,还能助力人们在像环保这样的社会领域发挥更大影响。瑞典公司Einride正在试验新的运输系统,试图凭借可替代能源和无人驾驶技术变革公路运输系统。Einride的T-Pod卡车使用电池驱动,T-Pod的自动驾驶系统并不完全依靠AI,而是结合了驾驶人员的远程人工控制,相对完全的自动驾驶更加安全。驾驶人员可以在远程控制台上监控和操控车辆,并在合适的时间在不同的车辆之间切换,比如在车辆充电或其它停留的时候,因此少量驾驶人员就能驾驭整个大型车队的运转。Einride期望这套基于车辆、远程控制系统、充电体系的基础设施能够让公路运输不仅更加高效,而且更加环保。

图片来源: http://www.einride.eu

平台的兴起

虽然平台这个词已经被赋予了过多的含义,有些滥用之嫌,但我们在讨论企业科技的时候还是没法绕过平台的兴起这一现象。在企业科技的上下文里,当我们说到平台的时候,通常指的是以云计算基础架构为代表的平台。在这之上,特性丰富的PaaS平台的采用,让技术团队生产力得到了的巨大提升。不过,我们现在已经看到了平台的下一步发展。部署快速创新实验的平台,建设无缝生态系统的平台,各种为商业目标而设计的技术平台开始浮出水面,“平台思考”(Platform Thinking)变得尤为重要。

以汽车行业为例,中国汽车销售市场增长日渐进入瓶颈。2015年,15家上市经销商集团中,有6家企业总收入保持增长,其余企业均出现不同程度下滑。统计范围内企业年内共实现汽车业务收入4398亿元,较2014年下滑5.32%。这个趋势中,有先见之明的经销商开始利用自己丰富网点渠道和大量存量客户,整合线上线下资源,建立贴近客户的一站式服务平台。ThoughtWorks的一家客户构想了一个覆盖车厂、4S店、银行、保险、配件厂、道路救援、二手车商、维修服务等的生态平台。这套平台的核心是以微服务的方式改造企业架构,逐步推进各系统的服务化。让服务在平台上注册,并开放其API,使得其它应用或第三方服务可以通过组装接口产生新的应用,并且这些应用能够统一运行在这个平台之上。

无独有偶,不仅仅经销商开始建设平台,车厂从另外一个角度切入了平台化的策略。在前方,车厂面对经销商对客户资源的垄断,后方则面临各种以新能源、自动驾驶为代表的新型汽车厂商的颠覆,同时各种共享经济模式的搅局者也在重塑着汽车行业的格局。以戴姆勒为代表的车厂积极主动布局自己的平台生态,不仅通过电商和销售顾问的手持设备整合消费者全生命周期的数据,并且试水“Car2Go”即行和Car2Share随心开两种分时租赁的业务模式。

当越来越多的行业面临类似的变革,企业需要梳理和设计企业应用间的共享服务,利用领域驱动设计(Domain Driven Design – DDD)分析现有应用API并重新设计,并分析业务战略相关的外部第三方服务,规划生态圈应用以及相应服务和API的实现。还是以汽车行业为例,车企的车联网IoT设备需要把急刹车、行车距离、凌晨开车的次数等数据推送至接口,而保险公司要建立相关数据的接收和分析机制,这样的数据发布与运营平台让创新的业务模式UBI(Usage Based Insurance,基于用量的保险)成为可能。提升开放服务平台的持续接入能力及其易用性,成为有意在新经济格局中占据主动的企业所必须研究的课题。

安全

2015年PwC和英国政府联合组织的信息安全漏洞调查显示,在被调查的大型组织中,出现安全漏洞的比例从2014年的81%增加到了90%。而小型组织发生安全漏洞的比例也达到了74%。在最新2017年的安全调查中发现,在知道自己出现安全漏洞的组织当中,有差不多三分之一不知道自己漏洞持续时间有多长,同时有约三分之一的公司无法评估由于这些漏洞带来的经济损失。相对应地,跟2016年相比,有46%的组织今年增加了信息安全的预算

创新的业务模式在涌现,新兴技术在被快速采纳,安全在这个进程当中明显落在了后面。以2015年出现的海康威视安全门事件为例,作为本来就是以安防为主业的公司,其部署的监控设备却被境外IP地址控制。不过回想起来,其实并不那么让人意外。这些系统过去的部署环境主要是在局域网或专网,当走向互联网、IoT的时候,必然会面临新的挑战。很多其他企业的数字化也在经历类似的进程。

虽然安全厂商和咨询公司拿出了一套套的方法,但这些放之四海皆准的体系并不能解决日趋复杂的问题。前面提到的生态平台和API经济,带来一个直接的后果就是模糊了系统和系统、企业和企业之间的边界。而IoT带来的数量急剧增加,且多样化的集成点,让安全隐患的发生几率呈现几何级的增加。这种情况已经不能简单地依靠后期的安全测试和第三方安全审计来解决了,成型的套装软件在这种情况下通常也是效果不佳。

安全是所有人的问题,建立一个人人关注安全的文化成为重中之重。ThoughtWorks提出的©BSI(Build Security In)方法就是在这样一个环境下的产物。在BSI里,ThoughtWorks模仿软件开发的敏捷宣言,提出了安全宣言。

  • 持续安全扫描 胜于 单次安全审查
  • 前期安全威胁分析 胜于 末期安全渗透测试
  • 主动发现安全漏洞 胜于 被动等待漏洞报告
  • 安全职责共享 胜于 独立安全团队

在制定方向之后,ThoughtWorks的团队在包括像瑞士信贷移动应用、戴姆勒奔驰的电商和销售顾问的手持终端项目上,构建安全基线,把安全扫描加入到产品自动化构建的Pipeline上,并引入安全建模等产品生命周期前端的实践。降低了在后期安全测试和审计当中出现问题的几率,大大减少了因为安全问题导致的上线推迟或带病上线的现象。 文化和体系的建设之外,人们也在采用新的技术提升安全手段的效用。以身份验证环节为例,人们开始结合安全信息和事件管理机制(Security Information and Event Management – SIEM),分析访问人员的登录时间、位置、设备,应用、访问行为等数据,识别高风险的访问行为。如果发现风险行为,就可能要求进一步鉴权,甚至强行终止访问。有些先进的组织开始结合机器学习的预测能力,以预测算法持续分析正在发生的访问事件,识别风险。在提升安全防护级别的同时,改善用户体验。

机器人的崛起

根据IDC最新的全球商用机器人消费指南,全球范围内在机器人技术以及相关服务上的投入,相比2016年的915亿美元,将在2020年前翻番,达到1800亿美元。虽然到现在为止,制造业仍然是机器人最大的市场,但机器人已经不再局限于在生产线上挥舞着机械臂,我们看到各式各样的机器人开始在企业科技场景下发挥着越来越重要的作用,后续跟进的包括能源、消费、医疗行业,还有智慧城市领域。

一个可能最有名的场景是在物流领域。著名的亚马逊名叫Kiva的橙色机器人,早在2015年底,已经有3万的Kiva机器人工作在13个仓库,大幅提高了仓库的效率,并减少配送出错的概率。根据记录,仓库周转时间从60-75分钟降低到15分钟,利用效率的提升可以转换为相当于增加了50%的仓储空间。根据亚马逊的高管Dave Clark的描述,使用Kiva机器人的每个仓库可以节省2千2百万美金的运营成本。这样的技术现在已不再被亚马逊垄断,在国内,我们看到天猫仓库已经开始使用来自Geek+d的仓储机器人,还有快仓等智能仓储机器人等厂家也在迎头赶上。

图片来源: https://www.amazonrobotics.com/

除此之外,最新的人工智能技术在图像识别和异常检测领域的发展日趋成熟。在相对危险、人员不容易抵达,或是范围过于广袤的地方,无人机和机器人开始巡视在林区、矿场、管道、机场,承担起监控、检修,以及安防的工作。类似的趋势也发生在需要精确无误,同时速度又是关键的领域。UCSF Medical Center的医院药房里,引入自动配药机器人的试点阶段,就达成了配制35万份药零差错的记录。

如何应对企业科技新范式?

“风会熄灭蜡烛,却能使大火越烧越旺。自然风险、社会风险,都带有随机性、不确定性,我们难以躲避,倒不如学习如何让自己在这一切中成长。伴随波动性、随机性、混乱和压力而成长的特性,就叫做反脆弱性。” ——纳西姆·尼古拉斯·塔勒布《反脆弱》

企业难以回避科技对商业的影响,更加难以精确地预测这种影响。我们先识别出科技、商业和社会的变迁趋势,然后梳理出这些宏大的故事主线背后一系列正在发展中的技术。企业需要观察这些现象,找到自己的主动出击的机会,从而培育相应能力,以期能够基于之上发展或孵化出新的业务模式。

我们看到以往基于专有套装软件的企业架构并不能支撑这样围绕客户路径,以快速响应,构建生态为目标的战略。对于很多积极进取的企业来说,建设反脆弱的科技平台已经是当务之急。ThoughtWorks的数字平台战略整合并且平台化了当前企业数字科技中各项关键技术领域,为最大化商业价值的反脆弱平台提供建设方向。

图片来源: https://www.thoughtworks.com/digital-platform-strategy

这个平台应该有几个特征:

  • 快速交付。企业应该帮助技术团队跟业务决策人密切协作,快速实现业务团队的策略意图。搭建基于持续交付为核心的弹性基础设施,自动化的部署和监控,以及贯穿全流程的安全机制,是快速及时应对变局的关键。
  • 构建生态。企业应该能够根据业务的策略和市场的机会,快速重新定义团队和企业的边界。需要以微服务和API建设服务拓扑,改善开发者体验,定义公共网关和服务边界,提升开放应用的可服务性。
  • 获取洞见。企业需要缩短数据洞察到价值创造之间的距离。要赋予一线团队能力,实现数据驱动的产品和服务演进和创新。要建立自服务机制,通过细粒度的数据授权达成数据自服务分区,让数据湖里的海量数据成为发现业务机会、感知商业风险、创新业务模式的原材料,并为整个组织所用。
  • 有序创新。组织不再依靠一两个英明的天才的创造力。前线团队的创意和想象,因贴近客户而更有价值潜力。创新的土壤不仅仅需要文化和氛围的建设,还要建立创新实验的基础设施。要快速低成本地实验来自组织各个角落的创新想法,让创新者能够以低风险的方式,以真实市场反馈为验证,大量尝试新的思路和方法。
  • 一致体验。业务生态和客户触点的复杂度的增加,让隔离的功能部门筒仓越来越成为价值创造的障碍。企业的运营模式将围绕端到端的客户旅程来构建和整合。当客户在线上线下各种渠道中,在移动、IoT和VR/AR为代表的多种触点之间切换时,企业要识别客户个体并提供一致的体验和内容。

企业科技平台的这些特征能够帮助企业增强在VUCA (volatility, uncertainty, complexity, and ambiguity)的环境里的抵抗力,把每次来袭的大风,变成发展的机会。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

登录工程:现代 Web 应用的典型身份验证需求

朋友就职于某大型互联网公司。前不久,在闲聊间我问他日常工作的内容,他说他所在部门只负责一件事,即用户与登录。

而他的具体工作则是为各个业务子网站提供友好的登录部件(Widget),从而统一整个网站群的登录体验,同时也能令业务开发者不用花费额外的精力去关注用户鉴权。这很有趣。

可以看出,在一个现代Web应用中,围绕“登录”这一需求,俨然已经衍生出了一个新的工程。不管是我们面临的需求,还是解决这些需求所运用的方法与工具,都已经超出了传统Web应用身份验证技术的范畴。

之前一篇文章中,我聊到传统Web应用中的身份验证技术,文章中列出的一些方法在之前很长一段时间内,为满足大量的Web应用中身份验证的需求提供了思路。在这篇文章里,我将简要介绍现代Web应用中几种典型的身份验证需求。

形式多样的鉴权

考虑这样一个场景:我们在电脑上登录了微软账号,电脑里的“邮件”应用能够自动同步邮件;我们登录Web版本的Outlook邮件服务,如果在邮件里发现了重要的工作安排,将其添加到日历中,很快电脑里的“日历”应用便能够将这些日程显示到Windows桌面上。

这个场景包含了多个鉴权过程。至少涉及了对Web版本Outlook服务的鉴权,也涉及了对离线版本的邮件应用的鉴权。要能够支持同一批用户既能够在浏览器中登录,又能够在移动端或本地应用登录(例如 Windows UWP 应用程序),就需要开发出能够为两种应用程序服务的鉴权体系。

在浏览器里,我们通常假设用户不信任浏览器,用户通过与服务器建立的临时浏览器会话完成操作。会话开始时,用户被重定向到特定页面进行登录。登录完成后,用户通过持续与服务器交互来延续临时会话的时长;一旦用户一段时间不与服务器交互,则他的会话很快就会过期(被服务器强制登出)。

在移动应用中,情况有所不同。相对来说,安装在移动设备中的应用程序更受用户信任,移动设备本身的安全性也比浏览器更好。另一方面,将用户重定向到一个网页去登录的做法,并不能提供很好的用户体验——更重要的是,用户在使用移动设备时,时间是碎片化的。我们无法要求用户必须在特定时间内完成操作,也就基本没有会话的概念:我们需要找到一种能够安全地在设备中相对持久地存储用户凭据的方法,并且Web应用服务器可能需要配合这种方式来完成鉴权。此外,移动设备也不是绝对安全的,一旦设备丢失,将给用户带来安全风险。所以需要在服务器端提供一种机制来取消已登录设备的访问权限。

(图片来自:http://docs.identityserver.io/en/release/intro/big_picture.html)

方便用户的多种登录方式

“输入用户名和密码”作为标准的登录凭据被广泛用于各种登录场景。不过,在Web应用、尤其是互联网应用中,网站运营方越来越发现使用用户名作为用户标识确实给网站提供了便利,但对用户来说却并不是那么有帮助:用户很可能会忘记自己的用户名。

用户在使用不同网站的过程中,为了不忘记用户名,只好使用相同的用户名。如果恰好在某个网站遇到了该用户名被占用的情况,他就不得不临时为这个网站拟一个新的用户名,于是这个新用户名很快就被忘记了。

在注册时,越来越多的网站要求用户提供电子邮箱地址或者手机号码,有的网站还支持让用户以多种方式登录。比如,提供一种让用户在使用了一种方式注册之后,还能绑定其他登录方式的功能。绑定完成之后,用户可以选用他喜欢的登录方式。它隐含了一个网站与用户共同的认知:联系方式的拥有者即为用户本人,这种“从属”关系能够用于证实用户的身份。当用户下次在注册新网站时遇到“邮件地址已被注册”,或者“手机号已被注册”的时候,基本可以确定自己曾经注册过这个网站了。

(图片来自:http://cargocollective.com/)

另外,登录过程中所支持的联系方式也呈现出多样性。电子邮件服务在很多场景中逐渐被形式多样的其他联系方式(比如手机、微信等)所取代,不少人根本没有使用邮件的习惯,如果网站只提供邮箱注册的途径,有时候还会遭到那些不经常使用电子邮箱的用户的反感。所以支持多种登录方式成为了很多网站的迫切需求。

双因子鉴权:增强型登录过程

上一节中提到的“从属”关系不光可以帮助用户判断自己是否注册过一个网站,也可以帮助网站在忘记密码时进行临时认证,从而帮助用户完成新密码的设置。如果将这种从属关系用于正常登录过程中的进一步验证,就构成了双因子鉴权。

双因子鉴权要求用户在登录过程中提供两种形式不同的凭据,只有两种验证都成功才能继续操作。现代化Web应用正在越来越多地使用这种增强型验证方式来保护关键操作的安全性。例如,查看和修改个人信息,以及修改登录密码等。

相信不少人还记得QQ密码保护问题的机制,它使得盗号者即使盗取了QQ密码,在不知道密码保护问题的情况下,也无法修改现有密码,让账号拥有者得以及时挽回损失。

双因子的原理在于:两种验证因子性质不一致,冒用身份者同时获得用户这两种信息的机率十分低,从而能有效地保护账号的安全。在QQ密码保护的例子里,密码是一种每次登录时都会使用的固定文本、相对容易被盗;而密码保护问题却是不怎么频繁设置和更改的、隐秘的、个人关联性极强的,不容易被盗。

(图片来自:http://bit.ly/2kFc492)

现代化Web应用形式多样,设备种类繁多,场景复杂多变,而为了更好地保护用户账号的安全,很多应用开始将双因子验证作为登录过程中的鉴权步骤。而为了兼具安全和便利的特点,一些应用还要求运用一些优化策略以提高用户体验。比如,仅在用户在新的设备上登录、一段时间未登录之后的再次登录、在不常用的地点登录、修改联系信息和密码、转移账户资产等关键操作时要求双因子鉴权。

单点登录:还是需要精心设计

以前,一般只有大型网站、向用户提供多种服务的时候(比如,网易公司运营网易门户和网易邮箱等多种服务),才会有单点登录的迫切需求。但在现代化Web系统中,无论是从业务的多元化还是从架构的服务化来考虑,对服务的划分都更细致了。

从整个企业的业务模式(例如网易门户和网易邮箱),到某项业务的具体流程(例如京东订单和京东支付),再到某个流程中的具体步骤(例如短信验证与支付扣款),“服务”这一概念越来越轻量级,于是人们不得不创造了“微服务”这个新的品类词汇来拓展认知空间。

(图片来自:http://cargocollective.com/)

在这整个的演变过程中,出于安全的需要,身份验证的需求都是一直存在的,而且粒度越来越细。以前我们更关注用户在多个子站点的统一登录体验,现在我们还需要关注用户在多个子流程中的统一登录体验,以及在多个步骤中的统一登录体验。而这些流程和步骤,很可能是独立的Web系统(微服务),也有可能是一个用户界面(独立应用),还有可能是一个第三方系统(接口集成)。

可以说,单点登录的需求有增无减,只不过当开发者对这种模式已经习以为常,不再意识到这也是一个能够专门讨论的话题。

考虑与用户系统集成,与业务系统分离

在讨论安全时,分不开的两个部分就是鉴权(Authentication)与授权(Authorization)。

鉴权的过程是向用户发起质询(Challenge),完成身份验证工作。这正是登录所解决的问题。通常在登录系统成功识别用户之后,就会将接下来的工作直接交给业务系统来完成。由于各个系统中的授权模型可能与业务形态有关系,因此登录与业务系统分离是很自然的设计。

在对安全要求更严格的企业或企业应用中,可能需要专门的访问管理机制,不过,这样的做法在互联网应用中很少见。但在互联网Web应用中,授权的范畴也包含一个很小的公有部分,是各个业务系统所共有的:即用户状态。我们希望在各业务子系统之间共享用户状态:用户被锁定之后,他在所有业务系统都被锁定;用户被注销之后,所有业务系统中有关他的数据都被封存。

(图片来自:http://cargocollective.com/)

另外在多个业务系统中,还可能会共用用户的基本资料和偏好设置等数据。比如,类似于邮件地址这样的资料,它可以作为登录凭据,也可以作为一个基本的联系方式。如果用户在一个子系统设置了偏好语言,其他子系统则直接使用该设置即可。这样,开发一个“用户”系统的想法也就应运而生了。由于与用户的状态等基础信息的关系很紧密,登录与用户系统之间的集成是很自然的,将登录子系统直接作为这个用户系统的一部分也不失为一种不错的实践。

与第三方集成:迎接更多用户

“即得”是一个开放式文档共享应用,特点是“无需登录,即传即得”,它利用长时间有效的Cookie来标识用户,从而免除了人们使用应用之前必须注册登录的繁琐步骤。

这种做法的风险是,如果用户有及时清理浏览器Cookie的习惯,那很可能导致用户再一次登录时不再被识别。不过从这样一个小例子中,却容易看出登录的真正作用,就是Web应用识别用户的过程,当下次同一个用户再次使用时,Web应用就能够知道“这就是上次来过的那个用户”。

如果识别用户这一需求能够在不需要用户注册的前提下搞定,岂不两全齐美?基于第三方身份提供方的接口来识别已经在其他平台注册的用户,并将其转化为自己应用中的用户,这种方式完全可行,并且大量的开发人员已经有了丰富的实践。

从 2010 年开始就有不少的大型互联网公司开始推出开放平台服务,让第三方应用通过Web接口与这些互联网服务交互,从而为他们提供更丰富多彩的功能。在这个过程中,一些应用不为这些平台提供扩展,却巧辟蹊径地利用了这些开放平台的身份识别接口来免除新用户注册的过程,从而为自己的产品快速导入用户。不少网站都提供“使用微博账号登录”功能,相信读者一定体验过。

(图片来自:http://bit.ly/2kFi3e8)

如果你的应用需要向第三方提供用户,那么我们的角色就由“从上下文中读取用户身份”变成了“向上下文中写入用户身份”了。如果你正好有过与各互联网公司开放平台的接口打交道的经历,这时候,你就可以体验一把提供开放、安全上下文的挑战了。如果……你的平台既希望让其他平台的用户能够平滑接入,又希望向其他平台公开自己的用户,那可能是另一番更有趣的挑战。这个过程,也可以作为生物验证之外的另一种间接消除密码的实践方式吧。

登录,现在实实在在地成为了一个独立的工程。尤其在形态多样的基于Web的应用,以及这些Web应用本身所依赖的各色后端服务快速生长的过程中,各种鉴权需求随之而来。如何在保障各个环节中安全的同时,又为用户提供良好的体验,成为一个挑战。

另外,个人信息泄露的事件频繁被曝光,它们导致的社会问题也开始被更多人关注和重视,作为IT系统支撑者的工程师们有责任了解事关安全的基础知识,并掌握必要的技能去保护用户数据和企业利益。

我会在接下来的文章中介绍解决典型登录需求的具体技术方案,以及相关领域的安全实践常识。


更多精彩洞见,请关注微信公众号:思特沃克

Share

致测试同仁们:让我们一起做安全测试吧!

本文首发于InfoQ:

http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safety-test

今天,很多的软件并没有经过专门的安全测试就被放到互联网上,它们携带着各类安全漏洞暴露在公众面前,其中一些漏洞甚至直指软件所承载的核心敏感信息或业务逻辑。这些漏洞一旦被不怀好意者利用,很可能会给企业造成经济损失。带来负面声誉影响的同时,还可能被起诉、遭到罚款等等,细思极恐。其中的一部分原因是企业本身安全意识不强,但是很多时候虽然软件企业已经开始意识到这些问题,却苦于缺少专业的安全测试人员,他们不得不冒着极大的风险先上线赌一把运气再说。

既然如此,作为质量代言人的我们,怎能对此置之不理呢?

你也许会问?怎么理?安全测试水太深了。

安全测试并不遥远

是的,安全测试在软件测试里面是一个很特别的科目(或作“工种”),很多人都觉得这个科目应该全权交给神秘的安全测试人员来管。这个观念导致很多测试人员徘徊在安全测试的门口却迟迟不进去,包括我自己。

直到后来,我非常有幸能够在不同规模的软件开发项目上跟“神秘的安全测试人员”学习如何进行安全测试,发现“神秘的安全测试人员”不光是名字跟我们一样都有“测试”二字,所做的事情在本质上也跟我们测试人员有很多相通之处。

想想看我们都做过什么:

我们修改过url的参数,对不对?他们也是!
我们在数据输入处提供过不合法的数据,对不对?他们也是!
我们尝试过修改只读数据,对不对?他们也是!
我们也测过用户会话是否如期timeout,对不对?他们也是!

Ok,这还不是全部。他们也做测试计划、测试用例设计、bug分析与管理等等。所以,安全测试离我们并没有那么遥远。

当然,我必须承认,安全测试是非常复杂的。一个专业的安全测试专家在某种程度上来说是一个全栈工程师。所以,想要在安全测试上一夜成才不太容易。不过好消息是,作为测试人员的我们却有得天独厚的优势,使我们能够在安全测试上快速起步,帮助团队尽快展开预防并检测安全漏洞的工作。
在这里我想要跟大家分享一下在敏捷开发团队中如何利用我们的测试经验开展安全测试。

安全测试并不陌生

首先,让我们先来了解什么是安全测试,我们作为测试人员有什么可以直接用上的技能和经验。
简单来说,安全测试其实就是一个发现软件安全漏洞的过程,旨在保护软件系统的数据与功能。它跟常规测试相似的地方至少有以下几点:

No. Summary Details
1 目标类似 预防、检测系统的缺陷(尽早、频繁反馈系统质量信息)
2 在软件生命周期中的工作过程类似(以敏捷团队为例) -了解系统业务需求
-针对业务与系统功能设计用例
-与其他角色一起启动需求的开发
-与其他角色一起在开发环境验收需求
-在测试环境进行全面测试
-分析并总结测试结果
-反馈测试结果
3 测试用例有很多重合 面向用户的测试场景非常类似
4 都需要有探索的过程 对会对不同的业务场景有目的的进行探索
5 都要有测试人员必备的“怀疑态度” 对开发人员的代码保持友好而警惕的态度

1. 目标类似
不管是常规测试还是安全测试,都有一个原则:预防胜于检测。这个比较容易理解,不管是常规测试的缺陷也好,还是安全测试的漏洞也好,如果能预防使它不发生,就省了后期的修复与验证工作。如果不能成功的预防缺陷,能早一些发现的话,肯定比晚发现的修复的成本低。

2. 在软件生命周期中的过程类似

以敏捷开发团队为例,常规测试人员在各个阶段做的事情,安全测试人员也要做:

  • 了解业务的需求,以避免混乱的测试优先级;
  • 针对业务与系统功能设计用例:常规测试需要关注系统功能,安全测试同样也不能脱离系统功能;
  • 与其他角色一起启动需求的开发:沟通测试用例,避免因为沟通不足造成返工;
  • 与其他角色一起在开发环境验收需求:尽早提供反馈,发现缺陷时开发可以马上修正
  • 在测试环境进行全面测试:针对端到端的场景进行测试,尽可能把第三方系统(如果有的话)也包括进来;
  • 分析并总结测试结果:整理问题清单,排列优先级;
  • 反馈测试结果:把测试结果反馈给团队等干系人。

3. 测试用例很多重合

在面向终端用户的测试场景上,常规测试的用例与安全测试的用例是非常类似的。比如对于登录系统的功能,不管是常规测试还是安全测试,我们都会测试用户输入正确的用户名是否可以登录,输入错误的用户名或密码系统会如何反应。

比如我曾经工作的一个搜集报税人信息的系统,不管是常规测试还是安全测试,都会测试系统的登录,系统信息的录入与编辑,文件的上传等等。因为在每一个终端用户可以操作的场景上,都可能会有安全漏洞存在。所以,有了常规测试的经验,我们就相当于有了不少安全测试用例的储备。

4. 都需要有探索的过程

测试是一个了解软件系统能否完成我们预期的过程,也是探索系统还有哪些我们没有预期的行为的过程。安全测试的过程需要把探索的目标转向安全漏洞。当我们这么做时,我们同样会得到很多探索的乐趣。

5. 都要有测试人员必备的“怀疑态度”

相信咱们测试人员都非常熟悉一个场景--开发人员说:“我只做了一个很小的代码改动。”然后我们带着友好而警惕的态度,发现这个“很小的改动”引发了很大的问题。不管是在安全测试还是非安全测试,这个警惕性是我们都需要保持的良好传统。

那么,有了这么多类似的地方,还缺什么呢?如果想要做专家,还差很多。但是如果想马上安全测试上起步,我们可以先做下面的改变。

安全测试从何做起

第一,转换视角

在我看来,不管是带着全栈的经验,还是只有部分技术知识,想要做好安全测试必须先转换我们观察软件的视角。举个例子,让我们看看下这幅画:

(图片来自:http://imgur.com/gallery/ZCgQ3)

同样一幅画,有人一眼看过去看到的是两个人脸,而有人看到的是一个花瓶。这就是观察视角的不同造成的。

在我刚开始接触安全测试时就很深的体会到了这一点。当时我在测试一个Web应用的用户登录功能。当我输入错误的用户名来试着登陆时,浏览器上的提示信息为“该用户名不存在”。当我尝试正确的用户名而错误的密码时,提示信息变成“密码输入错误。”对于这个清晰的错误提示我非常满意。试想我若是一个真实的终端用户,这个信息有效的帮助我缩小纠错范围,提高效率,非常好。

可是,就在我身边坐着的安全测试人员马上跳了出来:“这个提示信息需要改!敏感信息暴露了!”看到我一脸茫然,这位安全测试人员告诉我,通过我们的提示信息,恶意的系统使用者可以推测出哪些用户名已经存在于系统中,然后利用这些用户名可以再进行密码的暴力破解,缩小破解的范围。所以,这个信息虽然为合法用户提供了便利,也为不怀好意的系统使用者提供了便利。而往往这种便利为恶意的系统使用者带来的好处远大于给合法用户带来的好处。

这个经历在让我受震动的同时,也使我意识到可能很多安全漏洞之前就摆在我的面前了,我却没有看出来,因为我把它们过滤了。事实证明,在后来经历的不同项目中,当我转换了视角,有些安全漏洞不需要我去找,而是自己跑到我眼前来的。真是得来全不费功夫。

第二,改变测试中模拟的对象

为了能从不同的视角来观察软件,我们必须改变我们所模拟的对象。这也是一个让我们刻意练习转换视角的有效方法。

我们在做非安全测试的时候通常把自己想象成一个合法用户,然后开始验证系统是否能完成预设的目标。比如对于一个网上商城,我们会验证系统是否能让用户完成商品的浏览与购买,我们也会测试一些异常的行为,比如购买的商品数量不是数字而是一串无意义的字母时,看系统是否能比较优雅的做出回应。我们这么测试的目的往往是为了确保用户误操作以后还能够继续他们的购买,或者说不要给系统造成什么严重的伤害。

如果要做安全测试,我们则必须去模拟系统的另一类使用者-恶意用户。他们的目的是寻找系统中可钻的漏洞。比如同样是一个网上商城,恶意用户的目标之一就是要想办法以较少的钱,甚至不付钱就能拿到商品。所以,如果恶意用户进行了“误操作”,他们不会停留在“误操作”,而是通过“误操作”来看系统是否给自己提供更多的线索。

所以,我们需要转换测试时所模拟的对象,把思维从一个合法用户的视角中拉出来,转换成一个恶意用户。这需要一点时间,就如同之前看到的画,如果我们一开始看到的是人脸,要想下一次第一眼看到的是花瓶,我们需要时间来刻意练习。

第三,使用专用的测试工具

有了思维的转换,我们可以加入新的测试想法。但是,在具体做安全测试的时候我们会发现并不是那么容易去模拟恶意用户的行为。毕竟系统的前端会给我们设置很多的屏障。而且恶意用户可不总是从系统前门进去的。这时候,使用一些工具,比如OWASP Zap(https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project)、Burp(https://portswigger.net/burp/)等是非常有帮助的。我们可以在系统界面上执行功能测试的用例,用这些工具来获取http请求,篡改后发送给后台服务器。有了这些实用又比较容易上手的工具,我们就可以执行很多恶意用户的操作场景了。

能做到这三点,起步就基本够用了。

举个栗子吧🌰

下面让我们以网上商城的买家在商品评价中上传图片这个功能来讲讲如何实践这“三板斧”。假设我们从项目初期就加入了,那么我们大致有七件事情要做:

  1. 识别系统中有价值的数据;
  2. 在需求分析阶段加入恶意用户需求;
  3. 针对恶意用户需求设计测试用例;
  4. 参与启动恶意需求的开发;
  5. 在开发环境验收恶意需求的实现;
  6. 在测试环境中进行安全测试;
  7. 向团队反馈所发现的安全漏洞。

不要担心,这不是7个全新的事情。只是在每个需要测试人员出现的地方增加了安全的工作而已。

1. 识别系统中有价值的数据
很多人认为执行测试才是测试,而我们的安全测试从这里就开始了。
了解业务之后,我们需要考虑系统中会有什么有价值的数据。这是为下一步加入恶意用户需求做准备。对于一个网上商城,有价值的数据可能包括产品信息、订单信息、用户信息、支付,等等。
这个环节对我们测试人员来说并没有太多额外的工作,毕竟我们做非安全测试的时候也需要了解业务。不过要注意了,我们要测试的“图片上传功能”是一个涉及有价值数据的功能。我们需要提高警惕了。

2. 在需求阶段加入恶意用户需求
恶意用户需求是用来记录恶意用户想要在系统中达到的目的。与普通用户需求的区别是,我们不是要去实现它,而是使用它来帮助我们远离对系统使用者“不恰当的信任”。通常我们需要针对每一个合法用户需求来增加一个或多个相对应的恶意用户需求。


举个例子,如果我们这个“图片上传功能”的合法用户需求为:作为一个买家,我想在对商品进行评价的时候上传图片作为买家秀,以便于参加返现营销活动。那么对应的恶意用户需求可以是:为一个恶意用户,我想破坏买家秀返现活动,以便破坏商城的营销活动。“破坏买家秀返现活动”是一个大的目标。为了设计用例方便,它可以被细分为一系列小目标。比如让用户无法上传图片、让页面无法正确显示图片等等。

有了恶意用户需求的主干信息,我们就可以开始下一步设计安全测试用例了。

3. 针对“恶意用户需求”设计测试用例
现在我们需要做的是努力把自己限制在“恶意用户”的角度做头脑风暴:“到底有什么方法可以使买家无法上传图片信息呢?”, “让页面无法正确显示买家秀图片又怎么做到?”嗯,也许最直接的办法就是让服务器所在的机房断电、断网之类的。这是些不错的想法,虽然执行难度有点大。没关系,记录下来。除此之外,我们还可以有其他测试用例,比如:

  • 使存储图片的磁盘空间被占满而无法接受新的图片;
  • 使处理上传图片的进程繁忙而无法接受新的上传任务;
  • 上传特别大的图片使用户的客户端需要很长时间才能下载完
  • 上传伪装成图片的恶意代码,进一步获取服务器权限,删除所有的买家秀图片;
  • 等等

如果这个时候想到新的测试用例也同样记录下来,比如“我想不购买也上传买家秀图片以获得返现”之类的。
不用太担心这个阶段的测试用例过于“疯狂”或者不够完整,毕竟我们对于系统的实现还不是很了解。我们会在接下来的环节中完善具体的步骤。

4. 参与启动恶意需求的开发(evil story kickoff)
在开发人员开始开发合法用户需求之前,我们需要跟业务分析人员、开发人员一起沟通需求的内容。在敏捷软件开发项目中我们叫它story kickoff,即用户故事启动。当有了对应的恶意用户需求时,我们必然也要把它也加到启动的范围里。目的是把我们头脑风暴出来的测试用例跟所有的角色来沟通。预防胜于检测。

5. 在开发环境验收恶意需求的实现

100%预防软件的缺陷与漏洞是不太可能的,所以这个环节的存在是为了提早反馈。
我曾经经历过一个项目,都快上线了才决定做安全测试,结果测出来的问题之一是用户会话(user session)不能正确过期的问题,经过一番研究,发现需要对系统设计的架构进行比较大的修改,只能做个临时的修复让系统先上线,然后再把系统的架构给改了,重写这部分功能,重新测试。代价非常高。所以不管是安全测试还是非安全测试,”在开发环境验收恶意需求的实现“这个步骤都不能缺少。

而这个环节存在的第二个目的是让我们可以从开发人员那里得到支持-具体实施的细节,帮助我们完善具体的测试用例。比如在这个时间点我们若从开发人员那里得知系统的后台没有对图片上传者做身份验证,我们就可以至少增加一个测试的用例:“恶意用户以其他用户的身份上传一个风马牛不相及的图片”。有时候错误的图片比没有图片更具有杀伤力。

6. 在测试环境中进行安全测试
终于到了运行测试的阶段。可能这个时候我们之前想到的测试用例已经被开发人员给解决了。如果是这样那就太好了。但是,事实并非有这么美好。第一,可能这些用例只是在开发环境上成功通过了,但是在理想的测试环境里,也就是类产品环境里,这些用例可能并不能完全通过;第二,肯定还有其他需要探索的地方。这时我们就可以用OWASP Zap、Burp这样的工具来辅助我们把之前的安全测试用例执行一次,同时还再可以对系统的安全性做一下探索测试。

7. 向团队反馈所发现的安全漏洞
都测得差不多的时候,我们就可以向团队以及相关干系人汇报安全测试的结果了。跟非安全测试不同的地方是,当我们反馈安全漏洞的时候,要考虑不同漏洞结合起来是否会增加系统的安全风险。举个例子:如果有两个安全漏洞,一个是系统没有很强的用户账户密码规规则,另一个是系统没有对上传图片的大小做限制,那么恶意用户把这两个漏洞一结合起来,事情就比原来风险大很多。那么我们就必须建议提高这两个漏洞中任意一个的优先级。

当我们用“三板斧”走完这七步以后,我们已经可以把很多安全漏洞都挖出来了。是不是没有想象中的难?所以,测试同仁们,让我们做安全测试吧!

Share