开放平台的安全性考量 （上）

 

来源：unclejoey.com    作者：Uncle Joey

前言

       开放平台概念由来已久。个人第一次接触开放平台开发是在2004年，使用当时如日中天的eBay API为eBay卖家开发管理工具。后来几年又陆续使用过国外的几家电子商务厂商、SNS社交类网站以及Google提供的开放API。近几年来，国内的 开放平台概念越来越热。主要集中在三类网站。一类是社交类。例如人人、开心和各个微博平台。主要是Facebook和Twitter在开放方面取得的巨大 成功让这些网站看到了一个可能的方向。另外一类是搜索引擎，主要是百度的框运算。第三类是电子商务，以淘宝的TOP（Taobao Open Platform）为代表。

        一家网站可能在一开始就有意识地走开放之路，希望构造一个宏大的生态圈，吸引到更多的第三方开发者和独立软件提供商到这个生态圈中发展，从而形成良 性循环。也有可能在一开始只是业务需要，要在组织机构以外做数据交换或者支持客户做二次开发。但是不管目的怎样，开放平台在系统结构上，有很多共同的地 方。稳定性、高可用性、性能等ility要素都是在开放平台架构设计时需要考虑的。但是作为面向组织外客户的API开放，安全性（security）却一 定是架构师在做Balance时首先和优先考虑的ility属性。

我所工作的网站Active.com主要服务于北美用户。从2009年开始，我们陆续开始了自己的开放之路。目前我们所做的工作还远远称不上“平 台”，但是也毕竟在开放这条路上迈出了第一步。作为开放平台的观察者、开发者和设计者，安全一直是我最感兴趣的部分。昨天从北京参加完淘宝2011开放年 发布会之后，我一直在想把自己对这一块的思考整理一下，算是对自己学习过程的一个总结回顾。

开放平台的系统角色

一个开放平台架构所针对的系统角色简单来讲有以下几类：

1. 1. 网站 提供基础用户和服务的网站
2. 2. 服务  网站内部的某个用于完成业务或者提供数据的服务接口。一般根据数据格式有SOAP, XML, JSON等。使用HTTP协议进行访问，因此都是无状态的（Stateless）。
3. 3. 开放平台 内部服务通过接入开放平台，实现向外部用户提供服务。平台需要负责完成接收请求，身份校验，权限检查，流量控制，行为监控，服务转发，返回结果等一系列工 作，是整个开放平台架构的核心应用。某些“平台”功能相对简单，直接开发独立的专门针对外部用户的服务，这种实际上是把平台和单个服务在物理上合二为一。
4. 4. 第三方应用 第三方应用系统通过平台入口，访问到内部服务，从而完成跨企业域的业务整合。比如开发者为新浪微博开发的应用，可以使用自己的域名，独立运行在第三方服务器上，但是依然可以通过远程API调用完成业务功能。
5. 5. 用户 用户在此指网站用户，同时他们可能会使用第三方应用访问自己的数据，或者完成其网站业务。在电子商务系统中，用户还需要分为2类，A类用户为业务的提供 方，通常需要利用网站和第三方应用向其他用户提供业务；例如淘宝卖家。B类就是业务的接收方，利用网站和第三方应用接收A类用户提供的业务；例如淘宝买 家。

开放平台的身份认证体系 (Authentication of Open Platform)

 

身份认证(Authentication)是开放平台安全体系中的第一道关卡。作为独立的安全主体，开放平台对来自安全边界（Security Boundary）以外的每一次访问请求都需要做独立的身份认证，因为我们这里所谈的开放API都是通过无状态的HTTP协议进行的。

通常我们需要认证两类身份：一类身份是应用身份，一类是用户身份。

针对应用身份的认证 一般是通过一个应用票据（App Token or App Key）完成的。这个Token由平台颁发给对应的应用开发者，并由第三方应用进行保管。平台负责该票据的审核生成、发放与生命周期管理。在每次API请 求的时候，由第三方应用负责在该次请求中携带该票据，并由开放平台完成票据验证。这个机制中，需要开放平台生成的应用票据具备以下特性以确保安全：

1. 1. 唯一标示。每个Token必须唯一标示一个指定的应用以防止身份冒用。
2. 2. 不可猜测。这个Token的生成必须有随机因子，使得它不可被猜测。例如，使用开发者用户名和时间哈希生成的Token，就是一个不安全的Token.
3. 3. 票据的有效性验证必须基于持久化比对，不能基于算法。尽管持久化票据并且读取比对存在一定的性能问题，但是这个可以依靠Cache予以解决。如果对票据不 做持久化，而仅仅依靠算法保证其有效性，那么算法的泄密（通过前员工，逆向工程，代码泄露等）必然导致整个系统再无任何安全性可言。
4. 4. 如有可能，附加验证。很多时候对于应用的身份验证只是基于1个secret确实显得不太安全。因为这意味着一旦App Token泄露，应用身份就有可能被盗用。所以如有可能的情况下，开放平台应对App Token身份认真做附加验证，例如来源IP或者域名。针对来源域名做验证时，不要信任Http头中的Referrer，而应该去检查预设应用域名是否被 解析到来源IP地址。因为前者是可以被伪造的。针对分布式应用，考虑采用白名单和地址段的方式会有所帮助。
5. *5. 时效性。尽管很多开放平台基于方便开发者的考虑，对App Token的时效性没有做过多要求，也就是说永久有效。但是从安全管理的角度，为Token设置一个有效期并且实施过期提醒策略，督促第三方开发者更新 App Token，是非常有必要的。过期时间不宜太短，一般12个月左右对大部分开发者来说是可以接受的。
6. *6. 提供App Token暂时失效能力。供第三方开发者发现身份被盗用后迅速切断API盗用。这个能力作为开放平台的内部管理能力，供平台运维团队处理紧急情况使用。

针对用户身份的认证 目前也有很多解决方案。其中oAuth是目前被广泛采用的一个解决思路。基本思路就是由第三 方应用将用户重定向至平台的制定页面（在母网站域内），用户在登录后完成授权生成授权Token，然后由平台重定向用户至第三方应用并携带Access Token. 此后的第三方应用就可以凭借Access Token以用户身份访问开放API。oAuth有很多种实现，无论采取哪种方案，在实际实施中，需要注意的安全性问题有：

1. 1. 注意oAuth 1.0是不安全的。其授权过程可被截断并予以伪造（俗称的session fixation攻击）。1.0 A修正了这个问题。当然如果有兴趣的话，可以看看最新的2.0规范。更新版的1.0a和2.0都已经成为RFC标准。实施时不一定严格遵守，但是了解其原 理和安全改进是必须的！
2. 2. 注意授权页面的CSRF问题。这个问题很多平台都有过，严重程度不用多说。这也是为什么oAuth标准中一定有一个看似没有用处且影响性能的 Request Token。还是那句话，自己实现没有问题，也不一定需要一定严格遵守RFC，但是一定要明白为什么RFC这样设计。
3. 3. 尽量使用Http Header而不是Query String传递参数。
4. 4. 控制时效性。需要结合业务，对重要业务，尽可能地避免长效Token以保护用户。在很多情况下，牺牲用户体验是必须做出的艰难选择。看一看支持本地Cookie免登录的电子商务网站，在下单和支付时又需要再次登录，就能理解这一点了。

oAuth认证针对移动应用和桌面应用意义不是很大。尽管2.0规范中已经为此增加了几种新的Workflow，但是个人认为用户体验都很差。针对 这种需求，只能具体问题具体分析，一个建议是，不到万不得已，不要轻易开放支持Http Basic的API。有可能今天这个开发者是非常值得信赖的，但是口子一旦开放，就再也难以回头，只能越来越糟。解决这一问题的思路主要有：

1. 1. PIN码验证。对桌面应用比较有效，参见新浪的实现方式。
2. 2. 移动终端的验证中心应用。由用户在第三方应用上提出授权申请，再在官方应用（或者移动网站）的授权中心进行授权，开放平台在接到授权指令后通过后台推送 Access Token到第三方应用接口，完成授权。这种方式对移动终端较为方便。用户体验在可接受的范围之内。
3. 3. 建议开发者不要再开发桌面应用。

 

开放平台的授权机制（Authorization of Open Platform）

 

相对于认证（Authentication）来说，授权（Authorization）是一个更为复杂的过程。各种应用之间的用户角色、用户组、权限交叉在一起，看上去很容易让人眼花缭乱迷失方向。作为开放平台的设计者和开发者，需要捋清头绪，分清楚主要矛盾和次要矛盾。

开放平台所需要解决的第一个授权问题，就是某应用究竟是否有权限访问某API。在平台上接入的API，应该根据企业的业务划分，应用的开发者等级， 以及实际业务需要，授权给尽可能小的应用群体。也就是所谓的最小化授权。这种授权可以由平台通过简单的对应完成。为了较少维护成本，也可以对应用和API 划分不同的安全等级，高等级的应用可以访问的API是低等级应用被授权API的超集。

在实际开发中，我们甚至考虑过由平台做Function粒度的授权控制。但是后来发现这样做成本太高，而且没有必要。让API开发者去做他们该做的 事情。平台所需要做的事情，不是提供一个万能的权限管理机制（相信我，这样会死人的，我试过），而是完成自己该做的事情，把正确的访问请求，访问者身份和 访问参数，转交给服务提供者。