我正在为现有的移动应用程序构建一个新的服务层。移动应用程序通过在向身份验证端点的获取请求中提供用户名和密码作为 url 参数来使用现有服务层进行身份验证。这一切都发生在 ssl 上。
最初我认为这是不安全的,但这篇文章似乎表明它在传输层SSL 中使用 GET 和 POST并不是不安全的。唯一关心的是服务器如何记录请求。鉴于我正在编写服务器端并且可以控制日志记录,这是我应该担心的事情。我应该坚持应用程序团队更改客户端以发送发布请求以更好地保护密码,还是没有必要?
我正在为现有的移动应用程序构建一个新的服务层。移动应用程序通过在向身份验证端点的获取请求中提供用户名和密码作为 url 参数来使用现有服务层进行身份验证。这一切都发生在 ssl 上。
最初我认为这是不安全的,但这篇文章似乎表明它在传输层SSL 中使用 GET 和 POST并不是不安全的。唯一关心的是服务器如何记录请求。鉴于我正在编写服务器端并且可以控制日志记录,这是我应该担心的事情。我应该坚持应用程序团队更改客户端以发送发布请求以更好地保护密码,还是没有必要?
是的,坚持将请求更改为 POST。
这里的主要问题是用户名和密码将保存在日志中。作为最佳实践,任何日志都不应包含敏感信息,即使它们非常安全。
这在rfc2616中有明确规定:
15.1.3 在 URI 中编码敏感信息
因为链接的来源可能是私人信息或可能会泄露其他私人信息源,强烈建议用户能够选择是否发送Referer字段。例如,浏览器客户端可以有一个用于公开/匿名浏览的切换开关,这将分别启用/禁用Referer和From信息的发送。
如果引用页面是使用安全协议传输的,则客户端不应在(非安全)HTTP 请求中包含Referer 头字段。
使用 HTTP 协议的服务的作者不应该使用基于 GET 的表单来提交敏感数据,因为这将导致该数据被编码在 Request-URI 中。许多现有的服务器、代理和用户代理会将请求 URI 记录在第三方可能看到的某个地方。服务器可以改用基于 POST 的表单提交