WEB应用API的20种安全因素
笔者既从事网络安全，同时也算是个资深开发人员。日前读了一些关于WEB应用API的安全因素研究文章，觉得有必要吸收提炼一下，于是便概括形成了本文所述20种安全因素。
笔者：国际认证信息系统审计师、软考系统分析师
WEB应用API（以下简称API），也就是应用程序接口，是现在网络开发的主流模式。API直通应用数据，因此也是黑灰产着重尝试攻破的网络安全关键要点。
如果没有经过良好设计，API就成了能绕过所有安全防御手段的康庄大道。这是任何一个企业组织都不希望发生的事情。
1、API的设计是否简洁、简单。
任何复杂的设计都不可避免带来交叉组合的安全隐患。KISS原则是软件工程领域著名的原则，充分理解参透KISS原则，并基于KISS原则去设计API，是确保API安全性的第一因素。
2、维持API清单，并及时更新。
API也是企业组织的无形资产，因此需要有相应的资产化管理措施。而最起码地，应该文档化、记录化。通过API清单，企业组织才能清晰知道自己的风险敞口究竟有多大，才能选择正确的保护方式。
3、确保API本身，以及所有传入的参数都得到校验
WEB编程的其中一条原则是不能相信任何输入。API本身需要校验，API传入的所有参数也需要进行无遗漏的校验。通过充分有效的身份校验去避免API被滥用，通过结构化检查和数值边界检查防止恶意参数导致系统崩溃、数据泄露或代码注入，都是必要的过程。
而且，校验的过程应将调用者、API和参数三者结合在一起进行校验，以确保API的调用过程，是由合理的调用者以合理的参数发起。可以利用的信息包括云服务的角色机制，容器标识，命名空间，状态集合，网络节点等。
4、逆向思考API的实现机制
任何对API实施攻击的人都会通过API的表征逆向反推API的内部实现。作为开发人员，同样应该用类似的逆向思维模式，对代码进行审计，审视API的内部实现，并进行安全测试。通常这需要产生大量的边缘参数值或特殊参数值进行测试，需要依靠工具进行。
5、不要依赖API网关
API网关的作用并不是用于安全性，而是用于API的可扩展性。基于这个设计出发点，就不可能试图在API网关上完全解决安全问题。API网关本身就没有这个义务。
但需要指出的是，通过API网关集中API接口，然后结合一些前置的防御手段比如WAF设备，这还是能相对地提高这些防御手段的有效性。
6、基于HMAC措施加强身份验证
只依赖于用户名和密码组合的基本身份验证，是不足以面对当前网络威胁的。而HMAC身份验证，即基于哈希的消息身份验证方式，不仅因HASH值的强度高于一般密码，还能限制允许访问特定的URI资源、施加访问时间戳限制等措施，进一步提高了安全性。
7、不要通过API传递权限标识
任何API调用过程都有可能被拦截，被穷举，尤其是不能避免中间人攻击的情况（MITM）。因此，API参数不应传递直白的敏感信息，比如权限标识。正确的做法是通过登录会话管理，结合第6点的HMAC身份验证措施，分离特权验证和API功能调用。
8、确保不要直接在源码中嵌入密码、秘钥之类敏感信息
类似的例子，即因为直接嵌入敏感信息到源码，导致耗费大量人力物力进行补救的情况，在互联网上发生了无数次。即使是“临时”，也应以谨小慎微的态度，确保不会发生这种情况。API本身的实现过程也是同样的道理，而且因为API需要被外部调用的特点，直接嵌入敏感信息所导致的衍生问题更多。
分离敏感信息到独立的配置文件，并妥善设置文件的访问控制，在需要时才读取，这一切其实花不了多少开发时间。
9、实现API日志，并对日志进行审计
所有的API活动情况都应该实现日志记录，安全人员应定期对日志进行审计，通过日志记录判断是否存在对API的滥用和攻击行为，并可以针对性地调整API的安全设计，加强API的安全性。
10、不要盲目相信开源代码
所有用于严肃的环境，比如交付产品的代码，都应进行代码审计。开源代码并不代表其是安全可靠的，甚至有些开源代码出于各种原因根本就没有经过正式的测试，被使用只是因为它们“能用”而已。
11、选择和应用程序的模型相适配的外源API
在应用程序的开发过程中，引入何种外源API是架构师要面对的问题。如果从安全性出发，架构师应将应用程序抽象模型视为一个整体对象，然后评估引入外源API后，对象的完整性是否能保持完好。如果不能维持对象的完整性，则可以认为拟引入的外源API并不安全。
12、使用API的新版本并不等于安全性更高
安全性是需要时间验证的。如果API的新旧版本同时并存，无疑旧版本的安全性会因为经受了时间的考验而更高。同时，在切换到新版本之前，应对新版本的安全性进行彻底的评估，而不是简单地因为新版本提供了更多的功能特性就去使用它。这实际是“第一性原理”在软件工程上的实践。
13、积极向API的开发商反馈问题
如果在测试评估中发现API存在漏洞，应积极向API的开发商反馈问题，对于开源API，应积极参与反馈代码补丁。简单地通过外部方式绕过问题，并不等于解决问题，而只是留下隐患。
常见的方式，比如使用WAF（WEB应用防火墙）等设备去掩盖安全问题就是一种典型情况。但WAF并不是万能，即使是AI加持的下一代WAF，也依然会存在滞后缺陷。
14、保护API的调用者
这听起来有点古怪，但这也是逆向思维的一种。对于不是完全公开性质的API，比如企业组织内部应用系统的API，保护调用者就等于保护API本身。因此，无论调用API的是什么，比如自动化程序、脚本甚至是人工，都应该确保发起调用的环境是具有一定安全性的，从而防止API调用过程的数据被窃取。
15、最小特权原则
最小特权原则是计算机安全领域的通常要求。该原则不仅对人有意义，对软件程序同样具备意义。但在软件开发实践中，尤其是API的设计实现中，如果不经过良好的设计和代码审计，是不可能确保最小特权原则得到遵循。
最小特权原则在API环境的应用，在互联网上有很多实例，有些其实也很简单，比如典型如分权分级，IP白名单等等。总之并无固定必须实现的方式，只要是能确定调用API时，调用方不会出现滥用现象。
16、引入红队对API进行渗透测试
由于软件开发人员的通病，即会在潜意识中避开自己代码的漏洞，因此自我进行的代码审计和测试并不能确保发现所有问题。引入一支专业的红队，或者在企业组织内部组建紫队，是良好有效的手段。
红队可以对应用程序和API进行评估，建立威胁模型，然后进行渗透，无论渗透成功与否，相应的过程记录都可以为应用程序和API的开发者在未来的开发过程中实现安全性而提供支持。
17、API内部的授权细分
API需要访问后端的数据库资源，而如果所有的API都使用相同的账号密码去访问数据库，则极容易出现单一API缺陷暴露敏感信息就等于全部API暴露的重大纰漏。实际这也是最小授权原则的一种更具体的做法，就是细分不同的API使用不同的、有针对性的账号密码（和对应的权限）去访问数据库。
除了对数据库的访问外，API内部实现对其它资源的访问，也应尽可能按最小授权原则，细化拆分访问资源的授权信息。
18、规范管理和保护API运行时产生的数据流
任何安全保护措施都要先基于规范化的管理。尤其是对于数据流，需要先从数据流向架构开始规划，确定数据传输、交换所基于的数据结构、表达方式、加密要求，与具体网络安全控制措施相结合进行评估并文档化，从而确定网络安全控制措施是满足实际要求并且是可持续发挥保护作用的。
19、在底层架构考虑减少攻击敞口
一些最新的底层架构，比如容器技术、无服务器架构等，如果没有经过良好的安全规划和实现，是完全有可能在应用期间引入更多且难以控制的风险因素。因此，在选择底层架构时，应从安全可靠出发，并持续地把安全要求贯穿到架构落地的整个过程中，这也是现在DevSecOps开发模式得到业界关注的原因之一。
某些观点认为，可以通过无服务器架构（Serverless）“临时性”的特点，避免长期占用固定的网络资源（IP地址），从而减少API的固定敞口。但这需要良好的实现和公有云服务商的支持。
20、人
最后也是最关键的因素是人。无论是对API进行开发抑或只是运维，团队中都需要有同时熟悉API设计和网络安全风险因素的技术人员，这才能真正实现把安全意识贯穿整个API生命周期。这也是本文的概括性结论：
API的安全风险需要持续关注和适度控制。
熟悉CIS控制措施的读者应该清楚，网络安全风险无处不在，为控制风险需要付出的成本是需要企业组织认真衡量的。具体采取的方法也并不一定完全能符合本文所总结的20条，即使是第一条，KISS原则也并不容易做到，更无论最后一条，从何处可以找到可靠的人才。
本页网址二维码：