1

Есть ли способ сообщить (как клиент), есть ли какой-либо код на стороне сервера, который обрабатывается (PHP/ASP.NET), или это просто статические html-файлы?

3 ответа3

2

Попробуйте buildwith.com, он расскажет вам все, что он может узнать о платформе, на которой работает сервер.

2

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

Все, что увидит пользователь, это то, что им подают HTML-документ (расширение .html).

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

0

В зависимости от настроек сервера - и если вы работаете в Linux - вы можете использовать инструмент командной строки curl с параметром -I для отображения таких заголовков; используя Microsoft в качестве примера:

curl -I www.microsoft.com/

Microsoft возвращает следующие заголовки:

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 1020
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "67991fbd76a6c91:0"
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Sun, 12 Oct 2014 08:28:11 GMT

Итак, эта строка с надписью X-Powered-By: ASP.NET? Ну, я думаю, что это правильно? Ну не совсем. Хотя сервер может использовать ASP.NET, это не означает, что просматриваемая страница использует ASP.NET.

И чтобы сделать ситуацию еще сложнее, конечно, Microsoft будет использовать ASP.NET, верно? Но угадайте что? В реальном мире большинство серверов, по крайней мере, хорошо управляемых, не рекламируют какие-либо реальные сведения об используемом ими серверном программном обеспечении. Это называется усилением работы сервера. Например, давайте посмотрим на вывод заголовка для сайта BBC:

curl -I www.bbc.co.uk/

И вывод заголовка такой:

HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html
Content-Language: en-GB
Etag: "1d86e04c393ac9be31d256305b22b59e"
X-PAL-Host: pal116.telhc.bbc.co.uk:80
Transfer-Encoding: chunked
Date: Sun, 12 Oct 2014 08:32:46 GMT
Connection: keep-alive
Set-Cookie: BBC-UID=d524632ae30c5a5eebfec61e915b62ab64b472f7c4b4e10e5ae1a4c76eacdbc00curl/7.30.0; expires=Thu, 11-Oct-18 08:32:46 GMT; path=/; domain=.bbc.co.uk
X-Cache-Action: HIT
X-Cache-Hits: 827
X-Cache-Age: 88
Cache-Control: private, max-age=0, must-revalidate
Vary: X-CDN

Единственное, что мы можем извлечь из этого, это то, что основной сайт BBC использует Apache. Но это обеспечивает хороший кусок сети. Знаем ли мы, какая версия Apache? Мы знаем, что такое сценарий за кулисами? Нету. Не за что.

И это сделано намеренно, поскольку подавляющее большинство скриптов вредоносного ПО / бота используют Интернет в поисках слабых мест в системах, верно? Что ж, если сайт в основном рекламировал: «Эй! Я использую эту старую версию Apache, а также старую версию PHP! » Ну угадай что? Теперь вредоносное ПО точно знает, какие кнопки нажимать, чтобы получить доступ к слабым местам в системе. Никто не хочет этого. Таким образом, подавляющее большинство хорошо управляемых серверов там не афишируют, кто они.

Конечно, укрепление может только замедлить атаку. То есть, скажем, есть 1000 возможных способов атаковать сервер. Отправка подробных заголовков может сузить это число до 20, чтобы хакер мог войти быстрее. Но решительный хакер может просто позволить всем 1000 подвигам попытаться прорваться. Так что это не надежный метод сдерживания атак. Но это лучше, чем ничего.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .