当前位置: 首页 > 科技观察

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

时间:2023-03-18 19:02:27 科技观察

API团队应该知道的十大安全威胁大量数据被释放到外部世界。但是,由于可以直接访问这些数据,而绕过浏览器的阻止机制。因此,我们需要担心的不再是SQL注入、XSS等“传入”的问题,而是敏感数据记录可能被窃取等API“传出”的安全问题。此外,验证码和浏览器指纹识别等典型的预防机制不再有效,因为API旨在为单个客户端提供大量API访问。那么,我们如何着手做好API的安全保护呢?在这里,让自己从攻击者的角度检查目标API以阻止常见的未知对象攻击,并参考OWASP安全API列表(参见--https://owasp.org/www-project-api-security/),以防止利用各种零日漏洞。1.限制不安全的资源访问大多数API都提供对实体列表(例如/users或/widgets)的资源访问。浏览器等客户端通常使用以下方法进行过滤和分页来限制返回给客户端的item数量:FirstCall:GET/??items?skip=0&take=10SecondCall:GET/??items?skip=10&take=10但是,如果实体包含任何PII(PersonallyIdentifiableInformation)或其他敏感信息,则攻击者可以通过该端点获取数据库中的所有实体信息。一旦这些实体的PII不小心泄露,竞争对手就可以推断出你公司的采购信息和客户状态,甚至是大量的邮件列表。如果对此感兴趣,可以参考文章《如何清除Venmo数据》(https://22-8miles.com/public-by-default/)。常规的保护机制是记录那些大于100或1000的条目,并抛出异常信息。以下是两种常见的默认保护方式:对于数据类型的API,合法客户可能需要获取并同步大量的记录,通过各种cron作业来实现。那么人为限制页面的大小会迫使API频繁执行相同的操作,从而降低整体吞吐量。可以说,这类最大入口限制方式主要是为了满足内存和扩展性的要求,以及防止某些DDoS攻击。通过编写一个简单的脚本,在重复访问之间休眠一段随机时间,如下面的代码片段所示。当然,这样的防御并不总是对攻击者有效。skip=0whileTrue:response=requests.post('https://api.acmeinc.com/widgets?take=10&skip='+skip),headers={'Authorization':'Bearer'+''+sys.argv[1]})print("Fetched10items")sleep(randint(100,1000))skip+=102。防止分页攻击要防止分页攻击,您应该跟踪一定时间内访问资源的用户数量或API密钥数量,而不是仅仅停留在请求本身。您可以在达到阈值时阻止用户或API密钥(例如:一小时内每个用户或API密钥允许1,000,000条记录)。当然,确切的阈值取决于您的API用例及其订阅方式。就像验证码每分钟只能发送一次一样,这会减慢黑客调用目标API的速度。为此,攻击者必须手动创建更多新帐户或API密钥。3.保护API密钥池大多数API将受到密钥或JWT(JSONWebToken)的保护。由于API安全工具可以检测异常API行为并自动阻止对API密钥的访问,因此这是跟踪和保护API的本机方法。然而,攻击者经常使用大量IP地址来逃避DDoS检查;通过生成大量账号获取大量API密钥。防御这种攻击最简单的方法是要求用户注册自己的服务并生成相应的API密钥。我们可以使用验证码和双因素身份验证来阻止各种僵尸(bot)流量。除非有合法的商业用例,否则该服务的新注册用户不能以编程方式生成API密钥。相反,只有那些受信任的用户才能生成API密钥。由此,我们可以确保在帐户级别(不仅仅是每个API密钥)对异常行为进行异常检测。4.防止密钥意外泄露一般情况下,以下几种使用API??的方式会增加密钥泄露的可能性:如果将API密钥保存在服务器的环境变量中,并提供等待者类型的访问方式,这样就增加了泄露的几率黑客获得有效且未过期的密钥。当用户登录到交互式网站时,这显然不如在会话中使用具有较短到期时间的API密钥安全。API的消费者可以直接访问密钥,例如通过Postman或CURL进行调试。然后,任何开发人员都可能不小心将包含API密钥的CURL命令复制/粘贴到GitHubIssues或StackOverflow等公共论坛中。如果不使用一次性令牌或双因素身份验证,API就无法保护其密钥。防止密钥泄露的最简单方法是使用两个令牌而不是一个。刷新令牌存储为环境变量,只能用于生成短期访问令牌。与刷新令牌不同,这些短期令牌提供对资源的访问,但有时间限制,例如几小时或几天。客户端存储刷新令牌和其他API密钥。SDK在初始化时或最后一个访问令牌过期时生成新的访问令牌。如果将CURL命令粘贴到GitHub中,攻击者必须在到期前的几个小时内使用短暂的访问令牌(毕竟,他获得刷新令牌的机会极低)。5.防止DDoS攻击API开辟了一种新的商业模式,用户可以通过编程方式访问目标API平台。但是,它也使DDoS保护变得棘手。大多数DDoS保护机制正在清除或拒绝来自攻击者的大量请求。但是为了使混淆的正常请求通过僵尸流量,我们需要对HTTP请求进行指纹识别。但对于API服务来说,这是极其困难的,毕竟所有的流量看起来都是僵尸流量,而不是来自浏览器的cookie。今天,绝大多数API访问和调用都需要API密钥。如果请求中没有API密钥,它将被自动拒绝。那么,我们如何处理那些经过身份验证的请求呢?目前,最简单的方法是使用每个API密钥的速率限制计数器,例如:我们可以预先设置每分钟X个请求,然后对于超过这个数量级的请求将被HTTP429响应拒绝。目前,我们可以实现各种算法,如漏斗和固定窗口计数器来实现这一点。6.使用适当的SSL保护您的服务器在服务器安全方面,API与Web服务器没有太大区别。错误配置的SSL证书,或默认情况下允许非HTTPS流量,可能会导致数据泄露。如今,虽然非HTTPS请求已逐渐被HTTPS取代,但用户仍可能错误地从其应用程序或泄露API密钥的CURL发出非HTTPS请求。而且API无法实现HSTS(HTTPStrictTransportSecurity,HTTPStrictTransportSecurityProtocol)、HTTPS重定向等浏览器级别的保护。目前,比较普遍的做法是通过QualysSSLTest(参见--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=博客&utm_campaign=放置文章&utm_term=top-10-api-security-threats)。7.确保缓存标头API已正确配置,以通过不同的键提供对定义范围内的动态数据的访问。任何缓存机制的实现都应该基于APIkey的范围,以防止数据的“交叉污染”。例如:用户通过代理服务器使用多个APIkey,其中一个用于开发环境,一个用于生产环境,则两个环境中的数据可能会相互泄露。这方面的一个真实案例是:推特确认在一次数据安全事件后泄露了账户相关信息(参见:https://www.bleepingcomputer.com/news/security/twitter-discloses-billing-info-leak-在-数据安全事件/之后)。通常,许多API不使用标准的身份验证标头,而是使用类似于X-Api-Key的自定义标头。如下代码片段所示,缓存服务器只能选择缓存此类请求,而不知道此类请求是否经过验证。可见,我们应该正确配置缓存控制(Cache-Control)头。app.use((req,res,next)=>{res.setHeader('Cache-Control','no-store,no-cache,must-revalidate');res.setHeader('Pragma','no-缓存');//...});8、正确添加API日志通过对大多数入侵案例的研究,OWASP层发现企业通常需要200天以上才能检测到数据泄露事件。而且,如果没有适当的API日志记录和监控,攻击者可能会继续使用相同的漏洞,从而检测到更多漏洞。我们不仅要保证API日志能够跟踪API请求本身,还需要通过绑定实现对用户行为的分析。同时,应保护此类系统以确保数据记录不会被意外删除或过早销毁(应至少保存一年)。出于安全目的,GDPR和CCPA都允许系统进行API审计。如下图API审计日志所示,像MoesifAPISecurity(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),为相关对象分配不同的角色,以实现基于角色的访问控制。你可以参考文章top-10-api-security-threats)了解具体的保护方法。10.保护内部和外部端点同一个API服务可能有不同的内部和外部端点。然后,除了使用身份验证和授权等基本保护方案外,我们还应该通过启用负载均衡器或API网关来确保这些端点不会完全暴露在公共互联网上。此外,我们还可以通过提供多级安全(一种常见的预防策略)来保护和祝福API。原标题:Top10APISecurityThreatsEveryAPITeamShouldKnow,作者:DerricGilling