HSTS vs只有https和安全cookie
如果我的网站使用安全会话cookie在https上提供服务并将任何针对http url的尝试重定向到https，是否足够好？HSTS vs只有https和安全cookie
什么样的安全漏洞可以在这个设置中暴露给我，因为我不能在没有设置HSTS头的情况下生存？
该策略通过使攻击者难以诱骗用户使用SSL以外的内容访问您的站点来防止被动窃听。它也可能确保用户存储的任何书签都将指向https网址，这很好。然而，在发生中间人攻击时，HSTS仍然具有优势。
HSTS试图解决的问题的核心是浏览器不知道给定站点是否应该使用SSL。而大多数用户并没有明确尝试使用SSL;如果他们输入一个URL，他们通常首先进入非SSL http站点，通常他们只是跟随链接。如果攻击者可以诱骗用户通过http URL访问您的网站，并且可以坐在用户流量的中间（例如通过他们的无线AP），那么攻击者可以发起中间人攻击通过代理用户的流量到您的网站并将网站呈现给用户而不使用SSL（这是一种降级攻击），从而针对您的网站。由于用户不会看到SSL，因此他们的浏览器不会识别出攻击者没有为您的网站提供有效的证书，并且他们没有直接连接到您的网站。 （更复杂的方法是拦截SSL流量并为您的站点提供自签名或其他无效证书，但这通常会导致浏览器警告。）
在这种情况下，将非SSL用户重定向到SSL或在Cookie上设置安全标志实际上并不能帮助您。中间人攻击者将连接到您的SSL站点（并将用户的行为代理到该站点），并在将它们传递给用户时从Cookie中移除安全标志。
攻击者当然也可以删除HSTS报头。但是，HSTS协议的要点是，如果用户过去成功直接进入您的网站，他们的浏览器将记住您的网站发送了HSTS。如果他们以后连接到您的网站并发现它没有使用SSL或者浏览器无法验证证书，则浏览器会抛出错误并拒绝继续。如果浏览器支持HSTS并将您的站点记录为需要SSL，这将防止攻击者将您的站点降级为非SSL。
*有fairly good discussion of this，我认为这比the RFC中的讨论要清楚些。