攻击者知道在针对API时如何避开WAF和API网关。以下是一些公司应对API攻击快速增长的示例。

5月初，Pen Test Partners 安全研究员 Jan Masters 发现，他竟然能够在未经身份验证的情况下，向Peloton的官方API提出可获取其它用户私人数据的请求，且用户的本地设备和云端服务器都如此不设防。

这些数据中包括了详细的用户年龄、性别、城市、体重、锻炼统计数据，甚至可揭示用户在个人资料设置页面中设为私密的生日等信息。

应用程序编程接口（API）允许轻松地机器对机器通信。如今，应用程序开发中的API使用已成为新的实践标准，通过集成第三方服务的功能，开发人员不用再从无到有自己构建所有功能，这样一来可以加快新产品及服务的开发过程。

近年来，API的使用更是呈现爆炸式增长。根据Akamai的说法，API通信现在占所有互联网流量的83％以上。

尽管API支撑着用户早已习惯的互动式数字体验，是公司数字化转型的基础，但它们同时也为恶意黑客提供了访问公司数据的多种途径，成为诸多安全问题的根源所在。

除Peloton公司外，最近新闻中曝光的涉及API相关网络安全问题的企业还包括Equifax、Instagram、Facebook、亚马逊以及Paypal。

API的应用以及不断攀升的攻击趋势

根据Salt Security于今年2月发布的报告显示，去年有91％的公司存在与API相关的安全问题。其中，最常见的是漏洞，涉及54%的受访组织；紧随其后的是身份验证问题（46%受访者）、僵尸程序（20%受访者）以及拒绝服务（19%受访者）。

80％的组织认为他们的安全工具不能有效地防止API攻击。此外，Salt Security的调查还发现，三分之二的组织由于与API安全相关的担忧而减缓了将新应用程序投入生产的速度。即便是拥有Web应用程序防火墙（WAF）和API网关的所有Salt客户，每个月也都要经历多次API攻击，这就意味着这些安全工具已经阻止不了API攻击。

实际上，根据Salt的说法，WAF和API甚至已经阻挡不住OWASP API安全Top10威胁中90%的因素。

但糟糕的现实是，超过四分之一的组织正在没有任何安全策略的情况下运行基于关键API的关键应用程序。例如，Peloton最初就是可供任何人在任何地方通过API访问用户数据，而无需任何身份验证。

API存在漏洞并不稀奇。根据Salt Security的报告，82％的组织对了解API详细信息缺乏信心，例如API是否包含个人身份信息（PII），如客户专有网络信息、受保护的健康信息以及持卡人数据等；而22％的组织表示他们无法知道哪些API公开了敏感数据。

Traceable公司安全研究工程师Roshan Piyush表示，Peloton的错误是使用了未经身份验证的API，而其他遇到相同问题的公司还包括Panera、Fiserv、LifeLock和Kay Jewelers。可以说，这样的案例举不胜举，归纳来说，就是在开发过程中忽视了对API的身份验证和授权保护等问题。

一家银行API应用增长的故事

一家中型金融机构的网络安全技术经理Jeff Serota表示，在过去的几个月中，他的公司对API的使用急剧增长。如今，API连接了大约3,000个端点，其中包括内部应用程序、属于业务合作伙伴的应用程序以及面向客户的网站和移动设备。

不过这仅仅只是开始，按照公司的发展规划，未来三年API应用还将迅速增加。他们的目标是消除所有本地数据中心，并迁移至适用于所有内容的Web服务和API。

Serota介绍称，其API调用通过四个主要URL，不同的服务在其API调用中包含不同的参数。这种方法创建了一个保护层。他说，由于使用API存在很多风险，所以我们实际上混淆了一些API端点名称，以使其更难被横向攻击或被发现并用于恶意目的。

在过去的六个月中，该机构还一直在将多个API网关整合到一个主要网关中。而对于API网关，该公司选择了Apigee，这是Google在2016年收购的API安全供应商。

一些公司在尝试让所有开发人员都拥有一个网关时遇到了问题，或是担心潜在的瓶颈、单点故障或DDoS攻击。但Serota表示，他们的公司并不存在这种情况。相反地，他们的开发人员更喜欢API网关方法，因为作为基于SaaS和多区域的服务，API实际上为他们提供了更好的可用性和更低的延迟。

例如，一个API预计每月将有1000万笔交易，但在启动后的头两周内就发生了2亿笔交易。而他们并没有感到任何延迟或性能下降。Serota称，目前，在他们的生产环境中，每月有大约20亿次API调用，而两年前约为8亿次。

对于身份验证，该公司的移动和基于Web的应用程序使用了较旧的Java技术，但他们正在使用软件开发套件将其全部转移到基于API的身份验证中。而对于外部合作伙伴，该公司也正在努力为其API调用建立零信任模型。

以前，对于通过自己的Web或移动应用程序访问该机构的消费者，会存在持久性，这就意味着消费者不需要多次进行身份验证过程。而该公司的零信任模型意味着不再允许任何类型的会话持久性以及任何类型的cookie。用户必须每次都要重新认证。就“安全”“方便”和“快速”三个要求而言，你可以同时拥有两个，但没办法全部都实现。

对于位于公司安全范围内的API，还有另一种方法。Serota介绍称，在公司内部，我们更倾向于使用轻量级的零信任以外的方法。目前，我们正在使用IP安全性，根据要进行的操作，服务将进行身份验证，并执行更多基于Active Directory的操作。

行为分析还可以用来检测内部和外部流量的可疑行为，并自动过滤明显的不良消息。Serota称，我们会使用所有内容——从IP信誉到行为分析再到用户和账户模式等，来分析任何可疑行为。例如，我们有一个用户每隔一个周五会存入200美元存款，而现在每个周三都会存入800美元。这时候就会引起我们的注意。这不仅是为了保护我们的资产，也是确保我们主动报告了可能存在“洗钱”或“人口贩卖”的情况。

Serota还表示，通过使用自动化，该公司能够将到达其网络运营中心和网络安全事件响应团队的问题数量减少35％，出现在他们身上的误报变得越来越少。

机器人（Bot）对API的攻击

API流量不断增长，但恶意API流量却增长得更快。 数据显示，Salt Security客户每月的API调用量增长了51％，而恶意流量则增长了211％。

根据Akamai对来自金融服务、零售、媒体和娱乐行业的100个企业客户一个月的API数据进行的分析发现，在总数7440亿个API调用中，有12%来自已知的恶意行为者；25%来自既非web浏览器又非移动设备或应用程序的终端客户，这就意味着它们可能来自恶意行为者，而非合法用户。

安永（Ernst＆Young）网络安全董事总经理Rishi Pande表示，传统的前端应用程序（网站和移动应用程序）具有针对攻击者的保护措施，其中包括针对DDoS、凭据填充和其他自动攻击的防御。不过，纵然前端受到保护，但如果API网关不受保护的话，同样会危及前端安全。

API正在迅速发展，一些企业认为他们的技术可以提供适当的保护，而实际上这些工具本身还没有准备好应对挑战。

实际上，针对API层的攻击正越来越受到黑客的欢迎，因为它更加匿名，而且API的保护程度通常不及网站和移动应用程序。甚至可以说，如今的API安全性就如同应用程序安全性在2009年的发展水平。

一旦攻击者分解了一个移动应用程序并弄清楚了它的通信方式，他们就可以使用相同的API通道发送请求。人工智能和机器学习可以帮助抵御这种情况，因为通过机器人发出的API请求看起来与使用合法应用程序的真实人类发出的请求不同。

是时候解决孤岛问题了

根据Postman的《2020年API状态报告》，该报告对13,500多名开发人员进行了调查，结果显示只有36％的公司对其API进行了安全性测试。相比之下，进行功能测试的公司占70％，而进行集成测试的公司则占67％。

而根据SmartBear的《2020年API状态报告》显示，可用性是开发人员对API的最大关注，其次是功能，再次才是安全性。

造成这种问题的部分原因在于，开发团队与安全团队，以及安全团队与网络和基础架构团队间彼此孤军作战，缺乏充分的沟通和合作。而孤岛问题的解决方案就是DevSecOps。现在，我们可以集成测试并将测试控制权交给应用程序开发人员。我们要使每个人都成为安全团队的成员。

从一开始就将安全性纳入应用程序开发流程，要比尝试使用API网关之类的技术来保护事物更为重要。公司应该专注于更好的体系结构、更好的安全性和更好的API调用。这样做可能需要很长的时间，但是想要获得更好的保护就必须开发出更安全的应用程序。只有应用程序足够强大以抵御攻击，我们才不需要其他元素来提供额外的安全性。

如今，通过DevSec团队协作，开发人员开始对安全性有了更多的了解。不过，在API安全方面仍然存在诸多问题。首先就是业务逻辑问题，这是应用程序安全性的其中一个关键方面。随着将monolithic应用程序分解为通过API连接的小型服务，发现并缓解逻辑问题的挑战被放大了。该应用程序可以完全按照其设计的方式运行，身份验证机制也可以完全安全，它可以完全摆脱漏洞，但是如果编码中存在问题，则仍然可能发生违规行为。

然后要注意的是标准漏洞集。2019年发布的OWASP API Top 10威胁在过去两年中没有发生变化，这说明我们正在重复遭遇同样的问题。

最后，由于缺乏足够的人员手动监视API安全，因此组织需要研究工具、自动化、扫描技术和遥测监视，以确定API的调用方式，并寻找出可能表明恶意滥用的异常行为。

仓储物流企业获得API安全可见性

开发人员启动Web服务和设置API变得比以往任何时候都更加容易。不过，与任何其他新技术一样，安全性也经常滞后。

尽管开发人员都在使用新的安全控制，但仍然可能存在老旧的系统。这些过时的僵尸API带来了巨大的安全风险，此外，那些原计划只做短期使用却未及时退役的API也会带来很大的风险。

仓储物流公司Prologis的安全主管Tyler Warren表示，我们无法保护自己并不知道的东西！我们必须清楚地知道自己拥有什么才能保护它，这是头等大事。

如今，Prologis已在全球19个国家/地区拥有近10亿平方英尺的面积，约5,000个仓库。当人们听到Prologis是一家仓库公司时，往往会质疑“你们怎么可能正在研发高科技？”但是，Prologis高管层清楚地明白，技术是业务的推动者，而不是成本中心。所以，早在4年前，该公司就开始开发面向客户的系统。

现在，有了基于云的Prologis Essentials平台，客户可以随时提交服务票证或检查票证的状态，更重要的是，当有人搬进新仓库时，可以与提供虫害控制、叉车、照明以及其他所需产品和服务的本地供应商联系。

Warren介绍称，Prologis Essentials几乎完全是无服务器的，主要依赖Amazon和lambda函数，所以无需处理任何的遗留系统问题。该平台使用AWS API网关，并且有约15个API服务于500个端点，其中包括内部连接以及与外部业务合作伙伴的集成。上个月，该系统处理了529,000个API请求。

但是Warren发现，AWS并未提供有关API可视化的大量信息。为了解决这一问题，Warren团队尝试了很多方法，但都不如人意。他们致力于寻找一种易于部署且不会妨碍开发团队的技术。最终，Prologis选择了Salt Security解决方案。

他们原本计划2021年再将Essentials系统集成到Salt Security中，但是最终还是将计划提前了。原因在于API攻击面正在吸引越来越多的关注，恶意行为者也发现了很多攻击面，他们没有时间去冒险。

最终，将Essentials系统集成到Salt Security的工作花费了大约一个月的时间，因为许多方面都必须经过不断地测试，并确保开发人员对结果满意且保证不影响性能。

该工具位于AWS环境中，并在API网关处侦听流量、获取日志和元数据，并将报告发送到Salt的SaaS仪表板以进行警报和报告，这使得Prologis获得了很好的API安全可见性。

该系统已于去年秋天启动并运行。它可以连接到WAF并自动触发动作，可以发送报告供安全人员手动查看，还可以查找潜在的PII泄漏。此外，该系统还捕获到了一些情况，例如API提供了许多并非必要的信息，这一点是许多企业在使用API时必须注意的问题。记住，如非必要，那就不要做！