HTTP

页面。

通信流的这一未加密部分有其缺陷。

共享网络中的第三方和网络中介可以从最初的

HTTP

中间人攻击冒充网络服务器。

尽管如此重定向技术在从基本不加密的早期网络向大部分加密的当今网络过渡的过程中迈出了有用的第一步。

HTTP

Strict-Transport-Security告诉用户的浏览器从此只能在该域使用

MITM

从可用性和安全性权衡的角度来看这一切对于面向用户的网站都是合理的。

但有趣的是重定向方法似乎也被

API

主要由其他软件使用因此同样的可用性论点在这里并不适用。

此外许多

API

密钥以明文形式发送到网络上然后再将其发送到加密端点。

一个字母的遗漏可能会在我们不知情的情况下将使用的

API

幸运的是我们在代码审查期间发现了这个错误避免了错误扩散到生产甚至测试中。

我们还意识到我们自己的

API

客户端默默地跟随访问这些重定向时它往往会隐藏像上述案例中的拼写错误。

一个简单的字母遗漏很容易被忽略最终进入生产环境危及整个系统的机密性。

API

调用应以明显可见的方式失败这样开发人员可以在开发过程中尽早发现并修复拼写错误。

API

中间人攻击的机会窗口限制在极小的时间范围内。

这种方法适用于以自己的域名如

API

403。

在开发过程中可能会出现一些初始明文请求但开发人员更容易注意到它们。

还有谁

http://registry.npmjs.org/-/user/org.couchdb.user:npmFastmail

JMAP

http://api.fastmail.com/jmap/session…

API

http://graph.facebook.com/me?access_tokenfooIBM

Cloud

http://iam.cloud.ibm.com/identity/token

apikeyYOUR_API_KEY_HEREgrant_typeurn%3Aibm%3Aparams%3Aoauth%3Agrant-type%3Aapikey

Content-Type:

application/x-www-form-urlencoded

Authorization:

http://api.openai.com/v1/chat/completions…

我没有单独向所有这些

提供商报告这些发现。

有一些未列出的异常我确实联系了它们但结果各不相同。

HTTP

面向用户的应用程序的重定向经常在最佳实践列表和备忘录中被提及例如由

API

重定向的最佳实践项目都应该附加明确的注意事项在显著位置建议不要对

API

也许它们有自己的原因或者只是意外地错误配置了它们的反向代理。

不管怎样考虑到它们都处理潜在的敏感数据我通过各自的安全渠道联系了这些

API

请求中的敏感数据最初都是以明文形式在网络上传输的没有经过加密。

HTTP

接口或对未加密请求返回明确的错误响应。

这可以确保开发人员能够快速注意并修复意外的

http://