API 安全性是几乎所有应用程序中需要注意的最重要方面之一。
如今,API 是将您的应用程序与其他应用程序集成的最佳方式。 它们为您的应用程序提供了一个网关,因此,API 需要足够安全,以便您不会遇到不需要的访问者。
让我们看一下一些可能对您的应用程序构成威胁的 API 漏洞。
目录
常见API漏洞
#1. 跨站脚本(XSS)
XSS 攻击在 Web 应用程序中很常见,但如果传入的用户数据未得到正确清理,也可能通过 API 发生。 攻击者可以在服务器上运行恶意脚本并访问敏感数据。
#2. 违反速率限制
违反 API 的速率限制功能可能会让攻击者有机会用大量请求轰炸您的服务器。 最终,服务器可能会崩溃,您的客户群可能很难联系到您。
#3。 认证不当
如果未使用可靠的身份验证方法正确配置 API,则任何第三方都可以通过 API 访问您的系统。 授权也很重要,因为它定义了谁可以在指定的时间内访问哪个 API 资源。
#4。 不安全的数据传输
发送给 API 使用者的数据必须在途中加密。 如果不是,那么攻击者可能会使用中间人攻击来泄露数据。 这就是为什么始终建议使用 HTTPS 等安全协议来传输数据。
#5。 已弃用/过时的依赖项
API 有很多外部依赖项,用于执行复杂的任务并卸载一些复杂的逻辑。 如果这些依赖项存在漏洞,那么您的 API 也会间接变得脆弱。 始终确保更新依赖项版本。
现在您已经了解了 API 漏洞,让我们看看一些保护 API 的最佳实践。
另请阅读:为开发人员测试 API 的最佳 Postman 替代方案
API 安全 – 最佳实践
API版本控制
使用更新的依赖项定期监控和更新 API 至关重要,因为这些依赖项可能包含重大漏洞。 您可以根据API发布补丁版本的方式通知API用户 语义版本控制。
为了防止攻击者利用您的 API,您至少可以做的就是保持 API 处于最新状态。
验证
您可以通过多种方式对 API 用户进行身份验证。 最简单的方法是使用用户名/密码方法,但这太基本了,并且仅依赖于密码的强度。
另一种方法是使用 API 密钥来访问 API。 您可以为每个 API 用户提供一个他们可以使用的唯一密钥。
JWT 身份验证是一种将用户凭据转换为数字签名令牌然后发送给用户的技术。 然后,用户在每个请求中将相同的令牌发送回服务器,以便服务器进行验证。 JWT 也有过期时间。
最有效的解决方案是 OAuth。 它允许第三方使用现有的登录凭据访问 API。 例如,如果您已经登录 Google,应用程序可以使用这些凭据登录您的帐户,而无需密码。 您的 Google 帐户将成为密码。
授权
授权与身份验证不同。 当您授权用户时,他们已经通过身份验证可以使用您的 API,并且只是他们可以访问哪些 API 资源。
例如,大学教授可能可以访问一批中的所有学生,但单个学生只能访问他们的数据。 在这种情况下,学生和教授通过同一系统进行身份验证,但仅被授权执行某些操作。
确保 API 授权正常运行可以防止对资源的未经授权的访问。
数据编辑
数据编辑是有选择地向用户披露信息并保护敏感信息的过程。 适当的授权可以带来更好的数据编辑。 GDPR 等数据隐私法规也基于数据编辑。 任何不需要的第三方都应该无法窥视个人或敏感数据。
您可以通过实施中间件或网关管理器来实现数据反应。
加密
这已成为当今世界最重要的安全检查。 如果您要处理任何类型的敏感信息,加密是必须的。 您可以执行的最少加密是使用 HTTPS 协议,该协议使用 TLS(传输层安全)握手和 SSL(安全套接字层)。
端到端加密是严格保护传输中数据安全的另一种方法。 存储在数据库中的数据也应该加密,以防攻击者能够闯入数据库并访问数据。
错误处理
有关应用程序基础设施的信息可能会通过详细的错误消息泄露给攻击者。 为了避免这种情况,请保持错误消息通用并实现自定义错误处理。 确保错误详细信息中没有记录任何敏感系统信息。
输入验证和数据清理
在处理 API 时,输入验证非常重要,因为在用户发送输入之前您不知道输入。
清理是从有效负载中删除任何不需要的可执行代码的过程。 攻击者可以输入 Javascript 脚本,如果您在将其传递到 HTML 之前不对其进行清理,它将作为脚本执行并获取数据。
不当的清理可能会导致跨站点脚本(XSS)攻击。
入侵检测系统
入侵检测系统也称为 IDS,有助于监控和检测传入 API 的网络流量。 如果它发现流量中有任何异常行为,它可以记录并向有关当局发出警报。
一般来说,有两种类型的系统:基于网络的系统和基于主机的系统。 在基于网络的系统中,系统分布在不同的检查点以监控多个点的流量。 在基于主机的系统中,它部署到单个主机。
此类系统是在阻碍您的数据之前确定谁正在尝试访问您的网络的好方法。
IP白名单
IP 白名单是一种仅允许选定的 IP 地址访问您的 API 和网络的方法。 如果您有公共 API,则此技术可能不起作用,因为列出每个 IP 太复杂。
如果您知道系统中只有某些应用程序将访问您的 API,那么这将是有益的。
JSON 网络令牌
JWT 通常用于通过向用户发送根据其凭据创建的数字签名令牌来对用户进行身份验证。 它之所以有效,是因为它隐藏了用户的实际凭据,并且您也不需要将凭据存储在数据库或用户端。
JWT 可以分为三个部分:标头、负载和签名。 有效负载部分包含用户凭据,标头可以包含所使用的算法等信息。 签名部分由服务器和客户端对每个后续请求进行数字签名。
JWT 通常有一个到期日期,之后服务器会生成新的令牌,然后发送给用户。
记录和监控
监控 API 流量有助于提前检测和识别不需要的访问者。 您可以监控每个请求,但请确保日志不包含任何敏感信息。
速率限制
如果 API 没有实施速率限制,则由于网络流量的意外涌入,它很容易受到 DDoS 攻击。 攻击者可以在短时间内向系统发送大量请求,最终导致服务器崩溃。
节流和速率限制 API 通过限制 API 流量来避免拒绝服务攻击。
安全依赖
漏洞不仅出现在您的 API 代码中,还可能是您在 API 中使用的任何第三方依赖项的一部分。 这就是为什么定期监视和扫描依赖项并检测其中可能存在的任何漏洞非常重要。
如果可以使用修复漏洞的补丁版本更新依赖项,您可以实施计划作业来定期扫描和更新依赖项。 此外,选择更安全并提供频繁安全更新的依赖项。
安全标头应与 API 响应一起返回,以指示浏览器了解 API 安全性及其应如何操作。 您可以发送以提高安全性的重要标头包括:
- Cache-Control:设置为no-store,以避免在浏览器中存储敏感信息。
- Content-Security-Policy:将其设置为frame-ancestors“none”可以避免在iframe中构建API响应。
- Content-Type:此标头很重要,因为如果没有它,浏览器会尝试猜测 API 响应的类型,并且可能导致嗅探攻击。 对于 JSON 响应,您可以将其设置为 application/json。
- X-Content-Type-Options:将其设置为 nosniff 以指示浏览器不要猜测响应的 MIME 类型,而仅在 Content-Type 标头中查找它。
安全标准和框架
借助预定义的安全标准和框架来设计您的 API,以确保您的 API 符合最新的安全注意事项。
令牌到期
如果您使用不记名令牌,则令牌到期时间应该很短,因为它需要对用户进行重新身份验证,这是一件好事。 在 JWT 中,通常有两种令牌:访问令牌和刷新令牌。 刷新令牌是长期存在的,而访问令牌是短暂的。 无论如何,您的令牌应该有一个到期时间。
网络应用防火墙
WAF(又名 Web 应用程序防火墙)是一个监视、过滤和阻止任何恶意网络流量的网关。 通常是防止通过 HTTP 协议进行恶意攻击的最佳方法。
使用 API 网关
如果您想轻松设置 API 安全性并管理 API 路由及其访问,可以选择 API 网关。 他们还提供监控、日志记录和分析工具,您可以使用它们来监控您的 API。
零信任
零信任策略背后的想法是不信任任何集中的来源。 安全性应该分层并在多个检查点实施。
基本上,没有人可以信任,即使是 API 开发人员。 应监控和分析每个网关,以防止安全漏洞。
在这种情况下,自动化会派上用场。 您可以使用自动化工具定期监控和阻止异常或可疑活动。
最后的话
为了保证 API 的安全,您只能做这么多。 软件中总是存在一些可以被利用的漏洞。 此类漏洞会导致零日漏洞。 因此,为了保护您的 API,您至少可以做的就是让它们保持最新的安全标准。
看看最好的动态应用程序安全测试工具。