使用HTTP安全头部强化Web应用防护

本文详细介绍了HTTP安全头部在Web应用安全中的关键作用,包括CSP、HSTS等核心安全头部的配置方法和防护原理,以及如何通过动态应用安全测试维护这些安全措施的有效性,帮助开发者构建更安全的Web应用。

使用HTTP安全头部强化Web应用程序

什么是HTTP安全头部?

HTTP安全头部是一种响应头部,通过向浏览器提供有关如何安全处理网站内容的具体指令,帮助保护Web应用程序。这些头部在缓解各种网络威胁(如跨站脚本(XSS)、点击劫持和数据注入攻击)方面发挥着至关重要的作用。通过正确配置HTTP安全头部,组织可以实施更严格的安全策略,限制未经授权的资源加载,并降低恶意利用的风险。

常见的HTTP安全头部包括:

  • 内容安全策略(CSP):防止注入攻击
  • 严格传输安全(HSTS):强制执行安全的HTTPS连接
  • X-Frame-Options:防止点击劫持

实施这些头部是增强Web应用程序安全性的基本且有效的方法,提供了针对网络威胁的额外防御层。

使用HTTP安全头部增强Web应用程序安全性

在Web应用程序安全测试中,漏洞通常被视为应用程序代码中可利用的弱点,必须在源头解决。这通常导致修复特定应用程序中的单个缺陷,通常仅限于代码的一个区域。

然而,HTTP安全头部在运行时级别运行,提供了更广泛和更动态的保护层。通过在应用程序上线后为浏览器和服务器交互定义严格规则,这些头部有助于防止整个类别的网络威胁,使其成为高度有效的安全措施。正确配置和实施这些头部是强大安全态势的关键组成部分。挑战在于选择最有影响力的头部,并确保它们在应用程序环境中一致地应用和测试,以维护安全性和功能性。

通过动态应用程序安全测试(DAST)维护HTTP安全头部的有效性

与许多其他Web技术一样,HTTP协议头部随着时间的推移而发展,受到不断变化的规范和浏览器供应商支持的影响。安全研究通常比官方标准发展得更快,导致独立于正式规范的事实安全实践的兴衰。曾经广泛采用的头部可能变得过时,被更新、更有效的替代方案所取代——这使得保持更新变得具有挑战性。

此外,安全头部可以在服务器级别和应用程序本身内部配置。在拥有数百台服务器支持数千个网站、应用程序和API的复杂环境中,手动管理和审计所有接触点的安全头部是不切实际的。这就是自动化漏洞扫描工具发挥作用的地方。高级工具,如Invicti的DAST解决方案,可以自动检测HTTP安全头部的存在和正确配置,并根据最新的安全最佳实践提供清晰的建议。

基本HTTP安全头部

首先,让我们看看每个现代Web应用程序都应实施的两个最广泛认可的HTTP响应头部。除了显著降低整个类别的基于Web的攻击风险外,这些头部已成为维护安全在线存在的基本必需品。

严格传输安全(HSTS)

HTTP严格传输安全(HSTS)头部是一种关键的安全措施,确保Web应用程序仅使用加密的HTTPS连接,防止未加密的HTTP通信。在服务器级别配置,HSTS有助于防止中间人(MITM)攻击和协议降级尝试。

典型的HSTS头部可能如下所示:

1
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

此指令告诉Web浏览器,该站点及其所有子域必须在接下来的两年内(由max-age值以秒为单位指定)仅通过HTTPS访问。preload指令表示该站点包含在全局仅HTTPS域列表中,通过消除初始未加密连接的风险进一步增强了安全性。此外,预加载通过确保浏览器即使在首次访问时也从不尝试通过HTTP连接来提高性能。

内容安全策略(CSP)

内容安全策略(CSP)头部是最多功能和最强大的HTTP安全头部之一,提供了对Web应用程序可以加载内容的来源的细粒度控制。通过为允许的内容来源(包括脚本、样式、图像和其他资源)定义严格规则,CSP可作为对抗跨站脚本(XSS)攻击和其他代码注入威胁的有效防御。

限制所有资源为同一来源的基本CSP头部如下所示:

1
Content-Security-Policy: default-src 'self'

除了此默认设置外,CSP允许更具体的指令,如script-src、style-src、object-src和img-src,分别定义JavaScript、CSS、嵌入对象和图像的可信来源。例如,设置script-src ‘self’确保仅托管在同一来源上的脚本可以执行,同时仍允许其他资源从外部加载。正确实施CSP显著降低了未经授权的脚本执行风险,并增强了Web应用程序的整体安全态势。

其他HTTP安全头部

虽然内容安全策略(CSP)和严格传输安全(HSTS)是最基本的安全头部,但其他几个HTTP头部可以以最少的努力进一步增强Web应用程序的防御。尽管它们可能不那么关键,但这些头部提供了针对各种基于Web的威胁的宝贵保护,通常实现的安全增强如果仅通过应用程序代码实施将更加复杂。

X-Content-Type-Options

X-Content-Type-Options头部通过防止Web浏览器"嗅探"MIME类型并将文件错误解释为可执行脚本来增强安全性。当包含在服务器响应中时,此头部确保浏览器严格遵守Content-Type头部中声明的MIME类型,降低利用MIME嗅探执行恶意代码的攻击风险。

为了强制执行此保护,该头部使用单个指令:

1
X-Content-Type-Options: nosniff

通过实施此头部,网站可以减轻某些跨站脚本(XSS)和路过式下载攻击的风险,确保内容仅按服务器的意图处理。

跨源资源共享(CORS)头部

现代Web应用程序通常需要与其自身域之外的外部资源交互,需要对浏览器强制执行的同源策略(SOP)进行受控例外。几个HTTP头部允许开发人员选择性地放宽这些限制,同时保持强大的安全措施。

  • Access-Control-Allow-Origin:定义哪些域被允许跨源访问资源。值可以是特定域、多个域或以允许所有来源(尽管应谨慎使用)。
  • Cross-Origin-Opener-Policy (COOP):确定顶级文档是否可以与跨源页面共享其浏览上下文。将其设置为same-origin可防止未经授权的跨源访问。
  • Cross-Origin-Resource-Policy (CORP):指定哪些域可以加载特定资源。使用same-site将访问限制为同一来源,防止外部站点包含该资源。
  • Cross-Origin-Embedder-Policy (COEP):类似于CORP,但专门管理嵌入内容。require-corp指令确保只有来自允许来源的资源(由CORP头部定义)可以被嵌入。

由于安全头部通常在功能上重叠,可能需要多个配置来实现所需的安全态势,同时保持必要的跨源功能。正确实施CORS头部确保了与第三方资源交互的Web应用程序在安全性和互操作性之间的平衡。

获取元数据头部

获取元数据头部是一组较新的客户端HTTP头部,提供了有关如何发起请求的额外上下文,允许服务器实施更严格的安全策略。这些头部帮助浏览器向服务器传达应用程序特定的请求属性,提高对抗跨站请求伪造(CSRF)、跨源攻击和推测执行威胁的保护。

四个关键的获取元数据头部包括:

  • Sec-Fetch-Site:指示请求发起者与目标来源之间的关系(例如,same-origin、cross-site、same-site)。
  • Sec-Fetch-Mode:指定请求模式,如cors、navigate或no-cors,帮助服务器确定请求的方式。
  • Sec-Fetch-User:标识请求是否由用户交互(如点击链接)触发。
  • Sec-Fetch-Dest:定义预期的请求目的地,如document、image、script或style。

当浏览器和服务器都支持这些头部时,它们通过使服务器能够验证请求行为并阻止潜在的恶意活动来提供额外的安全层。正确配置后,获取元数据头部通过允许更精细地控制资源的访问和使用方式来增强Web应用程序安全性。

用于隐私和安全的其他HTTP头部

虽然不严格分类为安全头部,但某些HTTP头部通过控制信息在网页和服务器之间共享的方式,在增强数据隐私和安全性方面发挥着至关重要的作用。其中一个头部是Referrer-Policy,它有助于调节在向另一个Web服务器发出请求时应包含多少引用URL信息。

Referrer-Policy

此头部确定浏览器在向另一个Web服务器发出请求时应包含多少引用URL。常用的指令是:

1
Referrer-Policy: origin-when-cross-origin

使用此设置,浏览器在同一源内导航时发送完整的引用URL,但在发出跨源请求时将其限制为仅来源(域)。这种方法通过防止外部站点访问完整的浏览路径来帮助保护用户隐私,同时仍允许同一站点内有用的引用数据。

通过实施Referrer-Policy,网站可以在维护分析功能和减少向外部域泄漏敏感URL参数的风险之间取得平衡。

Cache-Control:管理网页缓存

Cache-Control头部提供了对浏览器和中间服务器如何缓存网页和资源的细粒度控制。正确配置此头部对于性能优化和数据安全至关重要,确保敏感信息不会无意中存储或从缓存中检索。

用于防止缓存的常用指令是:

1
Cache-Control: no-store

此设置确保响应永远不会存储在任何缓存中,这对于处理机密数据(如登录会话、金融交易或个人信息的页面特别有用。

其他Cache-Control指令允许进一步自定义,例如设置过期时间(max-age)、要求重新验证(must-revalidate)或指定私有与共享缓存的行为。通过利用Cache-Control,网站可以在基于其特定需求优化内容交付的同时增强安全性。

Clear-Site-Data:确保注销后的用户隐私

Clear-Site-Data头部通过指示浏览器在用户注销或会话结束时清除特定类型的存储数据来帮助增强安全性和隐私。这可以防止机密信息滞留在浏览器中,降低未经授权访问的风险。

清除所有存储站点数据的常见实现是:

1
Clear-Site-Data: "*"

此指令清除与站点关联的所有缓存内容、cookie和存储的会话数据。或者,更具体的指令(如cache、cookies和storage)允许对要删除的数据类型进行更精细的控制。

虽然尚未在所有浏览器中普遍支持,但Clear-Site-Data是加强用户隐私的宝贵工具,特别是在处理敏感信息(如金融服务、医疗保健或基于身份验证的平台)的应用程序中。

Permissions-Policy:控制对浏览器功能的访问

以前称为Feature-Policy,Permissions-Policy头部使开发人员能够限制或允许访问网页的各种浏览器功能和API。虽然它可以用于控制应用程序功能,但其主要目的是通过限制对敏感资源(如麦克风、摄像头和地理位置)的访问来增强隐私和安全性。

要阻止所有这三个功能,您可以使用:

1
Permissions-Policy: microphone=(), camera=(), geolocation=()

此配置显式禁用对麦克风、摄像头和地理位置API的访问,防止脚本或嵌入内容未经授权使用。其他指令允许更细粒度的控制,例如限制对特定域的访问或仅在某些上下文中允许功能。

通过实施Permissions-Policy,网站可以减少攻击面,减轻隐私风险,并确保只有必要的功能对用户可用。

已弃用的HTTP安全头部:回顾过去

在Web安全的早期,主流浏览器经常引入新的HTTP头部作为对新出现威胁的临时修复。然而,随着Web安全标准的发展并变得更加结构化,许多这些头部被弃用——有时仅在几年内。虽然它们不再推荐用于现代应用程序,但这些已弃用的头部为了解Web安全技术的快速发展提供了宝贵的见解。

(已弃用)X-Frame-Options

最初由Microsoft Internet Explorer于2008年引入,X-Frame-Options头部旨在防止涉及HTML iframe的跨站脚本(XSS)攻击。在引入更标准化的安全机制之前,此头部提供了一种控制网页是否可以在iframe中嵌入的方法,有助于减轻点击劫持攻击。

要完全阻止iframe嵌入,站点可以使用:

1
X-Frame-Options: deny

或者,将其设置为sameorigin允许页面仅在父框架来自同一来源时在iframe中加载:

1
X-Frame-Options: sameorigin

还有一个allow-from指令,允许特定的受信任URL嵌入页面。然而,此头部最终被内容安全策略(CSP)标准中的frame-ancestors指令所取代,该指令提供了对iframe嵌入的更细粒度和灵活控制。

虽然已弃用,但X-Frame-Options在现代Web安全实践的发展中发挥了至关重要的作用,展示了安全策略必须如何快速适应不断发展的威胁。

已弃用的HTTP安全头部:过去的教训

多年来,各种HTTP安全头部被引入作为对不断发展的安全威胁的临时修复。然而,随着Web安全标准的改进和更好的解决方案出现,许多这些头部变得过时。以下是三个值得注意的已弃用安全头部,后来被更有效的替代方案取代。

(已弃用)X-XSS-Protection

X-XSS-Protection头部最初设计用于通过利用Web浏览器中的内置XSS过滤器来减轻跨站脚本(XSS)攻击。典型的实现如下所示:

1
X-XSS-Protection: 1; mode=block

此设置指示浏览器检测并阻止可疑的JavaScript注入攻击。然而,由于内容安全策略(CSP)的进步和攻击者绕过XSS过滤器的能力增强,现代浏览器已移除此头部的支持。今天,CSP指令作为对抗XSS攻击的主要防御,使X-XSS-Protection过时。

(已弃用)Public-Key-Pins (HPKP)

HTTP公钥固定(HPKP)被引入以防止证书欺骗,允许网站指定在未来的HTTPS连接中应信任哪些加密密钥。服务器将提供有效证书公钥的哈希,如本例所示:

1
Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; max-age=5184000

虽然HPKP旨在加强安全性,但它被证明过于复杂和风险——错误配置可能将用户锁定在网站外较长时间(例如,两个月,由max-age定义)。由于这些挑战,HPKP被弃用,支持证书透明度(CT)日志和Expect-CT头部——尽管该解决方案也没有持续下去。

(已弃用)Expect-CT

在HPKP弃用之后,Expect-CT头部被引入作为强制执行证书透明度(CT)合规性的方式。此头部指示浏览器仅接受记录在公共CT记录中的证书,防止证书欺骗。典型配置如下所示:

1
Expect-CT: max-age=86400, enforce, report-uri="https://example.com/report"

enforce指令阻止不合规的证书,而report-uri允许记录失败以供进一步分析。然而,行业最终远离了Expect-CT,Mozilla现在建议完全禁用它。现代浏览器现在依赖证书透明度的自动执行,而不需要专用的安全头部。

要点

虽然X-XSS-Protection、HPKP和Expect-CT曾被视为有价值的安全措施,但它们最终被证明无效或被更强大的替代方案(如CSP和证书透明度日志)取代。这些弃用突出了Web安全的持续发展,强调了保持更新现代安全最佳实践的重要性。

使用Invicti保持HTTP安全头部的最新状态

实施HTTP安全头部是加强Web应用程序安全性最简单但最有效的方法之一,通常需要对应用程序本身进行很少或没有更改。然而,跟上不断发展的安全最佳实践和浏览器支持变化可能具有挑战性——特别是在管理大量网站时。

为了帮助组织保持强大的安全态势,Invicti提供自动化漏洞扫描,包括对HTTP安全头部和其他错误配置的彻底检查。Invicti不仅检测安全头部的存在,还验证它们的正确实施,提供清晰的建议以确保您的Web应用程序完全免受新出现的威胁。通过集成Invicti的安全测试,企业可以轻松保持更新并维护强大的安全框架。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计