API团队须知的十大安全威胁

译文
安全 应用安全
本文将从攻击者的角度,讨论API团队须知的十大安全威胁,并逐条给出对应的预防措施。

【51CTO.com快译】如今,无论是以API为主营服务(API-first)的公司,或是单页面应用/JAMStack,都通过各种丰富的API对外公布着大量的数据。不过,由于这些数据能够被直接地访问到,而且绕过了浏览器的预防机制。因此,我们需要担心的不再是SQL注入和XSS等“入向”问题,而是敏感数据记录可能被窃取等API“出向”安全性问题。此外,由于API被设计为能够向单个客户端提供大量的API访问,因此诸如验证码(Captchas)和浏览器指纹识别之类的典型预防机制,也不再能够起到明显的效果。

那么,我们该如何开始做好API的安全防护呢?在此,让自己从攻击者的角度来检查目标API,以阻断常见的未知对象攻击,并参照OWASP安全API列表

(请参见--https://owasp.org/www-project-api-security/),来防范各种零日漏洞的利用。

1. 限制不安全的资源访问

大多数API都提供了对于实体列表(例如/users或/widgets)的资源访问。诸如浏览器之类的客户端通常会使用如下方式,来进行过滤和分页(pagination),以限制返回给客户端的条目数:

  1. First Call: GET /items?skip=0&take=10  
  2. Second Call: GET /items?skip=10&take=10 

但是,如果该实体中含有任何PII(个人身份信息)或其他敏感信息,那么攻击者就可能通过该端点,获取数据库中的所有实体信息。一旦这些实体的PII被意外泄露,竞争对手就能够推断出贵企业的采购信息和客户状况,甚至是大量的邮件列表。如果您对此有兴趣的话,可以参看《如何清除Venmo数据》

(https://22-8miles.com/public-by-default/)一文。

常规的保护机制是记录那些大于100或1000条的条目,并抛出异常信息。下面是两种常见的默认保护方法:

  • 对于数据型API,合法客户可能需要获取并同步大量的记录,并通过各种cron作业来实现。那么人为地限制分页的大小,会迫使API频繁地进行同一种操作,进而降低了整体吞吐量。可以说,此类最大条目限制方法主要是为了满足内存和可扩展性的要求,以及防止某些DDoS攻击。
  • 如下代码段所示,通过编写简单的脚本,在重复的访问之间,随机休眠一段时间。当然,此类防护对于攻击者来说,并非总是奏效。
    1. skip = 0 
    2. while True:    response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})    print("Fetched 10 items")    sleep(randint(100,1000))    skip += 10 

2. 防止分页攻击

为了防止分页攻击,您应该跟踪在一定时间段内,用户或API密钥访问某个资源的数量,而不是仅仅停留在请求本身。您可以在用户或API密钥达到阈值时(例如:每个用户或API密钥在一个小时内之允许调用1,000,000条记录)阻止它们。当然,具体阈值的设定取决于您的API用例,以及它们的订阅方式。就像每分钟只能发送一次验证码那样,此举减缓了黑客调用目标API的速度。对此,攻击者不得不手动创建更多新的帐户或API密钥。

3. 保护API密钥池

大多数API会受密钥或JWT(JSON Web令牌)的保护。由于API安全工具可以检测到异常的API行为,并自动阻止对于API密钥的访问,因此这是跟踪和保护API的原生方式。但是,攻击者往往会使用大量的IP地址,来规避DDoS的检查;并通过生成大量的账户,来获取大量的API密钥。

抵御此类攻击的最简单方法是要求用户注册自己的服务,并生成对应的API密钥。我们可以通过使用验证码和双因素身份验证,来阻止各种僵尸(Bot)流量。除非是合法的业务用例,否则新注册服务的用户不能够以程序的方式,生成API密钥。相反,只有那些受信任的用户,才具有生成API密钥的能力。据此,我们可以确保在帐户级别(不仅仅针对每个API密钥)上,对异常行为进行异常检测。

4. 防止意外的密钥泄露

总的说来,如下使用API的方式会增加密钥泄漏的可能性:

  • 如果您将该API密钥保存在服务器的环境变量中,并提供侍候型的访问方式,那么就会增加黑客获得有效且未过期的密钥的可能性。这显然不及用户在登录交互式网站时,在会话中使用较短时间到期的API密钥安全。
  • API的使用者可以直接访问到密钥,例如通过Postman或CURL进行调试。那么任何一个开发人员都可以将含有API密钥的CURL命令,意外地复制/粘贴到诸如GitHub Issues或Stack Overflow之类的公共论坛中。
  • 如果不采用一次性令牌或双因素身份验证,API将无法保护其密钥。

防止密钥泄露的最简单方法是利用两个令牌而非一个。刷新令牌(refresh token)被存储为环境变量,并且只能用于产生短暂的访问令牌(short lived access tokens)。与刷新令牌不同,这些短暂的令牌可以访问到资源,但是有着时间的限制,例如数小时或数天。

客户存储刷新令牌和其他API密钥。SDK会在其初始化时、或是最后一个访问令牌到期时,生成新的访问令牌。如果CURL命令被粘贴到GitHub中,那么攻击者必须在数小时内使用短暂的访问令牌,不然就会过期(毕竟他获取到刷新令牌的可能性极低)。

5. 阻止DDoS攻击

API开辟了全新的业务模式,用户可以在其中以编程的方式访问到目标API平台。但是,这也会使得针对DDoS保护变得十分棘手。大多数DDoS的保护机制是清洗或拒绝攻击者发来的大量请求。但是为了让混淆在僵尸流量中正常请求能够顺利通过,我们需要对HTTP请求进行指纹识别。但是对于API服务而言,这是极其困难的,毕竟所有的流量都看上去像僵尸流量,而非来自浏览器的Cookie。

如今,绝大多数的关于API的访问和调用都需要用到API密钥。如果某个请求中没有API密钥,则会被自动拒绝。那么,我们该如何处置那些经过验证的请求呢?目前,最简单的方法是利用每个API密钥的速率限制计数器,例如:我们可以预先设定每分钟可以处置X个请求,那么对于超过这个数量级的请求,则以带有HTTP 429的响应方式予以拒绝。目前,我们可以采用诸如漏斗和固定窗口计数器等多种算法,来实现这一点。

6. 通过正确的SSL来确保服务器安全

其实在服务器安全方面,API与Web服务器并无太大差别。错误配置的SSL证书,或默认允许非HTTPS的流量通过,都可能导致数据的泄漏。如今,非HTTPS请求虽然已经逐渐被HTTPS所取代,但是用户仍然可能错误地从其应用程序、或泄露了API密钥的CURL中发出非HTTPS的请求。而且API是无法实现HSTS(HTTP Strict Transport Security,HTTP严格传输安全协议)、或HTTPS重定向之类的浏览器级保护的。

目前比较普遍的做法是通过Qualys SSL Test(请参见--https://www.ssllabs.com/ssltest/)或类似的工具,来实施并测试SSL。无论您的API是仅供自己的应用来访问,还是要在服务器端被访问到,您都可以通过负载均衡设备来阻断所有非HTTPS头的请求。具体请参见《REST API跨域资源共享权威指南》

(https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats)一文。

7. 确保正确地配置缓存头

API通过不同的密钥,提供了对于既定范围内动态数据的访问。那么任何缓存机制的实现,都应该基于API密钥的范围,以防止出现数据的“交叉污染”。例如:某个用户通过代理服务器正在使用多个API密钥,其中一个被用于开发环境,另一个被用于生产环境,那么两个环境中的数据就可能产生相互泄露。此方面的一个真实案例是:Twitter曾在数据安全事件后证实泄漏了账号相关信息(请参见:

https://www.bleepingcomputer.com/news/security/twitter-discloses-billing-info-leak-after-data-security-incident/)。

通常情况下,许多API并不使用标准的认证头,而是类似于X-Api-Key的自定义头。如下代码段所示,缓存服务器在并不知晓此类请求是否已通过验证的情况下,只能选择对其进行缓存。可见,我们应该正确地配置缓存控制(Cache-Control)头。

  1. app.use((req, res, next) => {  res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');  res.setHeader('Pragma', 'no-cache');  // ... 
  2. }); 

8. 正确地添加API日志记录

通过对大多数入侵案例的研究,OWASP层发现:企业通常需要超过200天,才能检测到数据发生了泄漏事件。而且,如果未能采用适当的API日志记录和监控,攻击者可能会持续使用相同的漏洞,进而探测到更多的漏洞。

我们不但应该确保API日志记录能够跟踪API的请求本身,而且需要通过绑定以实现对用户行为的分析。与此同时,此类系统应当受到相应的保护,以确保数据记录不会被意外地删除,或过早地销毁掉(应至少存储一年)。为了安全起见,GDPR和CCPA都允许系统开展API审计。如下图的API审计日志所示,像Moesif API Security

(https://www.moesif.com/solutions/api-security?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats)之类的方案,能够为API产品提供了一整套监视和分析功能,并且用户只需数分钟就能够快速上手。

9. 正确地处理授权

虽然大多数API开发人员都会自觉地添加诸如API密钥、或OAuth之类的全局性认证方案、来验证调用方的身份。但是,我们也需要通过授权的方式,来检查他们是否可以访问某些特定的资源。对此,我们往往会借用访问控制列表(ACL),并为相关对象分配不同的角色,来实现基于角色的访问控制。您可以参考《为RESTful API构建身份验证和授权的步骤》一文(请参见--https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats),以了解具体的防护方法。

10. 保护内、外部端点

同一项API服务有可能具有内、外不同的使用端点。那么,除了使用身份验证和授权等基本保护方案之外,我们还应通过启用负载均衡器或API网关,以确保这些端点不会完全暴露于公共互联网上。此外,我们也可以通过提供多级安全性(一种常见的预防策略),来进行API的防护与加持。

原标题:Top 10 API Security Threats Every API Team Should Know ,作者:Derric Gilling

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2024-01-03 07:53:21

2019-07-04 11:33:21

信息安全安全IT

2021-04-27 10:05:46

人工智能安全威胁网络安全

2015-05-08 08:22:27

2019-01-14 05:00:34

2014-01-02 09:26:04

2022-01-14 14:33:20

安全挑战勒索软件供应链

2012-12-11 11:24:58

2022-12-29 07:40:58

2016-10-21 10:00:09

2014-05-15 09:44:52

2013-07-26 13:23:28

2014-03-11 16:52:20

2013-07-05 10:18:14

2023-06-08 00:16:58

2014-01-03 11:22:53

2018-08-31 08:11:29

2010-08-03 13:20:53

FlexBuilder

2015-10-08 09:41:51

2011-12-23 10:09:20

点赞
收藏

51CTO技术栈公众号