HTTP重定向到HTTPS风险捕获密码吗? [英] Does HTTP redirect to HTTPS Risk Capture of Password?

查看:143
本文介绍了HTTP重定向到HTTPS风险捕获密码吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在NGINX中设置了http-https重定向配置:

I have an http-https redirect configuration set up in NGINX:

server {
      listen         80;
      server_name    localhost;
      return         301 https://$server_name$request_uri;
}

我的问题是:是否在任何时候,用户最初访问我的应用程序的登录页面用于发布他的用户名+密码,这是在重定向到HTTPS之前通过HTTP清除凭据的时间吗?

My question is: Is there at any point, from the user initially accessing the login page of my application to POSTing his username+password, a time when the credentials are going clear over HTTP before being redirected to HTTPS?

推荐答案

这在某种程度上取决于您的登录表单(它应该始终仅发布到https网址),但根据此信息,我认为不是,当按预期使用时,密码总是超过https

It depends on your login form somewhat (it should always post to the https url only), but based on this info, I think no, the password always goes over https when used as intended.

但是,您可能需要注意一些事情并添加更多保护(深度防御),因为攻击的重点是使事情不按预期进行。 :)

However, you might want to note a few things and add more protection (defense in depth), because the whole point in attacks is to make things not go as intended. :)

从用户的角度来看,攻击者可能会降低与http的连接速度攻击者自己维护与服务器的安全连接。请注意,即使服务器甚至没有响应普通的http,这也会起作用。请参阅此视频此链接(以及其他许多内容)。解决方案是HSTS(见下文)。

An attacker might be able to degrade the connection to http from the user's perspective while the attacker himself maintains a secure connection with the server. Note that this would work even if the server does not even respond on plain http. See this video or this link (among many others). The solution is HSTS (see below).

如果攻击者可以注入普通的http请求以任何方式进入客户端浏览器,通过普通的http发送凭证,这些凭证将不受保护。这适用于发布的用户名/密码,但也适用于会话cookie,这相当于会话期间的用户凭据。所以这意味着如果攻击者可以插入带有 src =http://yoursite.com的图像,会话cookie将以明文形式发送。响应将根据您的nginx设置进行重定向,但为时已晚。始终将会话cookie设置为 secure 解决了这个问题(但不是另一个关于发布凭据的问题,可以通过HSTS进行缓解)。

If the attacker can inject a plain http request in any way into the client browser that sends the credentials over plain http, those credentials will not be protected. This applies to username/password being posted, but also to the session cookie, which is equivalent to user credentials for the duration of the session. So this means if the attacker can for example insert an image with src="http://yoursite.com", the session cookie will be sent plaintext. The response will be a redirect as per your nginx settings, but that's too late. Always setting your session cookie as secure solves this problem (but not the other one about posting the credentials, which can be mitigated by HSTS).

您的网站应该有一个 Strict-Transport-Security 响应标头,所以一旦浏览器有机会在没有中间人攻击者删除标题的情况下与服务器通信,即使用户未在网址栏中明确指定,也会记得使用https。

Your website should have a Strict-Transport-Security response header, so that once a browser had a chance to talk to the server without a man-in-the-middle attacker removing the header, it will remember to use https even if the user does not explicitly specify it in the url bar.

Strict-Transport-Security: max-age=31536000; includeSubDomains

有关HSTS的更多信息这里

More info on HSTS is here.

这篇关于HTTP重定向到HTTPS风险捕获密码吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆