永安在线发布「API安全建设白皮书」,提出API全生命周期安全防护模型
作者: 日期:2022年08月04日 阅:15,451

由于数字化转型加速,越来越多的企业将应用和数据迁移至线上或云端,并暴露核心业务能力和流程相关的API为外部合作伙伴提供服务。脱离了传统的内网或网络区域划分,线上或云上应用的开发和集成、云端管理API,被潜在的商业合作伙伴及攻击者使用,无形中使得API安全风险增大。

API在数字化转型中扮演的角色将愈发重要,通过API来进行数据交换和实现业务逻辑成为最常见的方式。现阶段API应用的增速与API安全发展的不平衡,使得API成为了企业安全建设中最薄弱的环节之一,也因此成为攻击者的重点攻击对象。近些年因API安全问题导致的数据泄漏事件却频频发生,可以看到API安全是一个常见但似乎又不为人熟知的挑战。

据Gartner提供的数据显示,到2025年,由于API的爆炸式增长超过了API管理工具的能力,将有50%的企业出现API安全防护缺位。

近期Approov和Osterman出品的《2022 年移动应用安全状况》报告显示,针对APP和API的威胁,安全开发实践必不可少,但仅提供部分保护,需要加强运行时威胁防护,调研数据显示有3/5的企业缺乏对针对APP和API的⼀系列运行时威胁的可见性。

永安在线《API安全建设白皮书》对API安全的背景、API定义及其发展过程中面临的安全挑战进行介绍,并围绕API从设计、开发、测试、上线运行、迭代到下线的每个环节,提出基于实战化角度的API全生命周期安全防护模型,旨在帮助企业将安全落实到API生命周期的各个环节,进而构建具有更好可见性和可控性的API安全防护体系。

关注本公众号,回复“API安全建设白皮书”,或点文章底部【阅读原文】下载《API安全建设白皮书》PDF完整版。

白皮书框架

观点提要

1. API承载着应用程序的逻辑和敏感数据,易受攻击

从银⾏、零售、运输到物联网、自动驾驶汽⻋和智慧城市,API是现代移动端、SaaS和Web应⽤程序的关键部分,企业在面向客户、面向合作伙伴和机构内部的应⽤程序中随处可⻅API的使⽤。从本质上讲,API暴露了应⽤程序的逻辑和敏感数据,如个⼈身份信息,正因为如此,它越来越多地成为攻击者的⽬标。没有安全的API,企业难以实现业务的快速创新和发展。

2. API防护缺失已成为企业业务和数据安全最大风险敞口

由于API防护的缺失,企业对外暴露了哪些API、对谁开放API、API通信中哪些敏感数据在流动等问题都未得到应有的重视。攻击者可以通过API认证和授权漏洞、数据过度暴露、数据可遍历、安全配置缺陷等攻击API进行数据窃取和业务攻击。

API是需要开放给用户来使用的,具备开放性和承载业务逻辑的特点,攻击者可以和正常用户一样来调用API,导致攻击者的流量隐藏在正常用户的流量里面,其攻击行为会更加隐蔽,更难发现。

3. API全生命周期安全防护是企业安全建设的必要措施

针对API存在威胁防护,使用WAF类产品只能覆盖其中的一小部分威胁,对业务而言,从单点考虑API功能安全设计到通过对API生命周期来考虑API的安全,围绕设计、开发、测试、上线运行、迭代到下线的每一个环节加强安全建设就更加有必要。全生命周期来考虑API的安全性,通过安全左移方法和工具,综合性地融合管理手段和技术手段进行API安全治理,提高业务API的整体的安全性。

白皮书内容节选

 3. API 全生命周期安全防护 

3.2. API生命周期的安全防护模型

从API面临的外部威胁来看,主要有如下方面:命令执行/SQL注入/服务器接管等高危漏洞的风险、权限管控不完善的未授权和越权访问的风险、设计存在缺陷带来的数据批量泄漏的风险等。

接入WAF可以解决部分命令执行/SQL注入类问题,但目前市场上的WAF产品因API技术的特殊性对API安全的防护能力仍显不足,其主要表现在以下几个方面:

一是认证和授权流程的绕过,API的认证和授权流程很多互联网应用是基于OAuth2.0和OpenIDConnect去实现的,传统的安全防护产品难以检测业务流程绕过的威胁;

二是数据格式难以识别,API在交互过程使用的消息格式大多JSON格式、XML格式、Protobuf格式、JWT格式等,在威胁检测时需要深入这些数据格式的数据结构内容去分析,传统的安全防护产品在此方面检测能力比较弱;

三是流量控制能力难以满足业务需求,面对API层面的CC攻击、慢BOT攻击时,传统上使用的检测和防护策略,如访问频率限制、IP黑名单设置、二次验证机制等难以对新型攻击起到很好的防御效果。

针对API存在威胁防护,使用WAF类产品只能覆盖其中的一小部分威胁,对业务而言,从单点考虑API功能安全设计到通过对API生命周期来考虑API的安全,围绕设计、开发、测试、上线运行、迭代到下线的每一个环节加强安全建设就更加有必要。全生命周期来考虑API的安全性,通过安全左移方法和工具,综合性地融合管理手段和技术手段进行API安全治理,提高业务API的整体安全性。

3.2.1 设计阶段:引入威胁建模

在设计之初以及开发过程中,根据业务特点对风险进行评估,做到可靠安全设计。安全工程师参与到对需求和设计方案的实现中来。资源允许的情况下,安全工程师在设计阶段对每个API进行威胁建模,线上的API风险将会大大减少。资源有限的情况下,建设自动化威胁建模的能力,采用“重点业务人工评审”和“非重点业务自动化威胁建模”相结合的方式,对核心高风险API如账号登录、文件上传、营销活动等进行覆盖。

在设计阶段的威胁建模,一般使用 ASTRIDE(隐私、欺骗、篡改、信息泄露、否认性、拒绝服务和特权提升)和攻击树模型作为常用的威胁建模技术指导原则。结合业界安全白皮书、历史上安全事件总结,根据业务API的需求和功能设计,基于上述5A的原则整理出来潜在攻击者可能进行攻击的目标和方式。

对于API而言,攻击者通常可能会有:恶意内部员工、外部攻击者,竞争对手、好奇者等,攻击路径可能是下班后通过内部系统API盗取数据、利用API的逻辑漏洞批量爬取数据、发起BOT攻击、借助手机号接码平台发起恶意注册、利用代理秒拨平台发起低频慢速的攻击等。

下面列表的一些安全检查表和最佳实践可以作为威胁建模阶段的一些参考:

OWASP REST 安全检查表:

https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

apisec提供了API安全工具和资源:

https://github.com/arainho/awesome-api-security

API安全检查表:

https://github.com/shieldfy/API-Security-Checklist

JWT安全检查表:

https://pragmaticwebsecurity.com/files/cheatsheets/jwt.pdf

3.2.2 开发阶段:安全开发意识和规范培训,引入安全工具

比较理想的情况,同研发在设计阶段就威胁建模进行了讨论,大家对于API可能遇到的安全问题点都有了全面且清晰的理解;然而,在研发进行编码实现的环节,往往可能在实现上出现不完整,或者引入新的bug。同时考虑到研发人员也在不断的变化,需要安全工程师提供API安全开发规范、安全开发插件、安全辅助包、敏感数据加解密工具等辅助性安全开发工具。一方面通过培训的方式加强全员对安全开发的意识和能力,一方面需要借助工具的方式来实现自动化的检查,提早发现bug和漏洞。

在API安全开发培训方面,可以从四个方面来考虑:

API安全管理框架和关键指标,企业在API安全这块整体的框架,定型和定量的指标,如上线后的漏洞数量等。

常见API安全问题,如OWASP API Top 10 ,以及安全运营通过SRC以及业务中提炼出来的一些具有代表性的问题。通过问题案例的方式,更加能让大家理解和学习。

常见API安全技术与安全设计,整理收集业界和企业自身的一些优秀安全实践案例,能开拓研发的思维,在遇到类似问题时能想到更好的解决方法。

API安全编码案例,结合业界的优秀案例,基于企业自身的特点制定出来符合企业特色的安全编码的规范和案例。

下面列表的一些安全编码和开发规范,可以借鉴和参考:

OWASP 安全编码实践:

https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

腾讯的代码安全指南:

https://github.com/Tencent/secguide

永安在线API安全开发规范:

https://www.yazx.com/reportDetail/14ac36b8-f5c6-11ec-af75-00163e048a4c

在自动化工具方面,可以考虑如下几个方面的工具:

引入代码白盒代码扫描工具,嵌入到CI/CD或者研发流程中,发布到测试环境时就进行扫描。

引入API管理工具,对API的文档进行集中统一的管理,能够监控到API的变更迭代的过程数据。

入API安全验证相关的工具,验证API安全实现的正确性,以保障验证工作尽可能做到全面,相关工具如FuzzDB、个人数据隐私监测类工具。

3.2.3 测试阶段:漏洞加入测试流程,使用AST类工具提高覆盖率

在测试环节加入API安全相关的内容,针对自动化测试流程和人工测试,在API业务逻辑实现、稳定性、性能测试的基础上增加API安全的测试。落实API安全测试的目的是为了自动化扫描每一个API,自动化API安全测试从请求输入与应答响应两部分去分析API是否存在漏洞。API安全测试的常规内容主要包含API身份验证、授权、输入验证、异常处理、数据保护、安全传输以及HTTP Header安全性等。

API数量多,且在不断的迭代更新,需要借助自动化工具来辅助进行安全测试。常用的工具有以下三类:SAST、DAST、IAST工具,在测试阶段提前发现研发的安全漏洞。根据业务的特点,和供应商一起优化IAST工具,保障覆盖率的情况下,提高准确率,能提前发现许多输入处理不当导致的漏洞。

静态安全检测(Static Application SecurityTesting,SAST),其特点是分析应用程序的源代码或二进制文件,通过语法、结构、过程、接口等来发现应用程序的代码是否存在漏洞。

动态安全检测(Dynamic Application SecurityTesting,DAST),其特点是在应用程序的动态运行状态下,模拟黑客攻击行为,分析应用程序的响应,而确定应用程序是否存在漏洞。

交互式安全检测(Interactive ApplicationSecurity Testing,IAST),相当于是DAST和SAST结合的一种安全检测技术,通常会在应用程序中添加探针或Agent代理,收集应用程、Web容器、JVM中的执行日志和函数调用信息,结合请求输入与响应消息,分析应用程序中是否存在漏洞。

这三类工具中,IAST使用过程稍显烦琐,但技术优势比较明显,漏洞检出率高于其他两类,同时漏洞误报率也低于其他两类,并可以快速定位代码片段和API接口,可以作为首选的自动化API安全测试工具,如果没有此类工具,则建议选择DAST类。

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章