X powered by что это

Как отключить X-Powered-By, за минуту

Настройка серверов windows и linux

X-Powered-By

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами познакомились с очень полезной утилитой Windows Admin Center, которая позволяет вам очень большие возможности по администрированию серверов и клиентских рабочих станций в домене. Сегодня я хочу с вами поговорить немного про безопасность веб ресурсов, а именно разобрать, что из себя представляет заголовок X-Powered-By, как его отключение может положительным образом сыграть на работе сайта. Я покажу, как отключать X-Powered-By для разных платформ. Думаю, что после прочтения данной статьи вы не поленитесь и сделаете это.

Что такое заголовок X-Powered-By

Все началось после попадания сайта под фильтр МПК от Яндекса, я рассматривал много всего, что можно улучшить и оптимизировать, например обновил PHP на сайте, а так же установил самую последнюю версию CMS WordPress 6.3, повысив безопасность и скорость. Но безопасность настолько многогранное направление, что 100% вы защититься не сможете, но стремиться к этому нужно. И вот в один из вечеров я наткнулся на X-Powered-By.

X-Powered-By — это заголовок HTTP, который обычно включается в ответ сервера при обработке запросов. Он указывает на программное обеспечение или технологию, используемую для работы веб-сервиса.

Особенности заголовка X-Powered-By:

✅Идентификация технологии: Заголовок X-Powered-By позволяет идентифицировать используемую технологию или программное обеспечение на сервере. Например, значение может быть «X-Powered-By: PHP/7.3.9» или «X-Powered-By: ASP.NET».
✅Отладка и анализ: Заголовок X-Powered-By может быть полезен при отладке и анализе работы веб-сервиса. Он помогает разработчикам определить, какие технологии и версии используются на сервере, что может быть полезно для устранения ошибок и оптимизации производительности.
❌Информация о безопасности: Заголовок X-Powered-By может содержать информацию о безопасности, такую как «X-Powered-By: Express». Это может быть полезно для злоумышленников, которые могут использовать эту информацию для атак на сервер.
✅Поддержка клиентов: Заголовок X-Powered-By может быть полезен для клиентов, чтобы узнать, какая технология используется на сервере. Например, разработчики могут использовать эту информацию для выбора правильного клиентского программного обеспечения или библиотеки для взаимодействия с сервером.
❌Влияние на производительность: Заголовок X-Powered-By может незначительно повлиять на производительность сервера, так как он добавляет дополнительную информацию в ответ сервера. Однако этот эффект обычно незаметен для большинства веб-сервисов.

Полезность и вред заголовка X-Powered-By зависит от конкретного случая и требований безопасности. В некоторых случаях полезно скрыть информацию о используемой технологии для повышения безопасности сервера. В других случаях, например, при разработке и отладке, полезно иметь доступ к этой информации.

Исходя из описанного выше, лично для себя я не вижу особого смысла в данном заголовке на моем сайте. Я и так знаю, какая у меня версия PHP, а рядовым пользователям, это и подавно не нужно.

На каких движках вы можете встретить X-Powered-By

Apache
Nginx
PHP
ASP.NET
Node.js

Вот пример запроса к серверу по определению X-Powered-By:

Server: nginx/1.20.2
Date: Wed, 04 Oct 2023 22:11:49 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 93882
Connection: keep-alive
Cache-Control: private, max-age=600
Last-Modified: Wed, 04 Oct 2023 22:11:49 GMT
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
Set-Cookie: Culture=ru; domain=myseldon.com; path=/
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=2592000

Тут видно, что сайт работает на IIS ASP.NET.

Как выглядит X-Powered-By

Как отключить заголовок X-Powered-By на IIS

Для того, чтобы ваш сервер не генерировал заголовок X-Powered-By вам необходимо открыть диспетчер IIS. На уровне сервера найдите иконку «HTTP Responce Header«.

Как отключить заголовок X-Powered-By на IIS

Если тут будет строка X-Powered-By, смело ее удаляйте.

HTTP Responce Header удаление X-Powered-By

ASP.NET: В ASP.NET заголовок X-Powered-By может быть отключен путем установки значения «Response.Headers.Remove («X-Powered-By»)» в коде приложения или в файле конфигурации web.config. Включите эти строки в элемент

Для IIS 10

Чтобы отключить заголовок X-Powered-By на IIS с помощью PowerShell, выполните следующие шаги:

Откройте PowerShell от имени администратора.
Введите следующую команду, чтобы импортировать модуль WebAdministration:

Import-Module WebAdministration

Выполните команду, чтобы получить текущий конфигурационный файл IIS

$config = Get-WebConfiguration -PSPath ‘IIS:\’

Получаем секцию httpProtocol в конфигурации

$httpProtocolSection = $config.GetSection(‘system.webServer/httpProtocol’)

Устанавливаем значение false для добавления заголовка X-Powered-By

$httpProtocolSection.customHeaders.’add[@name=»X-Powered-By»].value’ = $false

Применяем изменения

$config | Set-WebConfiguration -PSPath ‘IIS:\’

Этот код импортирует модуль WebAdministration, получает конфигурацию IIS и устанавливает значение false для добавления заголовка X-Powered-By в секции httpProtocol. Затем изменения применяются к конфигурации IIS с помощью Set-WebConfiguration.

Как удалить заголовок X-Powered-By в Apache

Для отключения заголовка X-Powered-By веб-сервере Apache можно использовать директиву «Header unset X-Powered-By» в файле конфигурации .htaccess или httpd.conf. Для этого вам нужно отредактировать ваш файл .htaccess, сделать это можно через подключение на хостинг или ваш сервер, открыв его через текстовый редактор и внеся вот такой код:

Header unset x-powered-by

Включите модуль mod_headers с помощью заголовков a2enmod.
Откройте файл apache httpd.conf, который доступен внутри /usr/local/apache2/conf.
Удалите заголовок X-Powered-By, если он существует.
Перезапустите Apache с помощью systemctl, перезапустите apache2.

Как удалить заголовок X-Powered-By через PHP

Для отключения заголовка X-Powered-By в PHP можно использовать функцию header_remove() или установить значение «expose_php = Off» в файле php.ini.

sudo vi /etc/php.ini

Находим строку expose_php = on и меняем ее на expose_php = off

Не забудьте, что может понадобиться перезапуск сервера:

sudo service httpd restart или sudo service apache2 restart

Так же это можно сделать и на хостинге, например у меня это Mchost. Вам необходимо зайти в настройки сайта и выбрать управление PHP, там найти expose_php. Дождаться применения параметров.

PHP отключение X-Powered-By

Может получиться так, что у вас не будет доступа к файлу php.ini, в таком случае вы можете использовать код PHP. Добавьте в код для удаления X-Powered-By:

Если хотите поиздеваться, над теми. кто обычно эти заголовки просматривает ,то можете указать вообще свое значение:

Как отключить заголовок X-Powered-By на Nginx

В случае с веб-сервером Nginx можно использовать директиву «proxy_hide_header X-Powered-By» в файле конфигурации для скрытия заголовка X-Powered-By.

Впишите в секцию http: server_tokens off;

Как удалить заголовок X-Powered-By в Node.js:

В Node.js заголовок X-Powered-By может быть отключен с помощью модуля Helmet, который позволяет установить значение «hidePoweredBy: true».

Запрещаем X-Powered-By на cloudflare

Создайте правило по пути:

Dashboard > Rules > Transform Rules > Managed Transforms

Влияние на время ответа

До отключения X-Powered-By:

Время ответа 231 мс
Сжатие gzip Нет
Размер ответа 11.4 Кб
Заголовок Last-Modified Нет
server: nginx
date: Wed, 04 Oct 2023 22:52:48 GMT
content-type: text/html; charset=UTF-8
content-length: 11632
x-powered-by: PHP/7.3.2
vary: Accept-Encoding,Cookie,User-Agent
cache-control: max-age=3, must-revalidate
cache-control: max-age=600
last-modified: Wed, 04 Oct 2023 15:34:31 GMT
expires: Wed, 04 Oct 2023 23:02:48 GMT
content-encoding: gzip

Время ответа 214 мс вплоть до 174
Сжатие gzip Нет
Размер ответа 11.4 Кб
Заголовок Last-Modified Нет
server: nginx
date: Wed, 04 Oct 2023 23:26:29 GMT
content-type: text/html; charset=UTF-8
content-length: 11632
vary: Accept-Encoding,Cookie,User-Agent
cache-control: max-age=3, must-revalidate
cache-control: max-age=600
last-modified: Wed, 04 Oct 2023 15:34:31 GMT
expires: Wed, 04 Oct 2023 23:36:29 GMT
content-encoding: gzip

Сравнение времени ответа при выключении X-Powered-By

В целом, решение о том, нужно ли отключать заголовок X-Powered-By, зависит от конкретных требований безопасности и конфиденциальности информации. Если информация о используемой технологии не должна быть доступна посторонним пользователям, то рекомендуется отключить этот заголовок. Однако, если требуется отладка или анализ работы сервера, то полезно оставить его включенным. На этом у меня все, с вами был Иван Сёмин ,автор и создатель IT портала Pyatilistnik.org.

PHP — Как скрыть X-Powered-by в HTTP заголовках

PHP - Как скрыть X-Powered-by в HTTP заголовках

В сегодняшней статье мы поговорим о том как можно легко и быстро спрятать версию вашего интерпретатора PHP в HTTP заголовках.

Когда пользователь отправляет какой-нибудь запрос на ваш сайт, то этот запрос сначала обрабатывается вашим веб сервером Apache или Nginx и потом веб сервер этот запрос перенаправляет на ваш интерпретатор, в нашем случим это PHP. После того как PHP обработает запрос он, вернет ответ обратно веб серверу, а уже веб сервер вернет весь результат пользователю. В этом самом результате, а именно в HTTP заголовках помимо всех информации о сервере еще и передается версия вашего PHP интерпретатора которая на данный момент у вас установлена на сервере, а это может быть уже опасно для безопасности вашего веб приложения.

Скрывать версию вашего интерпретатора PHP от лишних глаз может помочь вам обеспечить безопасность вашего веб приложения. Обращаю вашего внимание на то что способ скрыть версию вашего PHP интерпретатора поможет лишь при некоторых типах атак, когда роботом ищется определённая версия с определённой уязвимостью.

По умолчанию ваш веб сервер Apache или Nginx передает номер версии PHP в HTTP заголовках. Имя заголовка который отвечает за версию PHP называется X-Powered-By.

php hide version

Как видим со скриншота наш веб сервер передает версию PHP которая у нас установлена.

Чтобы скрыть информацию о нашем интерпретаторе PHP, вам нужно изменить параметр expose_php который находиться в основном конфигурационном файле под названием php.ini который находится в директории /etc.

Открываем конфигурационный файл php.ini любым удобным для вас текстовым редактором.

$. sudo vim /etc/php.ini

Находим в файле параметр expose_php.

php hide version

Меняем значения параметра с On на Off.

php hide version

После того как мы изменили значения параметра expose_php, то теперь нужно перезапустить PHP интерпретатор, используя следующую команду:

$. sudo service php-fpm restart

Обновляем страницу в браузере и смотрим на результат.

php hide version

Как видим в результате информация о нашем интерпретаторе PHP теперь не показывается.

Всем спасибо, я надеюсь что вам моя статья хоть чем-то помогла.

Лучшие практические методы для рабочей среды: Защита

Термин “рабочий режим” означает тот этап жизненного цикла программного обеспечения, на котором приложение или API является в целом доступным для конечных пользователей или потребителей. Напротив, на этапе “разработки” происходит активное создание и тестирование кода, и приложение не является открытым для внешнего доступа. Соответствующие системные среды называются, соответственно, рабочей средой и средой разработки.

Настройки среды разработки и рабочей среды при установке, как правило, являются различными, и к этим средам предъявляются абсолютно разные требования. То, что идеально для разработки, не всегда приемлемо в рабочем режиме. Например, в среде разработки можно задать подробное протоколирование ошибок для отладки, тогда как в рабочей среде такая особенность настройки может привести к уязвимости защиты. Во время разработки можно не беспокоиться о масштабируемости, надежности и производительности, тогда как в рабочем режиме все эти вопросы играют решающую роль.

В настоящей статье речь пойдет о лучших практических методах в области защиты приложений Express, развернутых в рабочей среде.

Не используйте устаревшие или уязвимые версии Express

Версии Express 2.x и 3.x больше не поддерживаются. Проблемы, связанные с защитой и производительностью в этих версиях, не будут подлежать решению. Не используйте эти версии! Если вы еще не перешли к работе с версией 4, выполните инструкции, приведенные в руководстве по миграции.

Кроме того, убедитесь в том, что уязвимые версии Express, перечисленные на странице Обновления системы защиты, вами не используются. В противном случае, выполните обновление до одного из стабильных выпусков, предпочтительно, до последнего.

Использование TLS

Если ваше приложение предназначено для работы с чувствительными данными или для их передачи, для защиты соединения и данных необходимо использовать криптографический протокол Transport Layer Security (TLS). Данная технология позволяет шифровать данные до передачи с клиента на сервер, тем самым обеспечивая защиту от многих распространенных (и простых) способов несанкционированного доступа. Хотя запросы Ajax и POST могут казаться неочевидными и “скрытыми” в браузерах, инициируемая ими передача данных в сети является уязвимой для незаконного сбора и анализа пакетов иатак посредника (атак “человек посередине”).

Возможно, вам знаком криптографический протокол Secure Socket Layer (SSL). SSL является предшественником TLS. Другими словами, если раньше вы пользовались SSL, пора переходить к TLS. В целом, для работы с TLS мы рекомендуем использовать сервер Nginx. Подробные инструкции по настройке TLS на Nginx (и на других серверах) можно найти в разделе Рекомендуемые конфигурации серверов (Mozilla Wiki).

Кроме того, удобным инструментом для получения бесплатного сертификата TLS является Let’s Encrypt — бесплатная, автоматическая и открытая сертификатная компания (CA), предоставленная корпорацией Internet Security Research Group (ISRG).

Использование Helmet

Helmet помогает защитить приложение от некоторых широко известных веб-уязвимостей путем соответствующей настройки заголовков HTTP.

Helmet, по сути, представляет собой набор из девяти более мелких функций промежуточной обработки, обеспечивающих настройку заголовков HTTP, связанную с защитой:

csp задает заголовок Content-Security-Policy для предотвращения атак межсайтового скриптинга и прочих межсайтовых вмешательств.
hidePoweredBy удаляет заголовок X-Powered-By .
hsts задает заголовок Strict-Transport-Security , принудительно активирующий защиту соединений с сервером (по протоколу HTTP с использованием SSL/TLS).
ieNoOpen задает заголовок X-Download-Options для IE8+.
noCache задает заголовок Cache-Control и заголовки Pragma для отключения кеширования на стороне клиента.
noSniff задает заголовок X-Content-Type-Options для защиты браузеров от прослушивания (сниффинга) MIME ответов с отличным от объявленного типом содержимого (content-type).
frameguard задает заголовок X-Frame-Options для защиты от кликджекинга.
xssFilter задает заголовок X-XSS-Protection для активации фильтра XSS (фильтра межсайтового скриптинга) в большинстве современных веб-браузеров.

Установите Helmet, как обычный модуль:

$ npm install --save helmet

Затем используйте его в своем коде:

 . var helmet = require('helmet'); app.use(helmet()); .

Как минимум, отключите заголовок X-Powered-By

Если использовать Helmet не нужно, как минимум, отключите заголовок X-Powered-By . Злоумышленники могут использовать этот заголовок (включенный по умолчанию) для выявления приложений на базе Express и активации целенаправленных атак.

Поэтому рекомендуется отключить данный заголовок с помощью метода app.disable() .

 app.disable('x-powered-by');

Если вы используете helmet.js , это будет сделано автоматически.

Безопасное использование cookie

Для того чтобы файлы cookie не подвергали опасности ваши приложения, не используйте стандартные имена сеансовых cookie и соответствующим образом настройте опции защиты файлов cookie.

Существует два основных сеансовых модуля cookie для промежуточной обработки:

Модуль express-session, заменяющий собой промежуточный обработчик express.session , встроенный в Express 3.x.
Модуль cookie-session, заменяющий собой промежуточный обработчик express.cookieSession , встроенный в Express 3.x.

Основное различие между этими двумя модулями состоит в способе сохранения сеансовых данных cookie. Промежуточный обработчик express-session сохраняет данные о сеансе на сервере; в самом файле cookie сохраняется только ИД сеанса, но не данные сеанса. По умолчанию, используется хранилище в оперативной памяти, но данный способ не предназначен для рабочей среды. В рабочей среде необходимо настроить масштабируемое хранилище сеансов; см. список совместимых хранилищ сеансов.

Промежуточный обработчик cookie-session, в отличие от описанного выше, реализует хранение на основе файлов cookie: выполняется полная сериализация сеанса в файл cookie, вместо того, чтобы сохранять только ключ сеанса. Этот способ следует использовать только при условии, что данные сеанса имеют относительно небольшой объем и легко могут быть преобразованы в элементарные значения (а не объекты). Хотя браузеры должны поддерживать не менее 4096 байт на каждый файл cookie, позаботьтесь о том, чтобы не допустить превышения данного ограничения. Размер не должен превышать 4093 байт на каждый домен. Кроме того, помните о том, что данные cookie являются видимыми для клиента, поэтому, если по какой-либо причине их следует защитить или скрыть, остановите свой выбор на модуле express-session как на более подходящем.

Не используйте стандартные имена сеансовых cookie

Использование имен сеансовых cookie, предлагаемых по умолчанию, может сделать ваше приложение уязвимым для разного рода атак. В данном случае возникает та же проблема с безопасностью, что и при использовании заголовка X-Powered-By : потенциальный злоумышленник может воспользоваться им для идентификации на сервере и организации целенаправленных атак.

Для того чтобы избежать такой проблемы, используйте обобщенные имена cookie; например, при использовании промежуточного обработчика express-session:

 var session = require('express-session'); app.set('trust proxy', 1) // trust first proxy app.use( session(< secret : 's3Cur3', name : 'sessionId', >) );

Настройка опций защиты cookie

Для обеспечения защиты необходимо настроить следующие опции защиты файлов cookie:

secure — обеспечивает отправку файлов cookie браузером только с использованием протокола HTTPS.
httpOnly — обеспечивает отправку cookie только с использованием протокола HTTP(S), а не клиентского JavaScript, что способствует защите от атак межсайтового скриптинга.
domain — указывает домен cookie; используется для сравнения с доменом сервера, на котором запрашивается данный URL. В случае совпадения выполняется проверка следующего атрибута — пути.
path — указывает путь cookie; используется для сравнения с путем запроса. Если путь и домен совпадают, выполняется отправка cookie в запросе.
expires — используется для настройки даты окончания срока хранения для постоянных cookie.

Ниже приведен пример с использованием промежуточного обработчика cookie-session:

 var session = require('cookie-session'); var express = require('express'); var app = express(); var expiryDate = new Date( Date.now() + 60 * 60 * 1000 ); // 1 hour app.use(session( < name: 'session', keys: ['key1', 'key2'], cookie: < secure: true, httpOnly: true, domain: 'example.com', path: 'foo/bar', expires: expiryDate >>) );

Дополнительные замечания

Ниже приводится несколько дополнительных рекомендаций, взятых из исчерпывающего Контрольного списка требований к защите Node.js. В этой публикации можно найти дополнительную информацию по всем приведенным ниже рекомендациям:

Введите ограничение скорости передачи данных во избежание атак методом грубого подбора сочетаний символов для идентификации. Для реализации стратегии ограничения скорости передачи данных можно воспользоваться Шлюзом API StrongLoop. В качестве альтернативы, можно использовать промежуточный обработчик, например, express-limiter, но для этого придется внести некоторые изменения в код.
Всегда применяйте фильтрацию и очистку пользовательского ввода в целях защиты от атак межсайтового скриптинга (XSS) и ввода ложных команд.
Обеспечьте защиту от атак внедрения SQL-кода с помощью параметризованных запросов или подготовленных операторов.
Используйте инструмент sqlmap с открытым исходным кодом для выявления уязвимостей к внедрению SQL-кода в приложение.
Используйте инструменты nmap и sslyze для проверки конфигурации шифров, ключей и повторных согласований SSL, а также действительности сертификата.
Используйте safe-regex, чтобы убедиться в невосприимчивости регулярных выражений к атакам отказа в обслуживании регулярных выражений.

Избегайте прочих известных уязвимостей

Следите за рекомендациями Node Security Project, касающимися Express или других модулей, используемых вашим приложением. В целом, Node Security Project — это непревзойденный ресурс, предоставляющий ценные знания и инструменты, связанные с безопасностью Node.

И наконец, приложения Express — как и любые другие приложения — могут быть уязвимы к разнообразным веб-атакам. Ознакомьтесь с описаниями известных веб-уязвимостей и примите соответствующие меры предосторожности, чтобы их избежать.