Skip to main content

14. Security Considerations (安全考虑)

本规范涉及HSTS策略的表达、传达和执行. 整体HSTS策略威胁模型, 包括已解决和未解决的威胁, 在第2.3节 ("Threat Model") 中给出.

此外, 以下各节讨论HSTS策略的操作影响, 提供功能原理, 讨论潜在的HSTS策略滥用, 并强调HSTS策略体系中的一些已知漏洞.

14.1 Underlying Secure Transport Considerations (底层安全传输考虑)​

本规范被设计为独立于HTTP底层的安全传输. 然而, 第2节 ("Overview") 中的威胁分析和需求实际上假定TLS或SSL作为底层安全传输. 因此, 在HTTP运行在其他安全传输协议之上的环境中使用HSTS, 将需要评估该安全传输协议的安全模型, 以及HTTP如何分层在其上的具体细节, 以便评估HSTS在该环境中的后续安全属性.

14.2 Non-Conformant User Agent Implications (非符合用户代理含义)​

非符合用户代理会忽略Strict-Transport-Security头字段; 因此, 非符合用户代理不能解决第2.3.1节 ("Threats Addressed") 中描述的威胁.

这意味着Web应用程序及其使用非符合UA的用户将容易受到以下两种情况的攻击:

被动网络攻击 (由于网站开发和部署错误)

例如, 如果Web应用程序包含任何对Web应用程序服务器的不安全引用 (例如, "http"), 并且如果其Cookie并非全部标记为"Secure", 那么其Cookie将容易受到被动网络嗅探的攻击, 并可能导致用户凭据被滥用.

主动网络攻击 (Active Network Attacks)

例如, 如果攻击者能够放置"中间人", 安全传输连接尝试可能会向用户发出警告, 但如果没有强制执行HSTS策略, 目前的常见做法是允许用户"点击通过"并继续. 这使用户和Web应用程序容易受到此类攻击者的滥用.

这本质上是在缺少HSTS策略时所有Web应用程序及其用户的现状. 由于Web应用程序提供商通常无法控制其Web应用程序与之交互的UA的类型或版本, 因此HSTS主机部署者通常必须像未声明HSTS策略时一样, 谨慎避免网站开发和部署错误 (参见第2.3.1.3节).

14.3 Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport (仅在无错误安全传输上建立HSTS策略的后果)​

第8节 ("User Agent Processing Model") 中定义的用户代理处理模型规定, 仅当UA通过没有底层安全传输错误或警告的安全传输连接接收到STS头字段时, 主机才会最初被记录为已知HSTS主机, 或者对已知HSTS主机的缓存信息进行更新.

这背后的理由是, 如果存在"中间人" (MITM) -- 无论是合法部署的代理还是非法实体 -- 它可能会造成各种恶作剧 (另请参见附录A ("Design Decision Notes") 第3项, 以及第14.6节 ("Bootstrap MITM Vulnerability")); 例如:

未经授权地将主机记录为已知HSTS主机

如果主机不能统一通过安全传输提供其服务, 则可能导致拒绝服务情况 (另请参见第14.5节 ("Denial of Service")).

重置主机作为已知HSTS主机的生存时间

通过操纵返回给UA的max-age头字段参数值来重置. 如果max-age返回为零, 这将导致UA不再将主机视为已知HSTS主机, 从而导致对主机的不安全连接, 或者如果主机仅通过安全传输提供服务, 则可能导致拒绝服务.

然而, 这意味着如果UA位于MITM非透明TLS代理"之后" -- 例如在公司内部网内 -- 并且与代理之外的未知HSTS主机交互, 则可能会向用户显示传统的安全连接错误对话框. 即使接受了风险并且用户"点击通过", 该主机也不会被记录为HSTS主机. 因此, 只要UA位于此类代理之后, 用户就会处于脆弱状态, 并且对于尚未知的HSTS主机, 可能会显示传统的安全连接错误对话框.

一旦UA成功通过无错误的安全传输连接到未知HSTS主机, 该主机将被记录为已知HSTS主机. 这将导致从干扰代理之后进行的后续连接尝试失败.

上述讨论与第12节 ("User Agent Implementation Advice") 中的建议相关, 即当存在警告和错误且主机是已知HSTS主机时, 应"无用户补救"地终止安全连接. 这种姿态保护用户免受"点击通过"安全警告并使自己处于危险之中.

14.4 The Need for includeSubDomains (includeSubDomains的必要性)​

如果没有includeSubDomains指令, Web应用程序将无法充分保护所谓的"域Cookie" (即使这些Cookie设置了"Secure"标志, 因此仅通过安全通道传送). 这些是Web应用程序期望UA返回给Web应用程序的任何和所有子域的Cookie.

例如, 假设example.com代表Web应用程序的顶级DNS名称. 进一步假设为整个example.com域设置了此Cookie, 即它是"域Cookie", 并且已设置其Secure标志. 假设example.com对于此UA是已知HSTS主机, 但未设置includeSubDomains指令.

现在, 如果攻击者导致UA请求Web应用程序中不太可能已经存在的子域名, 例如https://uxdhbpahpdsf.example.com/, 但攻击者已设法在DNS中注册并指向攻击者控制下的HTTP服务器, 那么:

  1. UA不太可能已经为"uxdhbpahpdsf.example.com"建立HSTS策略.

  2. 发送到uxdhbpahpdsf.example.com的HTTP请求将包含Secure标志的域Cookie.

  3. 如果"uxdhbpahpdsf.example.com"在TLS建立期间返回证书, 并且用户"点击通过"可能出现的任何警告 (可能但不确定可以为此类域名获取必需的证书, 因此警告可能出现也可能不出现), 那么攻击者可以获取本应受保护的Secure标志域Cookie.

如果没有"includeSubDomains"指令, HSTS无法保护此类Secure标志域Cookie.

14.5 Denial of Service (拒绝服务)​

HSTS可能被用来对网站发起某些形式的拒绝服务 (DoS) 攻击. DoS攻击是一种或多个网络实体针对受害实体并试图阻止受害者执行有用工作的攻击. 本节从HSTS的角度讨论此类场景, 尽管此列表并非详尽无遗. 另请参见 [RFC4732] 了解Internet DoS整体考虑的讨论.

仅通过HTTP可用的Web应用程序

如果攻击者能够导致UA为此类Web应用程序的主机设置HSTS策略, 则有机会对仅通过HTTP而不使用安全传输可用的Web应用程序 (或其关键部分) 发起DoS攻击.

这是因为一旦在UA中为Web应用程序的主机设置了HSTS策略, UA将仅使用安全传输与主机通信. 如果主机未使用安全传输或未将其用于Web应用程序的关键部分, 则Web应用程序将对UA的用户变得不可用.

注意: 这是UA提供"HSTS策略删除"功能的用例, 如第12.5节 ("HSTS Policy Deletion") 中所述.

可以通过各种方式为受害主机设置HSTS策略:

  • 如果Web应用程序存在HTTP响应拆分漏洞 [CWE-113] (可用于促进"HTTP头注入").

  • 如果攻击者可以伪造从不安全受害站点的重定向, 例如, 从 http://example.com/ 到 https://example.com/, 其中后者由攻击者控制并具有明显有效的证书. 在这种情况下, 攻击者可以为example.com以及example.com的所有子域设置HSTS策略.

  • 如果攻击者可以说服用户为受害主机手动配置HSTS策略. 这假设他们的UA提供此类功能 (参见第12节 ("User Agent Implementation Advice")). 或者, 如果此类UA配置是可脚本化的, 那么攻击者可以导致UA执行其脚本并为所需的域设置HSTS策略.

includeSubDomains的无意使用

includeSubDomains指令指示UA自动将给定HSTS主机的所有子域视为已知HSTS主机. 如果任何此类子域不支持正确配置的安全传输, 那么它们将从此类UA无法访问.

14.6 Bootstrap MITM Vulnerability (引导MITM漏洞)​

引导MITM (中间人) 漏洞是用户和HSTS主机在以下情况下遇到的漏洞: 用户手动输入或跟随链接到未知HSTS主机时使用"http" URI而不是"https" URI. 因为UA在初次尝试与指定服务器交互时使用不安全通道, 因此此类初次交互容易受到各种攻击 (参见 [ForceHTTPS] 的第5.3节).

注意: UA实现可以采用各种功能/设施来缓解此漏洞. 请参见第12节 ("User Agent Implementation Advice").

14.7 Network Time Attacks (网络时间攻击)​

主动网络攻击可以颠覆网络时间协议 (如网络时间协议 (NTP) [RFC5905]) -- 使HSTS对信任NTP或缺乏实时时钟的客户端效果降低. 网络时间攻击超出了本规范的范围. 请注意, 现代操作系统默认使用NTP. 另请参见 [RFC4732] 的第2.10节.

14.8 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack (伪造根CA证书钓鱼加DNS缓存投毒攻击)​

攻击者可以通过伪造根CA证书钓鱼加DNS缓存投毒攻击, 获取属于受害HSTS保护Web应用程序的用户登录凭据.

例如, 攻击者可以首先说服受害Web应用程序 (受HSTS策略保护) 的用户安装攻击者版本的根CA证书, 该证书错误地声称代表受害Web应用程序的CA. 这可以通过向用户发送钓鱼电子邮件, 其中包含指向此类证书的链接来完成, 如果点击, 他们的浏览器可能会提供安装.

然后, 如果攻击者可以对用户的DNS服务器进行攻击 (例如, 通过缓存投毒) 并为其虚假Web应用程序启用HSTS策略, 受影响用户的浏览器将访问攻击者的Web应用程序而不是合法的Web应用程序.

这种类型的攻击利用了HSTS范围之外的向量. 然而, 除了HSTS之外, 通过在Web应用程序的整体部署方法中适当使用DNS安全扩展 [RFC4033] 等安全设施, 以及阻止电子邮件钓鱼和虚假证书注入的技术, 可以降低此类威胁的可行性.

14.9 Creative Manipulation of HSTS Policy Store (创造性操纵HSTS策略存储)​

由于HSTS主机可以选择自己的主机名及其子域, 并且此信息缓存在符合标准的UA的HSTS策略存储中, 因此控制一个或多个HSTS主机的人可以将信息编码到他们控制的域名中, 并在记录HSTS主机的过程中使此类UA照常缓存此信息. 此信息可以由其他主机通过巧妙构造和加载的Web资源检索, 导致UA向编码域名的 (变体) 发送查询. 此类查询可以揭示UA之前是否访问过原始HSTS主机 (和子域).

这种技术可能被滥用为另一种形式的"Web跟踪" [WebTracking].

14.10 Internationalized Domain Names (国际化域名)​

Internet安全部分依赖于DNS及其托管的域名. 用户使用域名来识别和连接Internet主机和其他网络资源. 例如, 如果输入国际化域名 (IDN) 的用户根据IDN的不同解释连接到不同的主机, 则Internet安全会受到损害.

本规范中指定的处理模型假设它们操作的域名是IDNA规范化的, 并且规范化过程正确执行了所有适当的IDNA和Unicode验证以及每个必要规范的字符列表测试 (例如, 如第10节 ("Domain Name IDNA-Canonicalization") 中所述). 这些步骤是避免各种潜在危险情况所必需的.

简而言之, 缺乏仔细和正确的IDNA处理可能导致的问题示例包括:

  • 同形字攻击 (Homograph Attacks): 使用视觉上相似的字符创建欺骗性域名
  • 双向文本问题: 混合从右到左和从左到右的字符导致显示混乱
  • 规范化不一致: 不同的规范化方法导致相同域名的不同表示

因此, 实现者必须特别注意正确处理IDN, 以维护HSTS策略的安全属性.

Last updated on