Joomla 4 新 HTTP 标头插件
继上个月关于安全、密码和 Joomla WebAuthn 插件的文章之后,这个月我们将探讨另一个与 J4 一起推出的 Joomla 安全功能。那就是 HTTP 标头插件,它现在已成为 Joomla 核心功能的一部分。
互联网不断发展,Joomla 也始终紧跟其后。这就是我选择它作为我的首选网页开发平台的原因。无论您的网站是一个小型家庭企业网站,还是一个销售额达数百万的全功能电子商务平台,Joomla 框架都有适合每个人的东西,并且始终在考虑实施新技术。其中一些甚至具有革命性。
在 Joomla 4 核心中引入 HTTP 标头插件是帮助保护您的网站免受攻击和恶意活动的一大步。
这个系统安全插件帮助网站所有者轻松配置 Joomla 熟悉的后端中的 HTTP 安全标头,而无需在 htaccess 文件或其他配置文件中翻找,或者更糟糕的是,您的网络托管 Cpanel。
看看在 Cpanel 中设置这个有多么复杂,[点击这里](https://support.cpanel.net/hc/en-us/articles/1500001533562-How-to-add-nosniif-CORS-HSTS-Clickjack-and-X-Xss-Protection-headers-on-a-per-domain-basis) 并告诉我您不会犯错!而且,这些都假设一旦框架安装在 Apache 中并创建了目录,您就知道如何添加您想要集成的 HTTP 标头。
您尝试了多少次实施 htaccess 命令,然后重新加载您的网站,却遇到了 http500 错误?
最大的问题在于,如果您没有将您的 HTTP 标头格式正确,您的网站就会出问题。
即便如此,对某个网站有效的东西可能对另一个网站不一定有效。一个很好的例子就是我的 htaccess 文件和我将浏览器设置为加载我的网站的 non www https 版本的方式。
##www 到 non www 和 http 到 https 混合
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin
这对于我之前的主机公司来说效果非常好。但是当我切换到不同的主机后,它就不再工作了。真是让人困惑!
我现在要使用以下htaccess代码来达到相同的效果
##www 到 non www 和 http 到 https 混合
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin
是不是很困惑?而且,如果你在格式上犯了一个错误,嘭!你的网站就坏了!至少在你修复代码之前是这样。
这就是为什么将事情保持简单,作为 Joomla 核心的一个部分,意味着更少的挫败感,更少的时间浪费在谷歌搜索你的错误上,你可以在椅子上坐着,欣赏你的新网站,并且有更多的时间庆祝。
所以,让我们来看看 HTTP头部 实际上是什么,你可以在哪里找到插件,以及你可以用它们做什么。不过,这里要提一下,这个Joomla功能是Joomla的高级功能,更适合数据敏感的网站,而不是你用心创建的关于你可爱小猫的新网站。然而,话虽如此,即使是简单的网站也应该尽可能安全,以防止在黑客攻击你的网站后执行恶意代码。
什么是HTTP头部?
HTTP头部不要与你的HTML文档的 <head> 部分混淆。它们是完全不同的。HTTP头部是您的网络服务器和浏览器之间的序言。一组指令告诉浏览器向访客显示什么,或者更重要的是,不显示什么。
你可以在浏览器中的开发者工具中看到HTTP头部以及它们如何与个别HTML对象相关。在Google Chrome中,打开开发者工具,然后网络标签。现在刷新网页,然后在左侧窗格中点击一个HTML项。它将在右侧窗格中显示该对象的HTTP头部。
在下面的图片中,你可以看到高亮显示的图片返回了一个200的HTTP状态,这意味着浏览器找到了它。还有一系列与该对象相关联的其他信息,例如文件大小和编辑日期。
如果你的某个HTML项未能显示,你可能在HTTP头部中找到关于原因的线索。在这个例子中,第二张图片未能显示,并且你可以从右侧窗格中显示的信息中看到没有HTTP头部信息。
除了这个神秘的提示
引用策略:'strict-origin-when-cross-origin'
'strict-origin-when-cross-origin' 简单来说就是,当一个HTML项(在这种情况下是图片)从一个不同的源(不是你的服务器)提供时,那么当时设置的HTTP头部策略必须遵循。在这个例子中,Joomla插件中设置的HTTP头部将拒绝所有不是来自这个网站或专门在Joomla HTTP头部插件中'包含'在HTTP头部参数设置中的不同网站的图片。
所以,当从HTML文档中调用图片时,浏览器会拒绝它,并且它不会被加载。
这与找不到并返回404未找到HTTP错误消息不同。在这种情况下,图片仍在托管它的服务器上寻找,但浏览器没有找到它。
好的。那么Joomla HTTP头部插件究竟做了什么?
除了告诉浏览器显示什么以及返回有关HTML文档的一般信息外,HTTP头部有助于减轻您可能在Joomla网站上遇到的攻击和安全漏洞。这就是Joomla HTTP头部插件发挥作用的地方。它通过根据Joomla HTTP头部插件中的设置明确显示HTML内容来实现这一点。
通过使用HTTP头部插件向你的Joomla网站添加基于HTTP的安全头部,你将为你的Joomla网站提供另一层安全。
这非常重要,因为默认情况下,一个HTML网页会向您的访客展示所有内容,不论好坏。除非网页的HTTP头信息明确指示不显示,否则都是如此。该插件通过允许您配置网站内容安全策略(Content-Security-Policy)中可用的高级安全选项来做到这一点。根据您的需求,该插件可以为每个网站配置不同的设置,因此它是在您对抗黑客时的真正灵活武器。
为什么我需要这个插件?
在理想的世界里,您可能不需要。然而,在我们所处的世界中,有太多不择手段的人试图寻找从无辜和轻信的人那里谋取利益的方法。在我们这里,我们把这些人称为黑客。黑客会不择手段地利用软件中的漏洞来获取经济利益,这通常会给网站所有者带来损害。
通过使用Joomla的HTTP头插件来控制向您的访客提供的内容,您可以减少黑客通过过时的漏洞插件向您的访客提供恶意网站内容的可能性。这有助于阻止您网站上恶意脚本的注入。
那么,让我们稍微考虑一下这个假设的情况。
您有一个漂亮的Joomla 3网站。它是在5年前制作的,看起来和功能仍然完美。所有的组件、插件和模块都保持最新。完美,对吧?
然而,并不完全是这样,因为当您5年前制作网站时,您安装了流行的Foo Bar插件,在您的首页上打印“FOO BAR”。一开始看起来很酷,但后来您改变了主意,并从首页文章中删除了插件{foo}FOO - BAR{/bar}的短代码。
但问题是:您并没有取消发布或卸载该插件本身,其使用已经从您的记忆中消失。 我相信我们都有这样的过失。
快进到今天,5年后,该插件仍然存在,在您的网站上已发布并处于活动状态,但已有5年未更新,因为您已经很久以前就忘记了该插件,或者作者停止了支持它。现在,某个恶意的家伙意识到这个插件存在一个可以被利用来对您的网站进行跨站脚本(XSS)攻击的安全漏洞,并使您的无辜访客成为受害者。
跨站脚本,也称为XSS,是您网站中的一个安全漏洞,它允许攻击者破坏您的用户与现在容易受到攻击的网站之间的交互。
攻击者/黑客使用XSS来利用您脆弱的网站向您的用户发送恶意脚本。因为脚本来自您的网站,用户的浏览器不知道或怀疑脚本不应该被信任,因此在网页加载和打开时执行脚本。
以这种方式运行的恶意脚本可能给您的用户带来许多问题,从窃取存储在cookies中的登录密码和用户名数据,到将您的用户发送到假冒的钓鱼网站。脚本甚至可以更改您网站所提供的网页的外观,并显示不同的广告。
使用 Joomla的HTTP头插件 有助于通过确保实际上只向您的访客提供您想要提供的服务器脚本和内容来阻止跨站脚本。其他一切都被阻止。
因此,在上面的例子中,您可以为HTTP头插件配置,只从指定的文件夹或可能是一个CDN(如果您使用的话)提供您的网站JavaScript(脚本)文件,以阻止攻击。
您还可以阻止网站运行HTML中嵌入的行内JavaScript。但请注意,根据您如何设计网站HTML,这可能会在以后造成问题。
这将有助于阻止恶意JavaScript代码在您的网站上执行。即使您的脆弱的Foo Bar插件是黑客最初能够向您的网站注入恶意代码的原因。
注意
容易受到XSS攻击的网站常见弱点是用户输入表单(用户登录页面、订阅通讯表单、联系我们表单等)没有验证和加密。
HTTP头插件在哪里?
您可以在Joomla的插件列表中找到HTTP头插件,以及其他所有Joomla插件,并且它访问的方式与您已经习惯的方式完全相同。
使用HTTP头插件
使用Joomla的HTTP插件相对简单,尽管在更改默认设置之前,了解一些与其使用相关的特殊术语可能是个好主意。尽管如此,其中一些您可能已经熟悉。
例如
当处理图像时,您会看到“img-src”这个术语,其中“img”指的是图像,“src”指的是图像的有效源。这些术语我们已经从基本的HTML中熟悉了。
在本文的末尾,有一个包含有助于您使用此Joomla插件的额外信息的网站列表。
HTTP头插件设置 - 选项卡1
当您打开插件时,第一个打开的选项卡是插件的基本设置。在这里,您可以调整X-Frame选项、引用策略、跨源打开策略,以及强制HTTP头。还有一些链接,可以提供更多信息,帮助您更详细地了解这些项的功能。
让我们逐一查看这些内容。
X-Frame选项
第一个设置是X-Frame选项,默认情况下是启用的。
此选项允许您决定您的网站内容是否可以在其他网站中使用、
启用后,会在您的网站头部添加一个‘x-frame-options: SAMEORIGIN’标签。此标签仍然允许您在自己的网站上使用、
X-Frame选项头部有助于保护您的网站和用户免受“点击劫持”攻击。这是一种攻击者在自己的网站上放置一个
这会让用户误以为他们点击的是透明上层按钮或链接,因为他们认为他们点击的是下面iframe中的链接。
因此,攻击者将本应针对原始框架页面的点击“劫持”到不同的网页上。
更严重的是,类似的技巧可以用来从电子邮件账户、社交媒体账户以及当然,您的银行账户中捕获密码和用户名登录详细信息。
大多数现代浏览器支持X-Frame选项,这很好。因此,我的建议是在HTTP头部插件中启用此设置,以帮助保护您的用户免受“点击劫持”的侵害。
大多数现代浏览器支持X-Frame选项。
设置为启用。这将全局限制在您的网站上对、
引用策略
在第一个标签页的列表中,下一项是 Referrer-Policy。如果启用,这允许您选择在点击网站上的链接或其他HTML对象时,多少潜在网站数据会被传输到另一个网站。
通常,我们会看到它被设置为一个HTML属性,如 <a> 标签,您可能将链接格式化为 <a href="https://someplace.com" rel="noreferrer">点击我</a>。Noreferrer 标签会隐藏发送网页的细节,不让接收网页得知。它是通过从网页的HTTP头部移除引用信息来实现的。
了解您的网站可能会“泄露”到链接网站的数据是保护您网站及其用户的重要部分。
尤其是如果您允许用户注册、包含敏感数据或您的网站处理货币交易时,这一点尤为重要。Joomla的HTTP头部插件帮助您在全球范围内控制这一点,而不是在单个链接级别上控制。
默认情况下,您的网站Referrer Policy设置为 ‘strict-origin-when-cross-origin’。这意味着除非是发送到较不安全的http页面,否则不会阻止来自原始网页的任何引用数据。但是,由于现在大多数网页都使用https,这已经成为一个比以前更大的问题。
当然,如果您的网站没有设置Referrer Policy,这些“泄露”的数据有无数无辜的用途。这包括收集链接网站用于分析、日志记录或优化缓存的资料。
不幸的是,并非每个被引用的网站都会将您的“泄露”数据用于如此无辜的操作。以下是一个例子。
大多数允许用户注册的网站将在登录/注册网页的登录表单旁边有一个重置密码链接。网页上也可能包含指向外部网站的其他链接、社交媒体链接,或者页脚中可能有“有用链接”。
这些都带您离开了安全环境。如果没有Referrer Policy,当从登录网页点击链接到那些外部网站时,发送出去的Referrer Header可能包含密码重置链接,以及其他您与外部网站共享的信息。
这可能会通过损害用户数据对用户构成安全风险。
由于这类数据敏感页面上存在潜在的安全风险,因此删除页面上的所有第三方内容也是一个好的做法。这包括所有链接和在 <iframes> 中提供的内容,如社交媒体小工具和YouTube视频。因为在此页面上输入的数据可能会通过Referrer Header发送到这些网站,如果您点击了突然弹出的可爱小猫视频。
Joomla的HTTP头部插件通过允许您从8个Referrer Policy中选择一个来为您的网站设置Referrer Policy,来解决这个问题。每个都有其自己的限制,关于何时以及共享多少数据。
让我们来看看这些。在 Mozilla头部页面上有它们的一个非常好的描述,它将它们描述为
no-referrer
将省略引用头部:发送的请求不包含任何引用信息。
no-referrer-when-downgrade
当协议安全级别保持相同或提高时(HTTP→HTTP,HTTP→HTTPS,HTTPS→HTTPS),在引用头部中发送原始、路径和查询字符串。对于请求到较不安全的目的地(HTTPS→HTTP,HTTPS→file)不发送引用头部。
origin
仅在引用者头中发送原始地址。例如,位于 https://example.com/page.html 的文档将发送引用者 https://example.com/。
origin-when-cross-origin
当执行相同源请求到相同协议级别(HTTP→HTTP,HTTPS→HTTPS)时,发送原始地址、路径和查询字符串。对于跨源请求和不安全的请求目的地(HTTPS→HTTP),只发送原始地址。
same-origin
对于相同源请求,发送原始地址、路径和查询字符串。对于跨源请求,不要发送引用者头。
strict-origin
当协议安全级别保持不变(HTTPS→HTTPS)时,只发送原始地址。不要向不安全的请求目的地(HTTPS→HTTP)发送引用者头。
strict-origin-when-cross-origin(默认)
当执行相同源请求时,发送原始地址、路径和查询字符串。对于跨源请求,当协议安全级别保持不变(HTTPS→HTTPS)时,只发送原始地址。不要向不安全的请求目的地(HTTPS→HTTP)发送引用者头。
注意:如果您没有指定策略,或提供的值无效,则这是默认策略。之前,默认设置为 no-referrer-when-downgrade。
unsafe-url
执行任何请求时(无论安全性如何),发送原始地址、路径和查询字符串。
警告:此策略会将潜在敏感信息从 HTTPS 资源 URL 泄露到不安全源。仔细考虑此设置的潜在影响。
作为良好开始,除非有理由不这样做,我建议将其设置为 ‘no-referrer’,从而为您的网站制定一个“共享无”策略。或者,'origin-when-cross-origin',这将允许您分析您网站内的 URL 流量(从而没有数据“泄露”),但只将您的域名作为引用域名发送到外部网站,因为 URL 中的“额外”数据不会附加到引用头中。
Cross-Origin-Opener-Policy
在第一个选项卡中设置的第三个选项是跨源打开者策略,这是一种基于浏览器的安全功能,允许您将不同的 ‘浏览器上下文组' 互相断开。
一个很好的例子是弹出窗口的使用。其中原始浏览器上下文组(所有文本、图像、链接等)与新创建的浏览器上下文组断开连接,然后在弹出窗口中显示。
虽然只有 3 个选项,但此 HTTP 头选项相当深入和复杂。因此,我鼓励您查看下面的链接,以更好地了解为什么应该在此网站上设置此选项。以及了解此选项激活时您可用的某些高级功能。
跨源打开者策略有助于关闭浏览器在不同上下文组之间共享数据时存在的漏洞,尤其是在网站上使用弹出窗口时。
设置您的 COOP 将帮助您减轻数据安全威胁,常见的一个被称为 ‘Spectre’。Spectre 使得加载到与您的代码相同浏览上下文组中的数据可能被黑客读取。Spectre 允许测量某些操作所需的时间。这允许黑客猜测 CPU 缓存中的内容。如果他们成功做到这一点,他们就会知道进程内存中的内容。然后他们可以访问您的数据。这可能很敏感。
COOP 通过隔离您的原始 HTML 文档数据与原始文档中将要显示的 HTML 数据来工作。这有助于防止所谓的 跨源攻击,或 XS-Leaks。
这个过程类似于我们在常规链接中使用的熟悉的 rel="noopener" 。但是,与仅在出站链接上激活的 rel="noopener" 不同,由 Joomla 插件在 HTTP 头部设置的 cross-origin-opener-policy 的文档,会限制双向数据。因此,具有活跃 COOP 政策的 HTML 文档在 HTTP 头部中不会有引用,并且新窗口的 window.opener HTTP 头部属性将被设置为 null。
在 Joomla HTTP 头部插件中设置此选项时,您有 3 个选项可供选择。
unsafe-none
这是默认值。它允许您的文档添加到其打开者的浏览上下文组中,除非打开者本身具有 cross-origin-opener-policy 为 same-origin 或 same-origin-allow-pop-ups。
same-origin-allow-popups
此选项保持对新打开的窗口或标签的引用,这些窗口或标签要么没有设置 cross-origin-opener-policy,要么通过将 cross-origin-opener-policy 设置为 unsafe-none 来选择退出隔离。
same-origin
仅将浏览上下文组隔离为同源文档。跨源文档不会在同一浏览上下文组中加载。
对于您的网站来说,一个好的起点是将此选项保留在插件中的 same-origin 上,这是默认设置。这将允许您的网站/域中的内容在弹出窗口中成功加载,但限制来自外部来源的弹出窗口中加载项的访问。
如本节开头所述,某些高级功能取决于 跨源隔离。例如,SharedArrayBuffer 对象 或 Performance.now() 方法,这些是某些服务工作者为无节流计时器所需的功能,仅在您的文档具有 cross-origin-opener-policy HTTP 头部并将值设置为 ‘same-origin’ 时才可用。
强制 HTTP 头部
第一个选项卡中要关注的最后一个选项是“强制 HTTP 头部”,这不要与 Joomla 通用设置中的“强制 HTTPS”混淆。
此节中的 Joomla HTTP 头部插件允许您添加(如果需要),一些在插件标签中未详细说明的“其他”头部,以及强制包含一些包含的头部。
从下拉列表中,您目前有 10 个选项。但值得注意的是,其中一些 可能会随着时间的推移而被删除,因为它们所引用的头部策略将发生变化或被重新构想。
您可以直接在此处设置的当前 HTTP 头部是针对以下内容的头部
您可以通过点击每个标题在 Mozilla 开发者网站上了解有关每个功能的更多信息。
Content-Security-Policy
Content-Security-Policy 响应头部允许网站控制用户可能为每个网页加载的资源。策略主要指定服务器原点和服务脚本端点。这有助于防范 跨站脚本攻击。
Content-Security-Policy-Report-Only
HTTP Content-Security-Policy-Report-Only 响应头部允许网络开发者通过监控(但不强制执行)其影响来尝试策略。
Cross-Origin-Opener-Policy
HTTP Cross-Origin-Opener-Policy (COOP) 响应头部允许您确保顶级文档不会与 跨源 文档共享浏览上下文组。
COOP 将 进程隔离 您的文档,潜在的攻击者如果要在弹出窗口中打开它,将无法访问您的全局对象,从而阻止一系列被称为 XS-Leaks 的跨源攻击。
Expect-CT (即将弃用)
Expect-CT 标头允许网站选择启用或强制执行证书透明度要求,以防止该网站被误发行的证书未被察觉。
特性策略(现已弃用)
HTTP 特性策略标头提供了一种机制,允许和拒绝在其自己的框架中以及在文档中任何 <iframe> 元素内的内容中使用浏览器功能。
权限策略(取代上述特性策略)
这是上述特性策略的替代方案。
引用策略
Referrer-Policy HTTP 标头控制应包含多少 referrer 信息(与 Referrer 标头一起发送)与请求一起。
Report-To
是 Content-Security-Policy 的一部分。Content-Security-Policy Report-To HTTP 响应标头字段指示用户代理存储原点的报告端点。
report-to 指令旨在取代已弃用的 report-uri 指令,目前大多数浏览器尚不支持 report-to。
Strict-Transport-Security
HTTP Strict-Transport-Security 响应标头(通常简称为 HSTS)通知浏览器,网站应仅通过 HTTPS 访问,并且任何未来尝试使用 HTTP 访问它都应自动转换为 HTTPS。
这比仅在服务器上配置 HTTP 到 HTTPS(301)重定向更安全,在后者中,最初的 HTTP 连接仍然容易受到 中间人攻击 的威胁。
X-Frame-Options
X-Frame-Options HTTP 响应标头指示浏览器是否允许在 <frame>、<iframe>、<embed> 或 <object> 中渲染页面,或不允许。网站可以使用此功能通过确保其内容未嵌入到其他网站中来 避免点击劫持攻击。
只有在访问文档的用户使用支持 X-Frame-Options 的浏览器时,才提供额外的安全性。
X-Frame-Options 标头有子项 frame-ancestors,它取代了 Frame-Options 标头。如果一个资源有两个策略,frame-ancestors 策略将被强制执行,而 X-Frame-Options 策略将被忽略。
使用 HTTP 标头值字段,您可以设置要遵循的值,并将它们分配给您的网站、管理网站或两者。
值得提到的是,浏览器对 HTTP 标头的支持情况各不相同,因此在使用您选择的 HTTP 标头之前检查其潜在受众的浏览器支持是一个好主意。
如果您为您的网站设置了一系列 HTTP 标头,而用户的浏览器不支持该标头选项,则浏览器将忽略它。
HTTP 标头插件设置 - 选项卡 2
Strict-Transport-Security (HSTS)
默认情况下禁用 Strict Transport Security 策略选项卡。
我喜欢研究。因为有时你会遇到真正的 OMG!时刻。这就是那种时刻。
Netscape Communications 在 1994 年为它的 Netscape Navigator 网络浏览器创建了 HTTPS。最初,HTTPS 与 SSL 协议一起使用。随着 SSL 发展到传输层安全性 (TLS),HTTPS 在 2000 年 5 月由 RFC 2818 正式指定。Google 于 2018 年 2 月宣布,从 2018 年 7 月开始,其 Chrome 浏览器将标记 HTTP 网站为“不安全”,这是为了鼓励网站所有者实施 HTTPS,作为使万维网更安全的努力。”……
谁能想到网景公司早在很久以前就发明了HTTPS协议呢?更令人惊讶的是,它花了这么长时间才被应用到我们今天所熟悉和喜爱的互联网上。
多年来,他们一直试图说服我们、威胁我们,在所有网站上实施HTTPS。我们中的大多数人屈服了,全球网络终于变得安全。但这真的是这样吗?
然而,还有一些坚持己见的人、顽固分子或被遗忘的网站仍在仅使用http来传输内容,尽管谷歌/火狐等浏览器会发出“此网站不安全”的警告。
一次快速的谷歌搜索出现了几个那些“仅http有罪”网站的过时列表。尽管自那时起,许多网站已更新为HTTPS。然而,一些显然被排除在外的组织,你可能会认为他们应该知道得更好。
例如
NGINX
GNU
华盛顿大学(http://www.washington.edu/)
据 w3techs.com 报道,大约20%的所有网站仍在仅运行HTTP。
那么,这究竟是个什么问题呢?
这是一个问题,因为用户浏览器发送和接收的任何数据都存在被拦截的风险。我们把这称为 中间人攻击。现在,如果你的网站只是关于可爱小猫的图片,这可能不是一个重要的考虑因素。
但即使是简单的网站也可能成为黑客和攻击者的受害者,他们会实施 点击劫持 和其他 跨源攻击,这会损害你的用户。
即使网站不交换用户数据或登录信息,也应使用HTTPS。
好的,让我们回到主题。
正如你所知,HTTPS的全部意义在于在用户的浏览器和你的服务器之间建立安全的连接。这种连接下,任何数据交换都在一个安全的环境中发生,不会被第三方拦截和复制,即中间人。
但是,你知道除非你的 HTTPS SSL证书 使用 TLS,你的“安全”连接并不像你想象的那样安全吗?非TLS HTTPS连接仍然 容易受到中间人攻击。
虽然是一篇旧博客文章,但 这篇文章 很好地解释了中间人攻击是如何工作的。
现在,浏览器广泛采用了TLS,但最新版本(1.3)并不像其前身(1.2)那样被广泛支持。
并且,TLS 1.3如果不处于 兼容模式 下,则不能直接与旧版本兼容。这可能会给一些人带来问题。
使用Joomla的HTTP头部插件处理Strict-Transport-Security(HSTS)有助于通过强制在访问者的Web浏览器中使用TLS来减轻中间人攻击。TLS确保所有Web通信都在客户端使用安全的传输层进行。
你是在使用301重定向将你的非安全HTTP版本网站转换为安全HTTPS版本吗?
大多数人都是。301重定向是大多数网站所有者在他们的htaccess文件中设置的指令。它们让谷歌知道应该使用的是HTTPS(安全)版本的网站。但问题在于,301只是一个URL重定向,所以你的网站仍然会通过HTTP进行一些初始连接。
与使用HSTS的用户和网站服务器之间的连接不同,服务器会自动仅使用HTTPS与之交互。
尽管如此,HSTS存在一个弱点,那就是用户浏览器和网站服务器之间的第一次初始连接仍然是通过HTTP进行的。但是,所有随后的连接都会自动通过HTTPS进行,直到HTTP头部的过期日期到达并重置该头部。
这与标准的301重定向不同,在标准301重定向中,每次页面加载都会包括一个初始的HTTP请求来启动HTTPS连接。
在HTTP头部HSTS设置中,有一个解决方案来解决这个问题,激活“预加载”。
这将向响应头添加“预加载”标签。
在设置中,还有一个链接,用于将您的网站域名添加到Chrome的HTTP严格传输安全(HSTS)预加载列表中。这是一个硬编码到许多现代浏览器中的列表。该列表会告知浏览器,与example.com的连接只能通过HTTPS进行。从而消除了甚至通过HTTP进行初始连接的需求。
一旦在Joomla HTTP头部插件中设置了HSTS,就会添加所有必要的标签到HTTP响应头部。这允许任何尝试连接到您的服务器的用户浏览器知道所有连接都必须通过HTTPS进行,无论是否在您的HTML中指定。
总的来说,使用Joomla的HTTP头部插件集成HSTS而不是依赖301重定向来通过HTTPS提供内容是一项重要的安全改进。这项改进有助于阻止中间人攻击,并为您的用户提供一个安全的环境。
HSTS覆盖整个域名,而301重定向只覆盖特定的URI路径。
HSTS使用一个独立的浏览器缓存,通常是被隔离的,因此它不能轻易或意外地被清除。
HSTS可以被预加载到浏览器中。这确保了用户无论是否以前访问过该网站,都只能通过HTTPS连接到您的服务器。
启用:HSTS
设置max-age:默认值为1年(31536000)秒,但有些人建议将其设置为2年(63072000)秒。
启用:子域名 - 如果您有子域名,请确保您有有效的SSL证书来覆盖它们,无论是单独的还是从主域名中作为通配符。
启用:预加载
最后,将您的域名提交到HSTS预加载列表。
HTTP头部插件设置 - 标签3
内容安全策略
内容安全策略标签默认是禁用的。
当您通过HTTP头部插件启用Joomla的内容安全策略时,您正在告诉您的访客浏览器从您的网站服务器加载了哪些资产。这是一种确保您只提供您实际想要提供的内容的好方法。
建立有效的内容安全策略是一种有效的阻止从您的网站发起的跨站脚本(XSS)和点击劫持攻击的方法。
跨站脚本,也称为XSS攻击,是一种恶意脚本被“注入”到不受怀疑且通常可信的网站中的攻击。攻击者找到一个可以利用的弱点,这通常是在用户可以输入数据的地方。
允许用户输入的过时组件,例如未经验证的评论表单,可能存在可以被跨站脚本攻击利用的漏洞。这就是为什么始终更新您的Joomla组件并尽量减少这些机会是一个好主意。
所以,以受感染的评论表单为例
您的网站在文章末尾使用评论表单来收集用户讨论,就像许多网站一样。这很好。
您从dodgy-joomla-extensions.com购买的评论扩展程序运行得很好,您的用户都喜欢它。但您已经5年没有更新它了,并且开发人员已经放弃了它。
5年后,黑客先生意识到,由于评论组件代码中的漏洞,他可以在看起来无辜的评论中隐藏一段恶意的代码。
这段代码最终会做什么因情况而异,但您可以确信的是,每次您的无辜文章页面加载并带有评论时,那段糟糕的代码也会被加载并执行。毕竟,它是HTML的一部分,浏览器并不知道它不应该在那里,或者是不受信任的。
因此,那段糟糕的代码会运行。它可能会检查您的cookie数据。它可能会窃取浏览器保存的敏感数据。或者,它可能会加载来自在线赌场或成人网站的广告。或者,它可能会从外部JavaScript文件完全重新加载您关于那些可爱小猫的无辜网页的HTML,以窃取您的用户的信用卡详情。
事实上,此时脚本可以执行几乎任何事情。
一个好的内容安全策略有助于阻止这类攻击,即使您的被破坏的评论扩展成为了黑客的目标。
它之所以能这样做,是因为Joomla HTTP头插件将CSP作为HTTP响应头提供,明确告诉浏览器应该加载什么。在HTTP头插件的CSP标签的设置中,您可以直接针对28个策略指令。这些指令通过只使用经过批准的文件和内容来源来帮助确保您的网站安全。
上面的攻击示例最终加载了来自不同来源的JavaScript文件,以改变屏幕上渲染的HTML输出。这可以通过在插件的Joomla CSP中添加指令 script-src 'self' 来预防。
在这个例子中,浏览器只有在JavaScript文件来自您的域名时才会加载HTML文档中的JavaScript文件。所有其他JavaScript文件都将被拒绝,包括黑客的。
虽然这有助于保护您的网站,但它也可能阻止您在网页渲染时想要加载的其他合法JavaScript文件。这些外部文件可以作为同一指令中的白名单来源添加。例如,如果您从CDN使用bootstrap,您会添加
script-src 'self' https://cdn.jsdelivr.net.cn
在这个例子中,如果您在CDN https://cdn.jsdelivr.net.cn上加载bootstrap有困难,您可以尝试添加所需的bootstrap文件的完整URL。所以,您会这样格式化您的指令:script-src 'self' https://cdn.jsdelivr.net.cn/npm/[email protected]/dist/js/bootstrap.min.js。
在构建新网站时添加这些外部来源会更容易实现。但如果你使用开发工具遍历您的渲染HTML,你应该能够找到您现有网站上已经使用的所有外部文件,并将它们包含在您的CSP中。
当在HTTP头插件中添加内容安全策略的指令时,您可以使用一系列核心值来定义浏览器应明确加载的内容。这些是设置第一个内容安全策略的基本值。
某些更高级指令还有其他选项,更完整的列表和用法示例可以在这里找到。
'none'阻止此类资源的使用。
'self'匹配当前源(但不包括子域)。
'unsafe-inline'允许使用内联JS和CSS。
'unsafe-eval'允许使用如eval()之类的机制。
让我们看看这些指令中的一些。以下是一些在Joomla HTTP头插件中可用的指令列表,以及简要说明,感谢内容安全策略提供。我建议您访问此网站以获取更多信息和分析。
default-src
默认-src指令定义了获取资源(如JavaScript、图像、CSS、字体、AJAX请求、框架、HTML5媒体)的默认策略。
EXAMPLE DEFAULT-SRC POLICY
default-src 'self' https://cdn.example.com
script-src
定义JavaScript的有效源。
EXAMPLE SCRIPT-SRC POLICY
script-src 'self' https://js.example.com
style-src
定义样式表或CSS的有效源。
EXAMPLE STYLE-SRC POLICY
style-src 'self' css.example.com
img-src
定义图像的有效源。
EXAMPLE IMG-SRC POLICY
img-src 'self' https://img.example.com https://example.com
connect-src
应用于XMLHttpRequest (AJAX)、WebSocket、fetch()、<a ping>或EventSource。如果不允许,浏览器将模拟400 HTTP状态码。
EXAMPLE CONNECT-SRC POLICY
connect-src 'self'
font-src
定义字体资源的有效源(通过@font-face加载)。
EXAMPLE FONT-SRC POLICY
font-src https://font.example.com https://example.com
object-src
定义插件的有效源,例如 <object>、<embed> 或 <applet>。
EXAMPLE OBJECT-SRC POLICY
object-src 'self'
media-src
定义音频和视频的有效源,例如HTML5 <audio>、<video>元素。
EXAMPLE MEDIA-SRC POLICY
media-src https://media.example.com
frame-src
定义加载框架的有效源。在CSP Level 2中,frame-src已被弃用,转而使用child-src指令。CSP Level 3已经重新启用frame-src,如果不存在,它将继续依赖于child-src。
EXAMPLE FRAME-SRC POLICY
frame-src 'self'
sandbox
为请求的资源启用一个沙盒,类似于iframe的sandbox属性。沙盒应用同源策略,阻止弹出窗口、插件和脚本执行。您可以保持sandbox值空白以保留所有限制,或者添加以下值:allow-forms allow-same-origin allow-scripts allow-pop-ups,allow-modals,allow-orientation-lock,allow-pointer-lock,allow-presentation,allow-popups-to-escape-sandbox,and allow-top-navigation。
EXAMPLE SANDBOX POLICY
sandbox allow-forms allow-scripts
report-uri
指示浏览器将策略失败的报告POST到这个URI。您还可以使用Content-Security-Policy-Report-Only作为HTTP头名称来指示浏览器仅发送报告(不会阻止任何内容)。此指令在CSP Level 3中被弃用,转而使用report-to指令。
EXAMPLE REPORT-URI
report-uri /some-report-uri
child-src
定义web workers和嵌套的浏览上下文(使用如 <frame> 和 <iframe> 等元素加载)的有效源。
EXAMPLE CHILD-SRC POLICY
child-src 'self'
form-action
定义可以作为HTML <form> action使用的有效源。
EXAMPLE FORM-ACTION POLICY
form-action 'self'
frame-ancestors
定义使用 <frame> <iframe> <object> <embed> <applet> 嵌入资源的有效源。将此指令设置为 'none' 大约相当于 X-Frame-Options: DENY。当此指令生效时,如果浏览器支持它,它将覆盖 X-frame-options 中的设置。
EXAMPLE FRAME-ANCESTORS POLICY
frame-ancestors 'none'
plugin-types
定义通过 <object> 和 <embed> 调用的插件的有效MIME类型。要加载 <applet>,您必须指定 application/x-java-applet。
EXAMPLE PLUGIN-TYPES POLICY
plugin-types application/pdf
base-uri
定义一组允许的URL,这些URL可以用作HTML base标签的src属性。
EXAMPLE BASE-URI POLICY
base-uri 'self'
report-to
定义由Report-To HTTP响应头定义的报表组名称。有关更多信息,请参阅Reporting API。
EXAMPLE REPORT-TO DIRECTIVE
report-to groupName
worker-src
限制可以加载为Worker、Shared Worker或Service Worker的URL。
EXAMPLE WORKER-SRC POLICY
worker-src 'none'
manifest-src
限制应用程序清单可以加载的URL。
EXAMPLE MANIFEST-SRC POLICY
manifest-src 'none'
prefetch-src
定义请求预取和预渲染的有效来源,例如通过带有rel="prefetch"或rel="prerender"的链接标签
示例:PREFETCH-SRC策略
prefetch-src 'none'
navigate-to
限制文档可能通过任何方式导航到的URL。例如,当点击链接、提交表单或调用window.location时。如果存在form-action,则此指令在表单提交时被忽略。实现状态
示例:NAVIGATE-TO策略
navigate-to https://example.com
Joomla的HTTP头插件还提供了在内容安全策略选项卡中设置一些全局参数的机会。
您可以选择通过客户端设置将CSP应用于您的网站、管理站点或两者。
“仅报告”选项让您可以在上线前使用Dev Tools测试您的指令并检查错误。在谷歌控制台中追踪CSP错误的根本原因总是很有趣!
接下来是“一次性数”(Nonce)设置。一次性数指的是“仅使用一次的数字”,是一种将随机生成的字符串应用于通过Joomla API添加到您的HTML中的内联<script>或<style>标签的系统。这些实例通常由第三方Joomla组件/模块/插件开发者在您安装额外功能到您的网站时实现。
在下面的图片中,您可以看到添加到由Akeeba Backup组件添加到我的HTML文档中的CSS<styles>中的带有nonce rel属性的<style>标签。
有趣的是,添加到HTML文档中的核心Joomla JavaScript和CSS代码当前不包含“nonce”标签。这是因为它们是“核心”的一部分,而不是通过Joomla API添加的。
如果您在CSP设置中启用“一次性数”切换,则允许浏览器将内联脚本和样式渲染为“安全”。您还必须在您的script-src策略指令中将Joomla {nonce}标签设置为script-src 'self' {nonce}。作为不支持'nonces'的旧浏览器的后备,您还可以在{nonce}占位符之后添加{script-hashes},如下所示 script-src 'self' {nonce} {script-hashes}(注意间距)。但不要忘记首先启用脚本散列。
Joomla随机生成“一次性数”文本字符串并将其添加到<style>和<script>标签。当您在插件设置中启用“一次性数”选项时,文本字符串会被传递到HTTP头。然后浏览器解析HTTP头并处理匹配的<script>或<style>。同时,浏览器从渲染的HTML中删除一次性数文本字符串。
这反过来阻止了黑客获取一次性数文本字符串并将其添加到自己的注入代码中。即使黑客成功地将恶意JavaScript注入到您的HTML中,浏览器也会将其阻止。
脚本散列
我们都知道我们不应该在HTML中包含内联JavaScript,你应该将它写入一个my-javascript.js文件,并添加到<head>或放置在</body>标签之前。但我们都有时这样做。
问题在于,如果你这样做,然后添加CSP指令‘script-src 'self'’,所有内联JavaScript将默认被阻止。它是这样设计的,以防止黑客注入的JavaScript在您的网站上运行。
可以通过指令script-src 'unsafe-inline'来覆盖这个问题,这将允许黑客的内联JavaScript运行,以及您的可信代码。这显然不是最佳选择。
脚本哈希拯救了!
Joomla的HTTP头插件自动收集所有通过Joomla API传递到网站的<styles>和<scripts>。然后它生成相应的哈希值并通过HTTP头传递它们。浏览器然后在网站本身上生成哈希值并确认哈希值是否匹配。如果匹配,则执行脚本,否则阻止。
要启用此插件功能,请将开关切换到'启用'。然后,在您的script-src策略指令中添加值'self' {script-hashes}。如果您正在使用'nonce'功能,以及'script hashes',请将指令值设置为与上面的nonce示例一样。
这真聪明。
但更好的是,我们可以用同样的想法手动处理脚本哈希,并将它们添加到我们的指令script-src 'self'中。这需要一点设置和维护工作,但如果您在文章或自定义模块中添加了一些JavaScript,它可能会救您的命。
使用sha256、sha384或sha512哈希生成器有更详细的方法来做这件事。但鉴于大多数人只会将少量JavaScript添加到文章或自定义模块中,我们将让谷歌的开发工具为我们做这项工作。
过程很简单。唯一的区别是我们如何生成哈希值。
假设您已启用Joomla HTTP头插件,CSP已激活,并且您已设置并保存了指令script-src 'self'。
步骤1 - 将您的内联JavaScript添加到文章或自定义模块中,并保存它。别忘了调整您的编辑器设置,以防止编辑器在保存时删除您的代码。
步骤2 - 导航到包含脚本的网页。打开开发者工具,在控制台标签中,您会看到一个类似以下错误的错误
拒绝执行内联脚本,因为它违反了以下内容安全策略指令:“script-src 'self'”。需要'unsafe-inline'关键字、哈希('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0=')或nonce('nonce-...')以启用内联执行。
步骤3 - 现在,您只需将错误消息中的哈希值复制/粘贴到插件中的JavaScript指令中并再次保存
script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='
接下来,重新加载您的网页,并在谷歌的开发者工具中再次检查。现在错误将消失,浏览器将在网页上加载您的脚本。
注意:我的示例中仍然显示错误,因为添加到我的文章中的JavaScript不完整。但它表明内联代码至少正在尝试工作。
将哈希值添加到您的内联代码中是将其在HTTP头中白名单化的好方法,这样它们仍然会被执行,而任何未明确哈希并添加到您的CSP中的内联代码仍然会被阻止。从而挫败黑客试图破坏您的网站的努力。
注意
如果您更改JavaScript,您需要重新计算哈希值并更改CSP指令中的值。
如果您在使哈希值工作方面遇到问题,有3个常见问题,您可以在这里找到解决方案。
严格动态
如果您在CSP中启用“严格动态”选项,这将将您通过哈希或nonce明确授予脚本的权限应用到任何直接链接到它或从它调用的其他脚本。此操作还将覆盖应用于这些子脚本的默认指令,如'self'或'unsafe-inline',这些指令在您的通用CSP指令中应用。它们将被忽略。
样式哈希
CSP的样式哈希与上面的JavaScript哈希工作方式完全相同,但请使用此功能如果您将CSS <style>块添加到您的HTML主体中。就像使用'脚本哈希' 启用插件功能和设置一个style-src策略指令来引用它,值为'self' {style-hashes}。
注意
如果您更改了内联CSS(而不是由Joomla API创建的CSS),您需要重新计算哈希并更改CSP指令中的值。
框架祖先 'self'
此插件中的选项允许页面被框架,例如,在一个iframe中,但仅限于同一站点。
如果您想明确允许不同的网站框架您的内容,您可以设置一个特定的指令‘frame-src’。
有时,在构建新网站时构建外部资源所需的内容时,构建一个良好的CSP更容易。
在CSP指令中,使用允许域的完整、正确的基URL非常重要。例如:https://www.mywebsite.co.uk,或https://www.anotherwebsite.com
您还可以使用通配符通过相同的CSP针对子域。例如:https://*.example.org。
并非所有浏览器都支持所有指令。
CSP支持sha256、sha384和sha512哈希。
最后备注/结论
在撰写本文时,我意识到我只触及了这一巨大话题的表面。
我喜欢发现我以前忽略或不知道的话题。你呢?
在研究HTTP头主题,特别是使用Joomla的新J4插件设置这些头时,我得出的结论是我们所有人都需要掌握这一主题。有太多的人(黑客)正在等待机会利用安全薄弱的网站。所以,不要帮助你的用户成为受害者。
享受调查Joomla HTTP头插件,了解它是如何帮助保护您的网站的。
然而,我建议你在开始之前对此有趣的主题进行一些研究。下面有一些链接可以帮助你开始自己的研究。这将使你对互联网是如何工作的以及你的网站是如何与之交互的有一个更好的理解。
参考
如果您需要重置与HTTP头插件一起安装的插件,可以使用以下选项设置
插件默认启用。
- HSTS和CSP选项卡默认禁用。
- X-Frame-Options默认启用。
- Referrer-Policy最初设置为:strict-origin-when-cross-origin。
- Cross-Origin-Opener-Policy最初设置为same-origin。
如果您已经读到这里,并想“这不公平,J3怎么办?”,“我们为什么不能在Joomla 3中拥有相同的功能?”。好消息是,你可以。虽然你将不得不从JED下载插件并安装它。J3插件具有与J4版本相同的大多数功能,而且是由编写J4版本的同一团队编写的,现在它已包含在核心中 :)。
当您使用Joomla 4插件设置好HTTP头后,您可以在这里测试您的HTTP头。
https://securityheaders.com/
您得分如何?
请注意,激活HTTP头插件可能在前端产生意外的操作。
最后,我要感谢Tobias Zulauf和Ced Keiflin,他们的贡献使得这篇文章能够按时完成!
更多阅读
以下是我用来研究这篇文章的一些网页,它们充满了关于这个主题的有用信息。
- https://docs.joomla.org/J4.x:Http_Header_Management
- https://csp.withgoogle.com/docs/index.html
- https://content-security-policy.com/
- https://scotthelme.co.uk/content-security-policy-an-introduction/
- https://scotthelme.co.uk/csp-cheat-sheet/
- https://support.cpanel.net/hc/en-us/articles/1500001533562-How-to-add-nosniif-CORS-HSTS-Clickjack-and-X-Xss-Protection-headers-on-a-per-domain-basis
- https://mdn.org.cn/en-US/docs/Web/HTTP/Headers/Referrer-Policy
- https://mdn.org.cn/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns
- https://mdn.org.cn/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
- https://web.dev/why-coop-coep/
- https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
- https://mdn.org.cn/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
- https://mdn.org.cn/en-US/docs/Web/API/Performance/now
- https://www.troyhunt.com/clickjack-attack-hidden-threat-right-in/
- https://scotthelme.co.uk/hsts-the-missing-link-in-tls/
- https://scotthelme.co.uk/wifi-pineapple-karma-sslstrip/
- https://help.upguard.com/en/articles/4581202-what-s-the-difference-between-using-hsts-and-doing-a-301-redirect
- https://content-security-policy.com/hash/
- https://content-security-policy.com/frame-ancestors/
- https://content-security-policy.com/nonce/
本文的德语翻译:https://www.jug-zueri.ch/artikel/das-http-headers-plugin-in-joomla-4
本文的俄语翻译(第一部分):https://habr.com/ru/articles/697214/
本文的俄语翻译(第二部分):https://habr.com/ru/articles/704778/
Joomla社区杂志上发布的一些文章代表了作者对特定主题的个人观点或经验,可能并不与Joomla项目的官方立场一致。
通过接受,您将访问由 https://magazine.joomla.net.cn/ 外部的第三方提供的服务
评论