This latest blog from ScotlandIS member, 速度反盗版, 强调了增强API安全性以保护关键基础设施的必要性.
API安全性对于保护任何组织的IT基础设施都至关重要. 如果网络攻击者能够滥用api，他们就可以从前门侵入组织.
这就是为什么ciso(首席信息安全官)和他们的团队越来越多地在API安全上投入资金. 根据 Future Market Insights, demand is estimated to grow at an incredible CAGR of 26.3% between 2022 and 2032, and is expected to reach US$10B by 2032.
API滥用
api(应用程序编程接口)允许软件与它所使用的后端服务进行通信, 而不暴露服务的所有内部细节或其工作原理. 例如, 手机银行应用程序将通过银行的API与银行系统对话，获取账户信息并发出交易请求. 这使得api对网络攻击者非常有吸引力，并且从网络安全的角度来看风险很高.
API滥用 falls into two categories:
- 未经授权的访问. 这是指api按照设计使用，但被不应该被允许使用它们的人使用. 通过对API的未经授权访问，攻击者可以恶意访问服务和数据.
- Vulnerability exploitation. APIs are software; and like all software are prone to defects (bugs). Attackers try to identify bugs that open up unintended functionality. If they can make an API behave in a way that is useful to them, it can give them a means to breach the organization.
保护api的传统方法是在服务器中构建防御. 这些防御措施监视来自API的流量——根据通过API的数据做出允许或不允许的决定. If the data looks right, it is allowed to pass. If an attacker can craft messages that look right, then they can get access to the API and the services behind the API.
This doesn’t mean these defenses are inherently bad. 恰恰相反:它们是网络安全难题的重要组成部分，而且往往非常复杂. 他们面临的挑战是，他们只看到了更大图景的一部分.
Our Director of Product Management, Neal米奇, spoke about how to “Become a hero to your DevSecOps team” at droidcon伦敦 2023.
Client Authentication to enhance API Security
服务器端防御看不到的一个重要方面是谁在发送数据. 因此，通过添加连接到API的客户机的身份验证，可以大大增强安全性. 将流量限制在合法和已知的客户端对阻止API滥用有很长的路要走.
The classic approach to authenticating clients is an API Key. 这是客户端在连接时传递给服务器的共享秘密(实际上是密码). As only an authorized client should know the API key, only authorized clients should be allowed to connect to the API. All other connections will be immediately rejected.
The Replay Attack Danger
这种方法的挑战与任何密码一样:一旦攻击者知道API密钥, they can “replay” it back to the server as many times as they like. 这允许他们对任何设备或脚本进行身份验证，就像它是一个合法的客户端应用程序一样.
API Keys can be exposed in a number of ways. 常见的方法包括逆向工程(稍后会详细介绍)或简单地从线路上嗅探密钥. 这样的工具 打嗝套件 允许攻击者对他们控制的应用程序实例进行中间人(MitM)攻击. MitM攻击使威胁参与者能够看到所有网络流量，包括API密钥.
Using cryptography to protect against replay attacks
经过验证的重放攻击的解决方案是加密挑战响应. This ensures that every authentication request is unique.
In practice, this means:
- 服务器生成唯一且不可预测的挑战，并将其发送给客户端.
- 客户端使用私钥对挑战进行加密签名，并将响应发送给服务器.
- 服务器使用与客户端持有的私钥相关联的公钥对响应进行加密验证.
因此，不再需要每次都向服务器发送一个固定的秘密. 相反，客户端发送一个只有服务器才能验证的动态响应值.
The Reverse Engineering Danger
到目前为止一切顺利, but let’s look at the case where the client is not another server, but instead is software running at the edge, e.g., a desktop application, mobile app, or IoT device. 在这种情况下，包含私钥的软件很容易被攻击者访问.
Software is not a locked box. 它可以很容易地被攻击者打开和分析，使用一种称为逆向工程的过程. Tools are freely available to extract software from a range of devices, decompile the code back to something readable, 仪器执行代码，以完全理解它在做什么.
Using reverse engineering, 攻击者可以快速且相对容易地从软件中提取加密密钥. They can then generate valid responses to the server’s challenge, authenticating themselves and tricking the server into granting access.
这就是为什么，在 2024 edition of their Mobile Top 10OWASP识别 Improper Credential Usage as the number one threat to mobile apps; with hardcoded credentials the top scenario described. Of course, the risk doesn’t just apply to mobile apps. 它存在于任何软件在边缘运行的地方，因此存在被威胁行为者分析的风险.
The need for white-box cryptography
从密码学上讲，这是使用服务器验证客户机的正确解决方案. 这种应用程序内加密的问题在于，在客户端软件中仍然存在一个秘密值:私钥. Just as with the API Key, the private key can be easily exposed. 这是 the danger of in-app cryptography.
为了解决这种危险，必须结合加密密钥保护. White-box cryptography, 从移动支付到视频DRM，这是一个在各种现实环境中得到验证的解决方案, effectively prevents the discovery of cryptographic keys within the code.
PACE has developed a 3rd-generation white-box called 白盒的作品. 这是一个软件开发工具，PACE的客户使用它来保护他们的高价值算法和数据，无论他们的软件在哪里运行.
传统的白盒库产品是单一且不灵活的sdk. 这意味着它们迫使开发人员将他们的架构屈从于白盒SDK. 与此形成鲜明对比的是, 3rd-generation white-boxes like 白盒的作品 empower the developer, 允许他们设计符合他们用例的软件架构.
要了解更多关于使用白盒加密进入API安全的知识， contact PACE to talk with our experts.
本文于2024年3月20日更新，包含了2024年OWASP移动十大应用程序的详细信息.