RESTful Web服务容易受到哪些类型的漏洞或威胁？
我从事的项目暴露了很多这些服务，但缺乏任何验证或安全性。
答案 0 :(得分：3)
在简短的非详尽列表中，您应该记住以下几点：
处理敏感数据时不要滥用GET请求
传递敏感数据时，请始终使用POST / PUT / DELETE和安全连接（https）。当然，需要正确的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攻击的主题，后者仍然旨在关闭服务而不是破坏数据或完成授权/身份验证违规。