12月3日，由永安在线举办的首届API安全管理论坛在深圳举办。四位大咖围绕API面临的挑战及如何进行API安全管理进行了精彩分享。其中，腾讯技术工程事业群安全专家胡珀在论坛上作了主题为《新的安全威胁：API安全的挑战和应对策略》的分享，我们对现场演讲全文进行了梳理，以供更多关注API安全管理的人共同学习。

本次演讲的完整版PPT，可通过“永安在线情报平台”公众号获得

演讲全文：

我先做一个自我介绍，我叫胡珀，是来自腾讯 TEG安全平台部，有超过 15 年的网络安全经验，在 07 年大学毕业之后，就加入到腾讯安全平台部，然后一直在从事基础安全体系方面的工作。

大家都知道，07年是 Web 2.0 的时代， Web 2.0时代的最大的问题 Web 安全，而Web API 安全就是Web安全中的一大类。从 07 年开始，我们已经在研究这方面的工作，只是最近几年才把API安全单拎出来讲。今天就将API安全这部分给大家做一个分享，也是我们团队以及我个人的一点经验之谈。

下面我将从三个方面来分享，一是API 的概念，二是风险案例，最后是安全实践。

API的起源

API 的起源得从1940 年开始。我在维基百科上考古了一下，其实在1940 年的英国，他们以前的代码不是现在这样打，而是在子弹上打孔。他当时他们用了个文件柜，把这种打孔的程序放到里面去，然后有一个目录告诉调用者，你这个东西放在哪个柜子里面，是哪个颜色袋子什么样的东西，他们把这东西叫做 API ，这是我们目前能找到的API最老的起源，大家可以去维基百科上详细一下。

其实1940年和现在的对 API 定义是一致的。所以说我们认为它不是一个新的概念，它只是经过几十年的技术的演进，到了今天的样子。下面，我们可以看一下 API 的一些定义，它其实是定义成一种函数协议，数据结构就明确主要是给调用者一个使用的。

API 其实会分很多类。比如说 90 年代到2000年左右那个时候 Windows 程序比较多，例如mqc，这种 API 其实就是一种 API 函数，在 Windows 下面。再比如说后来验证中经常出现的数据库，dbc这种，还有操作系统的 API 。我们现在说的最多的包括今天我们主题讲的甚至整个行业里面探讨的 API ，其实是指基于 Web 应用的API ，在网上的一个报告中显示， API 的增长速度非常快，在2021 年可以看到它比上一年度是同比增长了39%。

Web2.0时代，其实它是一个奠基的时代，那个时候已经有 API 了。我们来分享一些案例。当年在QQ 空间其实已经大量使用了 API 的技术，并且有一些 API 的安全风险，也有人利用这些 API 来做些事情。然后到 2010 年移动互联网时代，移动互联网时代有一个特点，就是 PC 端向终端演进，这个时候催生了大量的交互技术，比如说过去我的 Web2.0里面可能我用的是ASP、PHP ，这种动态的服务端程序。但是在2010 年之后，移动端其实是会大量使用类似ajax的，既然是 ajax ，肯定会有一个 API 跟他对接，这个时候API就大量的发展。然后在2020 年之后，像云原生、大数据、物联网包括这种微服务， DevOps 的这种里面它会提倡微服务，就更加会有大量的互相之间调用API。

导致API安全形势严峻的四个原因

再回到我们为什么要关注 API这个问题？很简单，因为公司现在有大量的 API ，所以我们就必须去关注它。同时，API安全的形势目前也比较严峻。这主要由四个因素导致：

一是外国黑客紧盯。为什么呢？因为 API 它其实承载了大量重要的数据，这种情况自然会被黑客攻击。

第二是能力沉淀不足。其实我们程序员开发同学他在编码的时候，很多时候他可能就没想到这个 API 是我要特殊对待的，这个时候就会出问题了。

第三是API 的治理功能还没有跟上。因为业务发展很快，安全不一定跟得上，比如说公司大量使用 API 的时候，可能我们的安全团队还在解决 SQL 注入的问题，还没想过解决数据安全的问题，还在做反入侵、HS，这个时候根本就没想到 API 怎么还会出问题。这其实就体现了 API 的治理能力没跟上。此外，API 其实可以分成两类，一类我理解是在互联网上能够公开访问的，就是给到用户端可以交互的，这是一类。第二类是在系统内部、服务之间，也就是一类所谓的东西流向之间，微服务之间这样的 API ，这两个需要用不同的方法来解决。

最后是自身安全机制问题，在设计时未考虑到安全。据一些调查报告显示，有 55% 的 API 其实是没有经过安全测试的，很有可能这些企业可能根本不知道 API 要单独测试，没想过这个问题。然后就用扫描器扫，扫完有可能根本扫不到。

我们来看一个风险案例，还是刚才我说的QQ空间的。API 它其实是一个 Web API 就是一个特殊的 cgi ，在以前很多SNS 社区 UGC 业务就大量使用这种 API 。比如 QQ 空间以前的某个业务，这个业务的一个cgi它会返回一堆 JS 代码，里面可能会包括当前访问的 QQ 号。这里就有一个问题，如果我在一个网页输出这个页面，然后让他去访问JS 就可以拿到我的 QQ 号。这是一种常见的溯源手段，就是利用社交网络的JSON Hijacking 漏洞去获取个人信息。后面我反应过来，实际上这个就是 API 安全范畴。我们当年天天挖的漏洞就是一个 API 安全问题，它其实就是一个输出 JSON P 格式的一个特殊的API互相之间去调用。然后 QQ 空间还有一个业务，比如说我们进入别人空间的时候，需要输入他的问题的答案。你可能不一定知道，但是如果用这种 JSON Hijacking漏洞的话，其实也是有可能拿到答案的。

这个案例是十年以前的了，问题早就已经修复。但这些案例主要是想说明，其实 API 安全它不是一个新的概念，只是大家已经越来越重视而已。第二， API 它本质其实还是一个 cgi，传统的安全漏洞都会出现在它上面。比如这里我举的这个JSON Hijacking，然后还有包括SQL注入、XSS、XXE都会出现。然后还有另外的案例，比如 Facebook 的 API 爆出漏洞导致个人信息泄露。很多时候我们会通过 API 去输出一些信息，如果你权限控制不当或者其他原因，他都能通过你的 API 把你的信息给拉走。

解决的方法前面我讲过一些，可以通过传统的方式，比如说用扫描器去扫或者用WAF来防，可以做一定缓解，但不一定全。为什么呢？比如说通过 API 泄露的一些数据，这个时候如果黑产要来拿这些数据，他一定会调集大量的机器来拖这些数据，会产生流量上的异常。或许通过流量可以发现，但是这里有个前提，就是我们大部分的WAF，可能是不会去关注这种问题的，那就解决不了问题。

第二个你得知道这个 cgi 是一个 API ，才可能会去重点关注他的流量异常。如果是一个无关紧要的，那他流量异常也没什么问题，所以说这其实是一个挑战。鉴权漏洞也是一样，跟普通的其实也没什么区别，无非就是发生在 API 上面。

还有很多新兴的系统，都会使用 API 。比如说之前我们就监控到很多的蠕虫病毒都会去攻击某些系统的 API ，因为这些系统可能在设计之初他都没有安全机制。包括我看到Docker API 、k8s API列出来的大部分是没有鉴权的或是弱鉴权，默认情况下只要我能访问到他端口，给他发这个数据去他就认，然后就会导致机器被黑或者被控制。这其实就是开发同学在设计这个系统之初可能就没有想过我是不是去做鉴权。

还有一种就是DDOS攻击，对 API 为什么会有DDOS攻击呢？因为 API 它承接了很重要的业务，可能它会很消耗资源，我可能去读的东西，但是同时 API 一般作为跟客户端 App 的交互接口。就比如说我在 App 去拉 Web页面的一个 cgi然后去拿到一些数据。这个 App 我不一定会用流量去拉，可能就自己写一个接口，比如就是一个 C 代码，我框架里面不是浏览器。对传统 web 页面，它遭到 CC 攻击之后，可能就会下一个 JS 或者下一个验证码。然后让浏览器去访问，如果浏览器能够执行，就说明客户端是浏览器，因为 CC 攻击端它一般不会掉浏览器，它一般会自己写一个程序。这个时候如果遇到验证码或者是遇到JS 是没法去解析和执行的，然后就可以判断出谁是攻击者或者是谁是机器人，谁是正常的人。

但是问题来了，如果我的 App 去拉这个 cgi ，这个 App 本身我是用我自己写的程序实现的接收响应，而不是用浏览器。这个时候我的 App 他会认为这个 App 是个机器人，也是攻击方，也会把它拦掉，所以说这里就有问题。所以如果针对 API 有 CC 攻击，其实还是很难防的。因为很容易就把真实用户给杀掉了。基于我们的一些经验，这个其实也是一个挑战，实际上就是传统的防御方法不一定能够防 API ，必须得有一定新的思路。

总结一下， API 需要关注的安全挑战跟传统的web完全不一样的地方有以下几个：一个是在设计时，就忽略了这是一个 API ，可能就没去去专门的对它做一些安全的设计，比如它出数据的时候，我是不是要对数据进行监控，是不是要有一个阈值，比如说这个量太大了会不会有问题，这个就是 API 的服务治理难。还有就是对外的 API 怎么去识别它是一个 API ，这也是个难点。因为传统的不管是 WAF 也好，扫描器也好，它是没有这个功能的。

另外一个是我们内部东西向的 API 其实是很多的，然后怎么去识别和治理它，也是有问题的。还有一个就是自动化的测试难，比如说我们去测这个 web 安全，肯定是上扫描器。但是如果这个接口是个 API 的话，首先扫描器它利用爬虫不一定能爬到这个接口，它根本不知道你的参数，各种交互它也是不知道的，既然它逻辑都跑不起来，对 API 就更没法去跑。以上就是腾讯过去遇到的一些难点。此外也需要注意Owasp API Securiy top 10里面的风险问题，都是需要去重点关注解决的。

API安全需要关注哪些领域和关键点

API 要关注哪个领域？我们从网络安全、应用安全开发和监管合规上面大概进行了分类。网络安全上就是通信安全端需要通信加密，你不能用弱密码。然后DDOS防护和 CC 防护特别得注意，可以重点关注CC防护。因为根据我们的经验，黑客打这个网站，肯定会先找你一个很好资源的 API 然后再拼命的拉起这个页面把你拉垮。有两类情况，一类他为了打垮你，进行DDOS攻击。第二类就是黑客在拖你的数据，然后你的服务比较脆弱扛不住了，他疯狂地拖，就会产生DDOS的情况，这实际上是一个数据泄露的情况。

还有流量安全可以在流量层面去检测，对 API 安全做一些发现和加固。然后应用安全层面包括我们使用 API 网关、用服务网格去治理以及用WAF。还有就是需要依托威胁情报。就像腾讯的安全体系已经那么全面，但为什么我们还要建立安全响应应急中心，做 TSC 跟白帽子交互，让白帽子来暴漏洞？就是因为我们需要这些威胁情报来作为补充，因为不管你的这个安全体系如何的全面，如何的强大，一定会有疏漏，这个疏漏就需要找威胁情报来帮我们查缺补漏。另外一个是安全开发。现在 DevOps 很火，那就把 API 安全放进去做一个全流程的管理。然后监管合规就不细说了，现在国家对数据安全的重视程度决定了必须对 API 这种数据的输出大家都要特别的注意。

DevOps刚才也提到，目前在腾讯内部我们也是在按各个事业群在推这种 DevOps ，就是所谓安全左移的一些方案。根据不同的事业群，他的技术架构和当前的 DevOps 的能力是每个事业群是不一样的。在 API 安全这一部分，我们基本上还是依托于这几个方向尽量做一些事情：计划创建、验证、发布响应阶段。

其实跟 DevOps 的传统的框架是一样的，无非就是针对 API 做了一些事情，原因不过就是过去我没有针对他。比如说我在 API 设计的时候，我要想到他必须要建全端设计怎么样，然后编码的时候也是一样，API它本质上是一端代码，它一定会出漏洞的。至于怎么弄，大家可以参考一下腾讯的代码安全指南，这个已经开源了，大家可以去找一下参考学习以及提出更多建议。

然后就是框架。腾讯内部有一套开发框架，现在也是在推全公司来接入。我们在框架层面做了很多事情，比如从 API 产生这个阶段开始，我们做了默认有鉴权，默认就可以防注入。另外一个就是那个在测试阶段，因为 API 数量大，传统的扫描器查不到，我们主要是通过流量来查。另外可以结合公司的 API 网关直接把数据给我们。再通过就流量来查缺补漏，这样相对会比较全一点。总的来说如果想把API安全真正的阻移，一定要跟公司的基础设施结合起来。另外一个是WAF，我们的WAF分两类，南北向的直接在上面加一个 API 安全的功能；如果是东西向的，就跟公司的 API 网关结合。

实际上 API 服务的治理主要就是依托 API 网关。如果企业里面的 API 特别多，我建议得具备 API 网关。但前提是，你要保证所有的 API 都经过API网关。

还有另外一个是在流量层面。因为前面我也提到我们不管是 API 也好，web的 cgi 也好，其实很难把它全部爬到。这个时候在流量里面去把他们抓下来是非常重要的查缺补漏的方式。其实 API 流量监测跟传统的流量系统没什么大的区别，无非就是对 API 做一个单独的定制。然后一般这种 API 的流量监测有两种方式，一种是串联在链路上，一种是旁路上，一般我们会推荐旁路。如果公司流量比较小，那串联无所谓，但从过往经历来说腾讯不适合串联。同时如果你跟网关旁路对接的话，也可以让网关把 SSL 流量加密，流量卸载掉之后，再来进行识别。大家可以看一下流量侧的API发现的框架。

那对 CC 攻击怎么办呢？如果 CC 攻击打这个 API 正好我的客户端运气不好，我又没有调浏览器，那就只有先去通过一些其他特征，比如通过操作系统指纹、设备指纹或者其他办法去识别出它到底是不是一个人或者是不是一个机器人。另外就是可以通过流量里面去自动识别它是 API ，识别到之后会针对这个 API 做安全策略，而不会给他去下验证码之类的。因为之前我们在没有做这个事情的时候，有些时候 App 被攻击之后，我们的防护系统会给他下验证码，结果它根本不会响应，整个业务就瘫掉了。这样子做了之后至少业务不会挂，然后我们再慢慢地去对抗这些CC攻击。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)