RESTful Web 服务容易受到哪些类型的漏洞或威胁?
我在一个项目中工作,该项目公开了很多这些服务,但是缺乏任何验证或安全性。
RESTful Web 服务容易受到哪些类型的漏洞或威胁?
我在一个项目中工作,该项目公开了很多这些服务,但是缺乏任何验证或安全性。
在一个简短的非详尽列表中,您应该记住以下几点:
处理敏感数据时不要滥用 GET 请求
传递敏感数据时,始终使用具有安全连接 (https) 的 POST/PUT/DELETE。当然,需要适当的 SSL 认证和配置来确保通信不会被第三方解码。
对于 RESTful 身份验证,请避免在每个请求上传递凭据。
不要试图将 HTTP 错误代码用于身份验证错误 进行身份
验证时,无论身份验证失败还是成功,都尝试使服务以相同的方式运行。始终返回相同的 HTTP 错误代码(200 OK,但根据身份验证结果使用不同的正文)。这可能会使潜在的攻击者混淆他的技术是否有效,或者他是否发现了一个弱点,他们现在必须学习如何解释你的 API 的响应体。从 HTTP 响应中提供太多信息将有助于他们更快地定位自己。将 HTTP 错误代码留作真正的用途——通知 HTTP 通信问题。这对于将与 API 集成的开发人员也有好处,因为行为不那么模棱两可。
允许有限的身份验证尝试
拒绝来自在有限时间内执行过多不成功身份验证尝试的客户端的连接。如果您在少量尝试后无法登录,某些系统会阻止您在 10 或 30 分钟内再次进行身份验证。这可以降低 DDoS 攻击的风险,并且可以显着削弱任何暴力破解密码猜测尝试。
密码验证时间很重要
如果在服务器端使用密码加密,请在传入密码和存储在服务器中的密码之间使用这种比较算法,这样无论密码是否正确,比较密码所需的时间几乎相等。必要时添加自定义超时。这可以防止定时攻击 - 通常大多数算法会更快地拒绝错误的密码,并且黑客可能会使用响应时间差异来确定她/他是否越来越接近猜测密码。结合有限的身份验证尝试,可以防止这种情况。
CORS
通过使用 CORS,您还可以在运行到浏览器时限制您的 api 的允许用户。这可能是一个重大的安全改进,因为攻击者无法直接从他们的机器攻击您的 RESTful API,而是他们必须找到绕过 CORS 的方法。通过使用足够严格的 CORS 规则并在托管允许的 CORS url 的服务器上具有良好的安全性,可以进一步防止后者,这样攻击者就不会破坏可以直接访问 API 的允许 CORS 的机器。
当然,还有其他一些事情必须牢记在心,这些是我现在能想到的最重要的事情。
您还应该知道,请求/响应在 Firebug 的“网络”选项卡(或您正在使用的任何浏览器调试器)或任何附加的流量侦听器中仍然可见,因此网页上调用 REST 服务的任何人至少可以看到url 以及获取/请求和响应的数据。
传递和返回需要可视化和页面/应用程序正常工作的数据,永远不要返回密码或用户敏感数据等敏感信息。
与许多服务一样,RESTful 服务可能会成为 DDoS 攻击的对象,但后者的目标仍然是关闭服务,而不是破坏数据或完成授权/身份验证违规。