Эта статья - дополненный перевод статьи Joomla’s New HTTP Headers Plugin For J4 из майского номера (2022) Joomla Community Magazine. Статья рассчитана на широкий круг читателей с разными уровнями компетенций, поэтому опытным вебмастерам и разработчикам имеет смысл пропустить часть текста вводного характера и сразу перейти к описанию плагина. 2-я часть перевода находится в этой статье. Далее текст автора.
В продолжение статьи о безопасности, паролях и плагине WebAuthn в Joomla [JCM, 04/2022, текст на английском - Т.С.], мы рассмотрим еще одну функцию безопасности Joomla, добавленную в Joomla 4. Это плагин HTTP Headers, который теперь включен в ядро.
Интернет постоянно развивается, и Joomla шагает в ногу со временем. Именно поэтому я выбираю его в качестве своей платформы веб-разработки. Независимо от того, является ли ваш сайт небольшим сайтом для мамочек и папочек или полноценной платформой электронной коммерции с миллионными продажами, в Joomla Framework найдется что-то для каждого, и мы всегда стремимся внедрять новые технологии. Некоторые из них даже новаторские.
Внедрение плагина HTTP Headers в ядро Joomla 4 - это огромный шаг вперед, помогающий защитить ваш веб-сайт от атак и вредоносной активности.
Этот плагин безопасности системы помогает владельцам сайтов легко настраивать заголовки безопасности HTTP из знакомого бэкэнда Joomla, вместо того, чтобы рыться в файле htaccess или других файлах конфигурации. Или, что еще хуже, Cpanel вашего веб-хостинга.
Проблема
Посмотрите, как сложно это настроить в Cpanel, и скажите мне, что вы ни разу не допустите ошибки! И все это при условии, что после установки фреймворка в Apache и создания каталогов Вы знаете правильный формат для добавления нужных HTTP-заголовков.
Сколько раз Вы писали директивы htaccess, а затем, обновив страницу, сталкивались с 500-й ошибкой?
Самая большая проблема заключается в том, что если вы не получите идеальный формат синтаксиса для Вашего HTTP-заголовка, вы сломаете свой сайт.
И даже в этом случае то, что работает для одного сайта, может не сработать для другого. Ярким примером этого является мой файл htaccess и то, как я настраиваю перенаправление с www + http на https
##www to non www and http to https mixin
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 to non www and http to https mixin
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-заголовки сайта
как Вы можете найти плагин HTTP Headers в Joomla 4
что Вы можете с ними сделать.
Однако, здесь стоит упомянуть, что эту функцию Joomla 4 можно отнести к продвинутому функционалу, который больше подходит для сложных сайтов, а не сайтов о котятах. Тем не менее даже простые сайты должны быть максимально безопасными, чтобы остановить потенциальное выполнение вредоносного кода после того, как они взломали ваш веб-сайт.
Что такое HTTP-заголовки сайта?
Заголовки HTTP не следует путать с разделом <head> HTML-страницы сайта. Это совершенно разные вещи. HTTP-заголовки - это преамбула между вашим веб-сервером и браузером. Набор инструкций, которые сообщают браузеру, что или, что наиболее важно, а чего не следует показывать посетителю.
Вы можете увидеть HTTP-заголовки для всех загружаемых ресурсов страницы в инструментах разработчика.
На скриншоте ниже видно, что выделенное изображение возвращает HTTP-статус 200, поэтому браузер нашел его. С этим элементом также связан ряд другой информации, такой как размер файла и даты редактирования.
Если один из ваших HTML-элементов не удалось отобразить, вы также можете получить информацию о причине в HTTP-заголовках. В этом примере не удалось отобразить второе изображение, и вы можете видеть из информации, отображаемой на правой панели, что информация о заголовке HTTP отсутствует, кроме загадочного послания:
Referrer Policy: 'strict-origin-when-cross-origin' [документация W3C, документация Mozilla - Т.С.]
Strict-origin-when-cross-origin означает, что когда HTML-элемент (в данном случае изображение) загружается из другого источника (не с Вашего сервера), необходимо соблюдать политику безопасности, установленную HTTP-заголовком. В этом примере заголовки HTTP, установленные в плагине Joomla, будут отклонять все изображения, которые не исходят ни с этого веб-сайта, ни с другого веб-сайта, который специально "включен" в параметры заголовка HTTP, установленные в плагине заголовка HTTP Joomla.
Итак, когда изображение вызывается из HTML-документа [с другого сайта - Т.С.], браузер отклоняет его, и оно не загружается.
Это отличается от ситуации, когда изображение не найдено на том же сервере, что и сам сайт, и сервер возвращает ошибку 404 для данного файла.
С этим всё понятно. Что же делает плагин HTTP Headers Plugin в Joomla 4?
Помимо указания браузеру, что отображать, и возврата общей информации об HTML-документе, HTTP-заголовки помогают смягчить атаки и уязвимости в безопасности, которые могут возникнуть на вашем Joomla-сайте. Это достигается за счет отображения HTML-контента на основе Ваших настроек в плагине Joomla HTTP Headers. Добавив необходимые HTTP-заголовки на свой Joomla -сайт с помощью плагина HTTP Header, вы обеспечите еще один уровень безопасности для своего веб-сайта Joomla.
Это важно, потому что по умолчанию HTML-страница будет отображать все свое содержимое вашему посетителю, и хорошее и плохое. Разве что в HTTP-заголовках веб-страницы явно не указано, что этого делать не следует. Плагин позволяет Вам настраивать расширенные параметры безопасности, доступные вам в Content-Security-Policy [Документация Mozilla, статья на Хабре, документация W3C - Т.С.] для вашего веб-сайта. Плагин может быть настроен по-разному для каждого веб-сайта в зависимости от Ваших требований, так что это действительно гибкое оружие в Вашем арсенале против хакеров.
Зачем Вам нужен этот плагин?
В идеальном мире Вы бы этим не занимались. Однако в реальном мире слишком много недобросовестных людей, пытающихся найти способы заработать деньги на доверчивых и неосторожных. Хакеры. Хакеры делают все возможное, чтобы использовать уязвимости в программном обеспечении для получения денежной выгоды, часто в ущерб владельцу сайта.
Используя плагин HTTP Header в Joomla для контроля того, какой контент предоставляется вашим посетителям, Вы снижаете вероятность того, что хакеры смогут предоставлять вредоносный контент Вашим посетителям с помощью устаревших и уязвимых расширений. Он помогает остановить внедрение вредоносных скриптов на ваш веб-сайт.
Проведём мысленный эксперимент.
У Вас хороший сайт на Joomla 3, сделали его лет 5 назад. Он до сих пор отлично выглядит и прекрасно работает. Все Ваши компоненты, плагины и модули обновлены. Всё хорошо, не так ли?
Ну, не совсем, потому что, когда Вы создавали свой сайт 5 лет назад, Вы установили модный плагин Foo Bar для вывода слов "FOO BAR" на главной странице. Поначалу это выглядело круто, но через некоторое время Вы передумали и удалили шорткод плагинов {foo}FOO - BAR{/bar} из материала на главной.
Но вот в чем проблема: Вы не сняли с публикации и/или не удаляли сам плагин, а его существовании на сайте и вовсе забыли. Я уверен, что у всех такое бывало.
Вернёмся из прошлого в наши дни: спустя 5 лет этот плагин всё еще существует, опубликован и активен на Вашем сайте. Но он не обновлялся в течение 5 лет, потому что Вы давно забыли о плагине или автор перестал его поддерживать. Теперь какой-то гнусный парень понял, что этот плагин имеет уязвимость в системе безопасности, которая может быть использована для запуска межсайтовой скриптовой атаки (XSS) на Ваш сайт и превращения Ваших ничего не подозревающих посетителей в жертв.
Межсайтовый скриптинг, который также известен как XSS, представляет собой уязвимость в системе безопасности вашего сайта, которая позволяет злоумышленнику скомпрометировать взаимодействие ваших пользователей с вашим уязвимым веб-сайтом. [Что такое XSS-уязвимость и как тестировщику не пропустить ее - статья на Хабре, - Т.С.].
Злоумышленник применяет XSS на Вашем уязвимом сайте для отправки вредоносного скрипта ничего не подозревающему пользователю. Поскольку скрипт пришел с Вашего веб-сайта, браузер пользователя не знает, что скрипту нельзя доверять, и выполняет его при загрузке и открытии страницы.
Вредоносные скрипты, запускаемые таким образом, могут вызвать множество проблем у Вашего пользователя, от кражи паролей и логинов, хранящихся в файлах cookie, до перенаправления пользователя на фишинговые сайты. Скрипты могут даже изменить внешний вид страницы и показывать Вам различную рекламу.
Использование плагина Joomla HTTP Headers помогает остановить межсайтовые скрипты, гарантируя, что ему отображаются только те скрипты и контент, которые Вы хотите отобразить своему посетителю. Все остальное блокируется.
Итак, в приведенном выше примере вы могли бы настроить плагин HTTP Headers так, чтобы он загружал JavaScript файлы Вашего сайта только из указанной папки или, возможно, CDN (если используется), чтобы предупредить атаку.
Вы также можете запретить сайту запускать inline JavaScript. Но нужно понимать что Вы делаете и помнить об используемых Вами подходах к разработке сайта, дабы не получить проблемы в дальнейшем.
Использование плагина помогло бы остановить выполнение вредоносного кода JavaScript на вашем веб-сайте. Даже если ваш уязвимый плагин Foo Bar был виноват в том, что хакер смог внедрить вредоносный код на ваш сайт.
На заметку:
Распространенными уязвимыми местами на сайтах, подверженные XSS-атакам, являются формы ввода пользовательской информации (страницы логина, формы подписки на рассылку новостей, формы обратной связи и т.д.) без проверки и шифрования.
Где найти HTTP Headers Plugin в Joomla 4?
Найти его можно в менеджере плагинов, там же, где и все остальные.
Как использовать плагин HTTP Headers?
Использование HTTP-плагина в Joomla относительно просто, но, желательно перед изменением настроек по умолчанию ознакомиться с некоторыми особенностями его использования. Хотя некоторые из них уже должны быть Вам знакомы.
Например, при работе с изображениями мы можем увидеть атрибут img-src, где img соответствует типу "изображения" и src - верный путь к файлу. Это простой HTML.
В конце этой статьи приведен список полезных сайтов с дополнительной информацией, которая поможет вам использовать этот плагин Joomla.
Настройки плагина HTTP Headers - 1-й таб
В первом табе находятся основные параметры плагина. Здесь можно установить настройки для
X-Frame Options
Referrer-Policy
Cross-Origin-Opener-Policy
А также принудительно установить HTTP заголовки. Здесь же есть несколько ссылок на документацию, которая даст Вам более подробное представление о доступных параметрах. Теперь рассмотрим каждый в отдельности.
X-Frame Options
Первый элемент настроек - X-Frame Options - включён по умолчанию.
Эта опция определяет будет ли контент Вашего сайта отображаться на другом сайте в <frame>, <iframe>, <embed> or <object> . Если Вы отключите эту опцию - любой другой сайт сможет отображать Ваш сайт, например, в iframe.
Если x-frame-options включён, то в заголовки сайта добавится x-frame-options: SAMEORIGIN (значение по умолчанию). Этот заголовок позволит отображать контент Вашего сайта в <frame>, <iframe>, <embed> or <object> , но только на Вашем сайте.
Также этот заголовок позволяет защитить сайт и пользователей сайта от кликджекинга (Wiki). Злоумышленник размещает <iframe> на своём сайте, а в качестве источника <iframe> указывает Ваш сайт. Затем злоумышленник использует несколько прозрачных слоев своего веб-сайта поверх него.
Это обманом заставляет пользователя кликнуть по кнопке или ссылке на прозрачном верхнем слое, потому что пользователь считает, что он нажимает на ссылку в iframe ниже.
Таким образом, злоумышленник перехватывает клики, предназначенные для исходной страницы во фрейме, и отправляет их на другую веб-страницу.
Аналогичные методы можно использовать для сбора данных о нажатии клавиш для ввода пароля и имени пользователя из учетных записей электронной почты, социальных сетей, данные банковских карт и т.д.
Большинство современных браузеров поддерживают параметры X-Frame, и это здорово. Поэтому я рекомендую включить этот параметр в плагине заголовков HTTP, чтобы помочь защитить Ваших пользователей, дабы они не стали жертвой кликджекинга.
Рекомендуется включить этот параметр из соображений безопасности. В опции "Добавить HTTP Headers" можно установит исключения для отдельных областей сайта.
Referrer-Policy
Следующий заголовок - Referrer-Policy (документация Mozilla, W3C). Этот заголовок определяет сколько данных о Вашем сайте будет передано на другой сайт при клике по внешней ссылке.
Заголовок запроса
Refererсодержит URL исходной страницы, с которой был осуществлён переход на текущую страницу. ЗаголовокRefererпозволяет серверу узнать откуда был осуществлён переход на запрашиваемую страницу. Сервер может анализировать эти данные, записывать их в логи или оптимизировать процесс кеширования.
Нередко мы видим атрибут rel="noreferrer" в тегах <a>. Например, <a href="https://someplace.com" rel="noreferrer">Click Me</a> . Атрибут noreferrer скрывает данные отправляющей стороны от принимающей стороны.
Осведомленность о том, какие данные с Вашего сайта могут "утечь" на сайт, на который Вы ссылаетесь, является важной частью обеспечения безопасности Вашего сайта и его пользователей.
Это особенно актуально, если на Вашем сайте есть регистрация пользователей, страницы содержат конфиденциальные данные или если Ваш сайт обрабатывает денежные транзакции. Плагин Joomla HTTP Headers помогает контролировать это на глобальном уровне, а не на уровне отдельных ссылок.
По умолчанию Referrer-Policy в Joomla 4 равно strict-origin-when-cross-origin . Этот заголовок не блокирует какие-либо данные исходной страницы, если только они не отправляются на менее безопасную http-страницу. Но, поскольку в наши дни большинство веб-страниц используют https, теперь это более серьезная проблема, чем когда-то.
Есть много безобидных и действительно полезных способов использования данных заголовка referer: аналитика, оптимизация кэширования и т.д. Но не каждый сайт может использовать эти данные в благих целях.
В качестве примера возьмем следующую ситуацию.
Большинство сайтов, на которых разрешена регистрация пользователей, имеют ссылку для сброса пароля рядом с формой входа на странице входа/регистрации. Также вполне вероятно, что на странице будут и другие ссылки на внешние сайты, ссылки на социальные сети или, возможно, в нижнем колонтитуле есть некоторые "полезные ссылки". ["Обвязка" контента в шаблоне сайта редко меняется от страницы к странице. Футер на всех страницах чаще всего одинаковый - Т.С.]
Всё это уводит из безопасной среды. Теперь, если нет Referrer-Policy , заголовок Referrer, который отправляется на один из этих внешних сайтов при нажатии на ссылку со страницы входа, может содержать ссылку для сброса пароля. А также другую информацию, которой вы поделились с этим внешним веб-сайтом. Это может представлять угрозу безопасности для пользователя, ставя под угрозу его данные.
Из-за потенциальной угрозы безопасности на странице с конфиденциальными данными такого типа также рекомендуется удалить со страницы весь сторонний контент. Это относится ко всем ссылкам и контенту, вставленным в <iframe> , таких как виджеты социальных сетей и видео YouTube. Поскольку данные, введенные на этой странице, могут быть отправлены через заголовок Referrer на эти сайты, если Вы нажмете на только что появившееся милое видео с котенком.
Плагин HTTP Headers для Joomla 4 решает эту проблему, позволяя выбрать один из 8 вариантов значений Referrer-Policy для Вашего сайта. У каждого есть свои ограничения на то, когда и сколько данных нужно передавать.
Пробежимся по вариантам значений заголовка (страница документации Mozilla):
no-referrer- ЗаголовокReferrerбудет опущен: отправленные запросы не содержат никакой информации оReferrer.no-referrer-when-downgrade- отправляет Referer только по протоколам одинакового или более высокого уровня безопасности (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Отправка Referer по протоколу с более низким уровнем безопасности не производится (HTTPS→HTTP, HTTPS→file).origin- отправлять только домен сайта, без указания конкретной страницы. Например при переходе со страницыhttps://example.com/page.htmlв Referer страницы будет только доменhttps://example.com/origin-when-cross-origin- отправлять полныйRefererдля запросов в пределах текущего источника и равного уровня безопасности протокола (HTTP→HTTP, HTTPS→HTTPS) , но для запросов на другой источник и запросы с более низким уровнем безопасности протокола отправлять только домен (HTTPS → HTTP).same-origin- отправка полногоRefererдля запросов к тому же источнику. Не указыватьRefererвообще для сторонних источников.strict-origin- указывать вRefererтолько домен сайта, если уровень безопасности протокола источника и адресата равны (HTTPS→HTTPS).Referrerне будет отправлен менее безопасным адресатам (HTTPS→HTTP).strict-origin-when-cross-origin(значение в Joomla 4 по умолчанию) - отправлять полныйRefererдля запросов в пределах одного источника [Когда пользователь "ходит внутри" сайта, сервер отправляет (и получает соответственно) полный Referer в заголовках. - Т.С.]. Для внешних источников отправлять только домен сайта в случае если уровень безопасности протокола одинаковый. Не отправлятьRefererесли уровень безопасности протокола ниже [Ваш сайт на https. Вы указали ссылку на другой сайт c https - сервер сайта получит только Ваш домен. Если Ваш сайт на https и Вы указали внешнюю ссылку с http, то при переходе по ней чужой сервер не получит заголовок Referer и не узнает откуда был переход - Т.С.]. Обратите внимание, что это значение по умолчанию в Joomla 4 если Вы не указали своих настроек или указанное Вами значение недопустимо. Ранее значение по умолчанию былоno-referrer-when-downgrade.unsafe-url- всегда отправлять полныйReferer, не обращая внимания на безопасность. Обратите внимание на то, что такая Referer-policy потенциально может привести к утечке данных с Вашего сайта при переходе по ссылкам с протоколом http. Перед использованием подробно изучите влияние этого параметра на безопасность.
Я бы установил значение этого параметра в no-referrer (если нет особых причин не делать этого), таким образом для всего сайта будет включена политика "ничего не сообщать об источнике". Или же origin-when-cross-origin, что позволит вам анализировать трафик по URL-адресам на Вашем собственном сайте (таким образом, без утечки данных), но отправлять только свой домен в качестве рефера при переходе на внешний сайт, поскольку нет дополнительных данных из URL-адреса.
Cross-Origin-Opener-Policy
Третий параметр, который можно установить на первой вкладке, — это Cross Origin Opener Policy (политика открытия перекрестного источника), которая представляет собой браузерную функцию безопасности, позволяющая Вам изолировать разные Browser Context Groups друг от друга.
Хорошим примером этого является использование всплывающих [не модальных, на javascript - Т.С.] окон, где исходная группа контекста браузера (весь текст, изображения, ссылки и т. д.) отключается от новой группы контекста браузера, которая создается и затем отображается во всплывающем окне.
Этот параметр HTTP-заголовка довольно глубокий и сложный, хотя есть только 3 варианта. Поэтому я рекомендую перейти по ссылкам ниже, чтобы лучше понять, почему этот параметр должен быть установлен на Вашем сайте. А также узнать о некоторых дополнительных функциях, которые становятся доступны вам, когда эта опция активна.
Cross Origin Opener Policy помогает закрыть историческую лазейку в том, как браузеры обмениваются данными между различными контекстными группами, особенно когда на веб-сайте используются всплывающие окна.
Настройка Cross Origin Opener Policy поможет смягчить угрозы безопасности данных, одна из самых важны для нас - Spectre (Wiki, Новогодние подарки, часть вторая: Spectre - статья на Хабре). Spectre делает данные, загруженные в ту же группу контекста просмотра, что и ваш код, потенциально доступными для чтения хакером. Spectre позволяет измерять время выполнения определенных операций и даёт хакерам возможность угадать, что находится в кэше процессора. Когда хакеры получат данные из кэша процессора они получают доступ к вашим данным.
Cross Origin Opener Policy работает, изолируя исходные данные HTML-документа от HTML-данных, которые будут отображаться во всплывающем окне исходного документа. Это помогает предотвратить то, что называется cross-origin attacks или XS-Leaks.
Этот процесс похож на знакомый rel="noopener" , который мы используем для обычных ссылок. Но, в отличие от rel="noopener", который работает только для исходящих ссылок, документы, для которых в заголовках HTTP с помощью плагина Joomla установлена политика cross-origin-opener-policy, ограничивают данные в обоих направлениях. Таким образом, HTML-документ с активной политикой Cross Origin Opener Policy не будет иметь ссылки на него в HTTP-заголовке, а свойство window.opener HTTP-заголовка нового окна будет иметь значение null.
При установке этого параметра в плагине HTTP-заголовков Joomla вам доступны 3 параметра:
unsafe-none- Это значение позволяет разрешает открытие сайта в виде поп-апа в других источниках, если толькоcross-origin-opener-policyне задано какsame-originилиsame-origin-allow-pop-up.same-origin-allow-popups- защищает документ от открытия в поп-апах других источников, но позволяет приложению взаимодействовать с собственными всплывающими окнами. Параметр сохраняет ссылки на недавно открытые окна или вкладки, которые либо не устанавливаютcross-origin-opener-policyлибо отказываются от изоляции, устанавливаяcross-origin-opener-policyравнойunsafe-none.same-origin(значение Joomla 4 по умолчанию) - изолирует контекстную группу просмотра только для документов того же происхождения. Документы из разных источников не загружаются в одну и ту же контекстную группу просмотра.
На заметку: верным выбором для Вашего сайта было бы оставить это значение same-origin так, как это сделано в Joomla 4 по умолчанию. Это позволит успешно загружать содержимое вашего собственного веб-сайта/домена во всплывающие окна, но ограничит доступ к элементам, загружаемым во всплывающее окно из внешнего источника.
Как упоминалось в начале этого раздела, некоторые расширенные функции зависят от cross-origin isolation.Такие функции, как объекты SharedArrayBuffer или методы Performance.now() которые нужны определенным service workers для нерегулируемых таймеров, доступны только в том случае, если в вашем документе есть HTTP-заголовок cross-origin-opener-policy со значением same-origin.
От переводчика
Продолжение следует. Замечания и пожелания к переводу приветствуются.
Так же полезные ресурсы
Ресурсы сообщества:
https://vc.ru/s/1146097-joomla - Сообщество Joomla на VC.
Telegram:
вакансии и предложения работы по Joomla: фуллтайм, частичная занятость и разовые подработки. Размещение вакансий здесь.
