在五月初，健身企业Peloton表示他们客户的账户数据被暴露在互联网上。任何人都能从Peloton的服务器接入用户账户数据——即使这些用户将他们的账户设置为“隐私”。而起原因则是某个出现问题的API许可了未经认证的请求。

　　API可以实现简单的机器对机器的交流。API使用最近呈爆炸性增长。根据Akamai的调查，API交互已经占所有互联网流量的83%。

　　API也导致了大量的安全问题。除了Peloton之外，其他涉及API安全问题的企业包括Equifax、Instagram、Facebook、Amazon和Paypal。

API的使用和攻击都在增加

　　根据Salt Security在2月发布的报告，91%的企业在去年有API相关的安全问题。大部分安全问题为漏洞（54%），其次为认证问题（46%）、bots自动化威胁（20%）、以及DoS攻击（19%）。

　　80%的组织不相信他们的安全工具可以有效防范API攻击。Salt Security的调研发现，三分之二的企业在减缓新应用的生产速度，原因就是API安全的考量。而Salt Security自身的客户，即使所有企业都部署了WAF和API网关，依然每个月都会经历数次API攻击——意味着API攻击已经绕过了这些安全工具。事实上，根据Salt的研究，WAF和API网关会遗漏OWASP十大API安全威胁中90%的情况。

　　然而，超过四分之一的组织在没有安全策略的情况下运行着基于API的关键应用。以Peloton为例，最开始就通过API将用户数据在没有认证的情况下对任何人、任何地点都允许接入。新思安全研究中心的首席安全策略官Tim Mackey表示：“Peloton保护他们API的第一步，是现在订阅人员的接入，但这依然意味着其他用户还是能够无视隐私设置对其他用户的信息进行接入。这些信息包括了用户的年龄、性别、头像、以及一些活动数据。”

　　造成泄漏的API并不少见。根据Salt Security的报告，82%的组织对自己是否知道API信息毫无信心；他们无法确定这些API是否包括客户个人网络信息、受保护的健康信息、持卡人数据等个人可识别信息。同时，还有22%的组织表示他们不知道如何发现哪些API在暴露敏感数据。

　　Traceable的安全研究工程师Roshan Piyush认为，Peloton的问题在于他们使用了未经认证的API，从而导致了对象级别的认证问题。其他有同样问题的企业还有Panera、Fiserv、LifeLock和Kay Jewelers，而且这份名单还在增加。Roshan认为，在开发过程当中，认证和授权保护往往会被忽略。

一个银行的API成长史

　　某中型规模金融机构的安全技术经理Jeff表示，他们企业在过去的数月中，对API的使用急速增长。如今，API已经连接了3,000多个终端，包括企业的内部应用、属于是商业伙伴的应用，以及面对客户的网站和移动设备。

　　而这仅仅是开始。Jeff提到：“我们现在在五年计划的第二年，而在未来三年这个进程会进一步加速。我们16个月以前来了新的CISO，而他有很强的API开发背景，因此他必然会进行加速。”

　　Jeff表示，他们现在还只是在做准备工作：“我们肯定是在正确的道路上。我们现在正在消除所有部署的数据中心，并且转移到网站服务商，同时用API连接所有东西”。

　　Jeff提到，API会从四个主要的URL地址调用，各有不同的服务以及不同的参数。这种方式能形成一层保护。Jeff说到：“由于API的风险性，我们故意混淆了一些我们API终端的名字，使得横向攻击或者嗅探更加难以实现。”该金融机构也在过去六个月将多个API网关合并到一个主要网关中。

　　公司的API网关使用了Apigee，该API安全厂商在2016年被谷歌收购。

　　一些企业会对所有开发者都使用一个网关产生一些顾虑，比如担心潜在的生产瓶颈、单点故障、或者DDoS攻击等。但Jeff认为他的组织不会有这个问题：“我们的开发人员会偏向使用API网关的方式。该解决方案是通过SaaS提供，本身能跨多个地点，从而给开发人员更好的接入体验，降低延迟。因为SaaS能够自动延展，它不像传统的API网关那样有所限制。”

　　举例而言，如果一个AP接口之前预计一个月要进行1,000万次处理，但是在它上线的前两周就有了2亿次处理——而事实上，使用者并没有感到任何延迟，或者性能的降级。现在，产线每个月会有20亿次的API调用，而两年前只有8,000万次。

　　在认证方式上，该公司的移动和网站应用使用更老的Java技术。Jeff表示，他们正在将这些全部都通过一个软件开发工具组移到一个基于API的认证环境；这现在是他们的关键部分，正在和多个部门进行协同。

　　这个新的解决方案改变了企业防范基于信用的攻击的方式。对于外部合作伙伴，该公司正在推进API调用的零信任模型。Jeff表示：“虽然说我们想加速这个进程，但是有一部分合作伙伴并没有准备好。”

　　对于通过网站或者移动应用接入的消费者，会有一定的持久性；这意味着消费者不用多次进行验证。但是，Jeff却提到：“我们的零信任模型表示我们不会允许任何对话有持久性，或者支持任何形式的cookie维持状态。用户需要每次都进行验证。我用一个最基础的理念来说：安全、便利、快速，你可以实现两项，但是无法三项都做到。”

　　而对于在公司安全边界内的API，就有另一种解决方案。“当API在内部的时候，我们就倾向于使用一些更轻量化的非零信任方案。”Jeff说到，“我们会用IP安全，基于流量的目标地址、服务账户进行认证，会更基于活动目录进行。”

　　行为分析也同样被使用，进行内部和外部的可疑行为监测，并自动化过滤明显的恶意信息。“能在前门就将麦子和谷壳分开，能让我们更聚焦于期望见到的‘好’调用。行为分析本身也是现实进行的交互行为。我们会使用所有从IP信誉库、行为分析、用户和账户画像的方式。”Jeff说到，“假如我们有一个用户每周五都进行一次200美元的存款，而现在开始每周三存款800美元了；我们会开始观察这个行为。这不仅仅是保护我们自己的资产，也是确保我们能够主动报告潜在的洗钱和人口拐卖行为。”

　　通过自动化能力，该供公司能够将送达到它SOC和安全事件响应团队的事件数量降低35%。为了实现这一点，一年多以前NOC和CSIRT团队使用了Salt Security的解决方案，和Apigee API网关一起共享流量。

　　“这个解决方案能看到所有到达我们最高等级API的流量，然后进行学习，从而给我们潜在的攻击者信息，以及改进代码的建议。”

　　其他团队也启用了相关平台，包括反诈团队、开发团队、和安全架构团队。Jeff表示，这也让他们加速了API迁移的进程。

针对API的机器人攻击

　　API流量在增加，但恶意API流量增长得更快。Salt Security客户的每月API调用流量增长了51%，而恶意流量增长了211%。

　　基于Akamai对于100家包括金融服务机构、零售、媒体、和娱乐行业的企业客户的每月API数据分析，发现有7,440亿API调用，12%来自已知恶意因素，25%来自非网站浏览器、移动设备、或者应用的终端客户——意味着这些流量也可能来自恶意人员，而非正常用户。

　　安永的网络安全管理主任Rishi Pande表示，传统的前端应用，比如网站和移动应用，会对攻击有一定防御能力。这些防御能力可以防范DDoS、撞库、和一些其他自动化攻击。“你的前端或许被保护了，但如果API网关没有被保护，那很快就会出现问题。”Pande说到。这个领域演化得很快，但一些客户会以为相关技术提供了保护，但是实际上这些工具并没完全准备好。

　　而撞库问题并不只是随着API出现的。事实上，根据Cequence Security的攻防专家Jason Kent的看法，针对API层的攻击正在越来越多，因为这种攻击匿名性更强，同时API并不像网站的移动应用那样被保护得那么好。Kent有一次通过仓库大门公司API的设计问题，成功打开了仓库大门。他提到：“在标准的网站安全中，会有在客户端侧的额外代码运行，从而知道在操作的是人还是机器。但在API使用中，我们完全放弃了这一套人机识别。我们能够频繁发起你能想象到的最快速的攻击。”

　　Kent认为，现在API安全的处境就像2009年应用安全的情况一样。他成功破解仓库大门API的方式是查看其移动应用。“你从应用商店下载的应用只是一堆被解压缩的文件夹和文件。”他说到，“它会包含所有它进行沟通的API终端名单。”

　　一旦攻击者获得了移动应用，并明白它是如何交互的 ，攻击者就可以使用同样的API频道发送请求。Kent认为，人工智能和机器学习可以防御这类攻击，因为来自机器人的API请求和真人使用正规应用的方式是不同的。

该左移了

　　Postman的2020年API报告调研了13,500名开发者，只有36%的公司为他们的API做安全测试——相比而言，有70%的公司做了功能性测试，67%做集成测试。而根据SmartBear的2020年API报告，可用性是开发者对API的最大考虑，其次是功能，而安全只在第三位。

　　部分原因是因为开发团队往往和安全团队是分开的，同样也和网络以及架构团队分开。“这个问题的解决方法就是DevSecOps。”Capgemini North America的高级网络安全经理Albert Whale如是说，“我们现在能够集成测试，然后将这种测试的能力交给应用开发者掌控。我们能够让每个人都成为安全团队的一员。”

　　Whale认为，从一开始就创建更为安全的应用，要比试图在最后通过API网关等技术进行保护要重要得多。“我将API网关视为一个单点故障点。”他说，“它会降低应用的速度，因为它必须收集所有的信息。这不是说API网关很可怕，但是它们就像WAF一样实现他们的功能；但是除了有时候需要使用它们，也有时候需要限制。”

　　Whales提到，企业应该注重与更好的架构、安全和API调用：：“企业会花更长的时间去实现这些，但是拥有更好代码的应用才是真正需要的防护。当你有一个足够能够抵御攻击的应用的时候，显然你不需要额外的因素来提供更多安全能力。”

　　网络安全研究公司Securosis的分析师兼总经理Mike Rothman也同意，开发者正在越来越注重安全。“我们看到DevSec正在让更多的人进行合作。”他说，“这种情况总是会发生吗？未必。但是我们正在试图打破许多原有的固化思维以及沟通壁垒，让团队都一起合作。”

　　Rothman提到，当涉及API安全相关的时候，就有多个领域的隐患。首先是业务逻辑。“这是我无法告诉你我们是否处理正确的应用安全关键领域之一。”当一个整体化的应用被通过用API连接的方式分成多个小型服务的时候，对发现和缓解逻辑业务逻辑隐患的要求也极大提升了。应用也许会像设计得那样运作，认证机制也在完美地进行，甚至应用本身可能完全没有漏洞，但是如果编程逻辑里出现问题，依然会产生泄露事件。

　　然后就是一系列需要注意的漏洞。在2019年发布的OWASP十大API漏洞，已经两年没有变化了。Rothman表示：“我们一直都在重复相同的错误。然后我们需要从多个层面对环境 进行保护——传统的网络技术、以及传统的应用安全技术。”

　　最后，企业也需要注意工具、自动化、扫描技术、以及遥测监控，因为永远不会有足够的人员手动监测API。“我们需要权衡我们有的资源，而人员显然不是。”Rothman说到，“通过监控来看API是如何被调用的，可以寻找可能标志着恶意使用的非正常行为。”

仓库公司获得API安全可视化能力

　　开发者现在非常容易就能够启用一个网站服务，然后设置API。不过每一项新技术的产生，安全总是滞后的。

　　即使所有的开发者都配备了信的安全控制，但还是可能会有老系统的存在。这些过时的僵尸API有着极大的风险，因为API应该是使用期短却从不会被停止使用。

　　“你无法保护你不知道的东西。”仓库公司Prologis的安全主任Tyler Warren说到，“看着市面已有的API解决方案，你得先知道你有什么才能去保护它。这已经不是一个新手任务了，因为我们第一优先的工作任务是发现我们有什么。”

　　Warren作为Prologis的API安全项目负责人，表示他们公司在四年前开始开发面向顾客的系统。“我们拥有大约10亿平方英尺的土地，在19个国家有大约5,000个仓库。”他说到，“当人们听说你是一个仓库公司的时候，他们会说：‘你们和高科技能有什么联系？’但是管理层的决策是，技术驱动业务，而非一个成本的堆积。”

　　因此，Prologis开始改变。四年前，仓库的思维模式是：“这是你的四面墙和屋顶，这是你的钥匙，过几年等你要续租的时候再来找我们。”

　　现在，有了基于云的Prologis Essential平台，能够让客户提交服务单或者检查收据状况；但更重要的是，可以和当地供应商联系，在有人入驻新仓库的时候获得虫害控制、叉状抓爪、照明灯其他产品和服务。

　　鉴于这是一个全新的服务，没有之前的系统可以参考，Prologis开始使用基于云的无服务器架构。“我们直接跳过了容器。”Warren说到，“我们几乎完全是无服务器的，主要是用Amazon和其Lambda服务。”

　　Prologis Essentials使用AWS的API网关，有15个API接口服务500个终端，包括内部连接和外部合作伙伴的集成。上个月，系统处理了52.9万次API请求。

　　不过，Warren发现AWS并不提供太多API的行为信息。“AWS自身并不会给你这些信息。”Warren表示，“我们尝试了一些以前的方式，但是WAF无法实现这个效果。WAF虽然能给你一点保护，但是也仅此而已了。”

　　Warren试图去寻找易于部署的技术，并且需要该技术不会给开发团队造成麻烦。“如果你把关系搞砸了，那麻烦就来了。”他说，“如果你是那种喜欢说‘不’的安全人员，那开发人员就会饶过你。因此，解决方案需要符合他们的工作流，并且不会给他们增加额外的工作 。”

　　Prologis同样选择了Salt Security。他们原本计划2021年全面展开项目，但是最终从2020年就开始着手。“API攻击面越来越值得注意。”Warren提到，“那些坏人已经发现了很多攻击面。”

　　Salt Security花了大约一个月的时间将自己的解决方案嵌入Essentials系统。“大部分工作都是测试。”Warren说，“同时确保开发者同意这些改变，不会对性能产生影响。”

　　Salt Security的工具位于AWS环境，并且从API网关获取流量、抓取日志和元数据、再传送给Salt的SaaS显示板进行告警和报告。“我一开始猜测我们有100个API终端。”Warren说到，“但最后发现我们有500个。一般而言，我觉得我了解网络上在发生什么，但我这次显然错得离谱。这是行业里的一个通病——人们总是少估了他们有的东西。”

　　系统最终在去年秋天上线运行。它能够和WAF连接，并且自动化处罚行动。现在，它会将报告发给安全人员手动阅览。“我最不想做的事，就是阻断了合法流量。”Warren提到。

　　该系统也会检查是否存在潜在的个人信息泄露情况。比如，Warren有一次被告警，因为AWS私钥可能产生泄露，虽然最终发现这是一次误报。Warren解释：“我们有些账户数字看上去像AWS私钥，但这只是一个巧合。”

　　这个系统还发现有些API提供必要之外的信息。“虽然说邮箱和账户数字的组合并不一定会是敏感信息。”Warren表示，“但我需要的是‘如果不是绝对需要，就不要做’。”这条建议，应该是某个使用API的企业都需要遵守的。

是某个使用API的企业都需要遵守的。

相关阅读

[调查]API安全成为威胁新趋势

API安全成企业当务之急

ISC2021创新沙盒决赛十强点评 老周提出FITS理念