学做网站多久,信誉好的微网站建设,wordpress 高性能,wordpress4.7.4原文#xff1a;jviide - 2024.05.23
TL;DR: 与其将 API 调用从 HTTP 重定向到 HTTPS#xff0c;不如让失败显而易见。要么完全禁用 HTTP 接口#xff0c;要么返回明确的 HTTP 错误响应#xff0c;并撤销通过未加密连接发送的 API 密钥。遗憾的是#xff0c;许多知名的 A…
原文jviide - 2024.05.23
TL;DR: 与其将 API 调用从 HTTP 重定向到 HTTPS不如让失败显而易见。要么完全禁用 HTTP 接口要么返回明确的 HTTP 错误响应并撤销通过未加密连接发送的 API 密钥。遗憾的是许多知名的 API 提供商目前并没有这样做。
背景
当用户将网络浏览器指向 HTTP URL 时服务通常会将请求重定向到相应的 HTTPS 页面。通信流的这一未加密部分有其缺陷。共享网络中的第三方和网络中介可以从最初的 HTTP 流量中嗅探密码和其他机密甚至通过 MITM 中间人攻击冒充网络服务器。尽管如此重定向技术在从基本不加密的早期网络向大部分加密的当今网络过渡的过程中迈出了有用的第一步。
后来的技术进一步加强了安全性。现在服务器可以在发送 HTTP 到 HTTPS 的初始重定向响应的同时发送 HSTSHTTP Strict-Transport-Security告诉用户的浏览器从此只能在该域使用 HTTPS。这就将琐碎的嗅探和 MITM 中间人攻击的机会窗口限制在了第一次请求。随后浏览器增加了 HSTS 预加载列表和 HTTPS-Only 模式允许完全跳过初始未加密请求。
从可用性和安全性权衡的角度来看这一切对于面向用户的网站都是合理的。但有趣的是重定向方法似乎也被 API 广泛采用。API 主要由其他软件使用因此同样的可用性论点在这里并不适用。此外许多 API 客户端往往不会像浏览器一样保留他们所看到的 HSTS 标头状态。
本文认为由于这些因素应重新考虑将 API 调用从 HTTP 重定向到 HTTPS 的常见做法。虽然本文主要针对 REST API但其观点也适用于使用 HTTP(S) 作为传输机制的其他类型的 API。
一个简单的拼写错误就足够了
在工作中我们正在针对第三方 API 构建一个新的集成。初始代码提交中包含了一个拼写错误的 API 基础 URL写成了 http://... 而不是 https://...。这是一个相当容易犯的错误。
这个错误在运行时基本上被掩盖了第三方 API 对每个请求都会响应 301 重定向到其 HTTPS 端。Node.js 内置的 fetch 功能会愉快且悄悄地 跟随访问这些重定向到 HTTPS 端点。
注Go 语言默认的 http.Client 也会自动请求重定向后的端点除非自定义 CheckRedirect 属性。
现在这样的 API 请求都将 API 密钥以明文形式发送到网络上然后再将其发送到加密端点。一个字母的遗漏可能会在我们不知情的情况下将使用的 API 密钥暴露给第三方。随着集成的进行代码很有可能会在数年之间泄露 API 调用中的任何机密。从长远来看恶意的可能性会不断累积。
幸运的是我们在代码审查期间发现了这个错误避免了错误扩散到生产甚至测试中。我们还意识到我们自己的 API 也进行了类似的 HTTP 到 HTTPS 重定向。
快速失败原则
当 API 将 HTTP 请求重定向到 HTTPS而 API 客户端默默地跟随访问这些重定向时它往往会隐藏像上述案例中的拼写错误。一个简单的字母遗漏很容易被忽略最终进入生产环境危及整个系统的机密性。
在大多数情况下最好遵循快速失败原则未加密的 API 调用应以明显可见的方式失败这样开发人员可以在开发过程中尽早发现并修复拼写错误。
快速失败最好的解决方案是完全禁用 API 服务器的 HTTP 接口不再响应对 80 端口的连接尝试。如果初始的未加密连接从未建立那么就不会发送 API 密钥从而减轻嗅探攻击的风险并将 MITM 中间人攻击的机会窗口限制在极小的时间范围内。这种方法适用于以自己的域名如 api.example.com托管的 API。
我们自己的 API 位于 /api 路径下与我们服务的 Web UI 在同一个域名下。因此我们对完全禁用 HTTP 接口没有信心所以选择了第二种方案所有在 /api 路径下的未加密 HTTP 请求现在都返回描述性错误信息和 HTTP 状态码 403。在开发过程中可能会出现一些初始明文请求但开发人员更容易注意到它们。
还有谁
这解决了我们自己的 API 问题。我们还联系了第三方 API 提供商和几个朋友让他们检查一下自己的 API。谁知道呢也许有一些常用的 API 接受 API 密钥或其他凭证并且也从 HTTP 重定向到 HTTPS
我从脑海中列出了一些知名的 API并做了一个小调查。其中有几个返回 HTTP 错误或完全拒绝连接。这里列出了它们的 cURL 命令以便查看它们的详细响应
Stripe API返回 403 (“Forbidden”) 和一个描述性错误信息。 curl -i http://api.stripe.comNPM Registry API返回 426 (“Upgrade Required”) 和一个描述性错误信息。 curl -i -X PUT -H content-type: application/json -d {} http://registry.npmjs.org/-/user/org.couchdb.user:npmFastmail JMAP API整个 HTTP 接口似乎已被禁用。 curl -i -H Authorization: Bearer foo http://api.fastmail.com/jmap/session…
然而以下 API 确实 响应了 HTTP 到 HTTPS 的重定向
Facebook Graph API curl -i http://graph.facebook.com/me?access_tokenfooIBM Cloud API curl -i http://iam.cloud.ibm.com/identity/token -d apikeyYOUR_API_KEY_HEREgrant_typeurn%3Aibm%3Aparams%3Aoauth%3Agrant-type%3Aapikey -H Content-Type: application/x-www-form-urlencoded -H Authorization: Basic Yng6YngOpenAI API — 更新于 2024-05-28已返回错误。 curl -i -H Content-Type: application/json -H Authorization: Bearer 123 -d {} http://api.openai.com/v1/chat/completions…
我没有单独向所有这些 API 提供商报告这些发现。有一些未列出的异常我确实联系了它们但结果各不相同。
请谨慎对待每个结果我不得不在没有有效凭证的情况下测试其中一些 API或者使用文档示例中的凭证。但总体模式表明API 将 HTTP 请求重定向到 HTTPS 的习惯非常普遍。为什么会这样呢
最佳实践也需要实践
当与他人谈论这个话题时许多人都指出API 从 HTTP 重定向到 HTTPS 的缺点是显而易见的——事后看来是这样。
面向用户的应用程序的重定向经常在最佳实践列表和备忘录中被提及例如由 OWASP开放网络应用安全项目发布的那些。相反专门针对 API 的建议似乎很少。我只在 OWASP 网站的深处发现了几处提及例如一个出色的 PDF 幻灯片集由 Philippe De Ryck 编写名为常见 API 安全陷阱 “常见 API 安全陷阱”的第 8 张幻灯片重点强调了相关部分。
我的 Google 搜索技巧可能不够好。不过也许每个建议面向用户的网站进行 HTTP 到 HTTPS 重定向的最佳实践项目都应该附加明确的注意事项在显著位置建议不要对 API 进行此类重定向。因此我在 OWASP 的 GitHub 页面上发起了一个议题建议相应修改 OWASP 的传输层安全备忘单。
额外内容以明文响应的流行 API
在审查 API 列表时我碰到了一些既不重定向也不拒绝未加密请求的流行 API。它们只是以未加密的 HTTP 响应回应未加密的 HTTP 请求没有在任何阶段强制使用 HTTPS。
也许它们有自己的原因或者只是意外地错误配置了它们的反向代理。不管怎样考虑到它们都处理潜在的敏感数据我通过各自的安全渠道联系了这些 API 提供商并解释了这个问题。
结论
由于 API 的性质将 HTTP 重定向到 HTTPS 可能弊大于利。与面向用户的网页不同API 主要由其他软件使用。API 客户端通常会自动跟随重定向并且不会维护状态或支持诸如 HSTS 之类的安全标头。这可能导致静默故障即每个 API 请求中的敏感数据最初都是以明文形式在网络上传输的没有经过加密。
让我们采用“快速失败”的方法完全禁用 HTTP 接口或对未加密请求返回明确的错误响应。这可以确保开发人员能够快速注意并修复意外的 http:// URL 为 https://。我们应将通过未加密连接发送的 API 凭证视为泄露并立即自动撤销。
在撰写本文时一些知名且流行的 API 确实将 HTTP 请求重定向到 HTTPS。这种行为似乎很普遍也许是时候修改最佳实践明确建议 API 拒绝处理未加密的请求了。
