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