Проверка CMS сайта
Инструмент для проверки CMS позволяет определить движок сайта и другие используемые на ресурсе технологии: набор шрифтов, системы статистики, CDN, JavaScript фреймворки и прочее. С помощью этого инструмента вы можете проверить сайт конкурента или клиента на продвижение.
Зачем нужно проверять CMS?
Этот инструмент поможет, если вам нужно определить, на чем сделан сайт конкурента или клиента, а также оценить понравившийся сайт, если вы хотите скопировать его или использовать некоторые идеи у себя. Перед созданием собственного сайта стоит найти несколько вариантов, которые вы можете взять за основу, и посмотреть, на чем они сделаны. Помимо движка может понадобиться информация о различных технологиях сайта, не принадлежащего вам.
Почему проверка показывает несколько CMS на одном сайте?
Может быть так, что на сайте используется несколько систем управления для разных разделов — например, для каталога и блога. Этот вариант подходит в случае, если функциональность одной CMS не справляется со всеми специфическими задачами компании, а создать собственную систему управления, которая учитывала бы все особенности бизнеса, невозможно.
Почему сервис не определяет ЦМС на моем сайте?
Сервис может не показывать CMS сайта в случае, если он находится на самописном движке или движок непопулярный и его еще нет в нашей базе. Также причинами могут быть: настроенный редирект на другой сайт, отсутствие ответа от сервера сайта или некорректный ввод URL.
Рейтинг CMS
По данным Ruward Track, ТОП-10 самых популярных в России CMS выглядит так:
Анализ сайта: как узнать «на чём» сделан сайт?
Почти каждому веб-разработчику знакомо чувство, когда видишь интересный сайт и очень любопытно разобраться «как это работает?», «на чём он сделан?», «какие виджеты используются?» и т.д.
Есть разные небольшие хитрости «бывалых», например, «разобрать под лупой» html-код — где иногда можно что-то и выловить. Но этот способ довольно ненадежный, т.к. не позволяет провести более полный анализ не имея доступа к «внутренностям сайта».
Вообщем, теперь, когда вам нужно будет в очередной раз провести анализ сайта и получить ответ на вопрос «на чём сделан этот сайт?» — просто воспользуйтесь очень полезным сервисом BuiltWith.com
Как пользоваться веб-сервисом BuiltWith.com
Данный сервис очень прост в использовании — достаточно ввести в поисковое поле необходимый линк сайта (например, www.topobzor.com) и нажать кнопку Lookup.
В итоге веб-сервис нам выдаст список из таких параметров:
- информацию о сервере (Server Information)
- какая CMS используется (Content Management Systems)
- какой фреймворк используется (Framework)
- какие рекламные площадки используются (Advertising)
- какие системы аналитики и SEO-анализа применяются (Analytics and Tracking)
- какие JavaScript библиотеки есть на сайте (JavaScript Libraries)
- какие виджеты используются (Widgets)
- какие каналы RSS/Atom и пр. (Aggregation Functionality)
- информация о Doctype, CSS/HTML версиях и пр. (Document Information)
- какая используется кодировка на сайте (Encoding)
При этом, это всё в бесплатной версии веб-сервиса BuiltWith.com.
Конечно, у такого функционального веб-сервиса есть и платные пакеты, которые позволяют сохранять анализ сайтов, проводить более серьезную и основательную аналитику, проверять большие списки сайтов и пр. При этом цены стартуют от $295 для одного человека до $8950 в год (корпоративная версия).
Еще приятный бонус — у BuiltWith.com. есть:
- плагин (add-on) для FireFox: https://addons.mozilla.org/en-us/firefox/addon/builtwith/
- плагин (extension) для Chromehttp://www.chromeextensions.org/other/builtwith-technology-profiler/
Будем рады, если вы поделитесь своими способами «препарирования сайта» ��
Как узнать, на каком движке сделан сайт
На стартовом этапе создания ресурса, хорошо бы посмотреть, на какой CMS работают сайты конкурентов. Это поможет решить, на каком движке делать свой. Если большинство небольших интернет магазинов работают, например, на OpenCart и PrestaShop, для этого есть причины. Но некоторые вебмастера скрывают подобную информацию. Потому что злоумышленникам проще взломать портал, когда известно на чем он работает.
Как узнать, на каком движке работает сайт, вручную
Один из вариантов узнать cms: кликнуть правой кнопкой и выбрать информацию о странице. Появится окно с данными по веб-сайту. Нас интересует строка: generator. Если тегов много, открываем исходный код.
Запускаем поиск через меню « правка» – «найти» или комбинацией клавиш «ctrl+f». В строку забиваем: meta name=»generator» и смотрим.
Обычно названия популярных cms прописаны по умолчанию в этом теге. Но администраторы часто вручную стирают информацию по движку, чтобы скрыть ее от злоумышленников и конкурентов.
Узнаем CMS по ссылке на админпанель
Еще один вариант — посмотреть, какая на сайте админка. Для этого вручную перебираем возможные пути к популярным cms. К адресу портала приписываем через слеш разные варианты пути к панели администратора. Например, для joomla добавляем /administrator. Но и этот способ не всегда срабатывает. Чтобы защитить сайт от взлома, вебмастера часто изменяют путь к админпанели или вообще разрешают вход только со своего IP.
Адреса к админпанелям популярных cms:
- DLE — /admin.php
- Битрикс — /bitrix/admin
- WordPress — /wp-admin
- MODx — /manager
- Drupal и другие — /user ; /login ; /admin
По структуре ссылок
Еще один вариант: посмотреть структуру ссылок портала. В зависимости от движка, они отображаются по-разному в адресной строке.
Сейчас большинство вебмастеров используют человеко-понятные урлы вида /stranica-sayta-j-kotikah.html и этот способ практически не работает.
Примеры структуры ссылок «по умолчанию»:
- wordpress: …/p301
- joomla: …/index.php/…
- ocstore: …/index.php?route=
- prestashop: …/page_name
Смотрим на чем создан сайт в robots.txt
В этом файле хранятся инструкции для поисковых роботов. Очень полезный инструмент, который есть практически на любом ресурсе. Вебмастера используют его, чтобы запретить индексацию некоторых страниц или разделов сайта, настроить временной интервал между загрузкой файлов с сервера, указать правильное зеркало веб-портала и т.д. Чтобы посмотреть документ, добавьте к имени ресурса: /robots.txt.
Смотрим платформу сайта с помощью онлайн-сервисов
Глянули robots.txt, покопались в коде и погадали на кофейной гуще, а посмотреть движок не получилось? Попробуем другие методы, например, один из онлайн-инструментов.
2ip.ru
Чтобы открыть сервис, перейдите по ссылке https://2ip.ru/cms/.
Простой и удобный русскоязычный инструмент. Вводим адрес и нажимаем: «Узнать». Система проверит сайт на наличие признаков движков. В базе данных сервиса 65 различных cms. С помощью 2ip можно посмотреть и другую информацию о портале:
- домен, хостинг, информацию о сайте и IP-адресе;
- стойкость пароля, посещаемость и скорость загрузки сайта;
- проверить анонимность, время загрузки файлов и многое другое.
Builtwith
Простота работы устраняет все неудобства, связанные с англоязычным интерфейсом. В строку вводим адрес и кликаем: «Lookup». Инструмент отлично справляется с задачей. Кроме данных о cms, сервис покажет:
- сервер, фреймворк, язык программирования;
- данные по рекламе, счетчики аналитики;
- библиотеки JavaScript и виджеты;
- метатеги, CSS, стандарт HTML и кодировку страниц.
Узнаем, на чем сделан сайт с помощью плагинов к браузерам
Если информацию о движках ищем часто, чтобы не бегать по сторонним ресурсам, устанавливаем один из плагинов для браузера.
wappalyzer
Работает с firefox, chrome и opera. Показывает движок, веб-сервер, шрифты, фреймворк, язык программирования и др. Переходим по ссылке, выбираем версию под свой браузер и устанавливаем. Не требует перезагрузки и быстро работает.
После установки, в адресной строке появятся иконки с данными о сайте. Чтобы вывести подробную информацию, нажимаем любую из них.
RDS bar
Многофункциональный плагин для анализа сайта. Шустро работает, но помимо анализа платформы сайта имеет множество функций – просмотр количества страниц сайта в поисковой выдаче, количество ссылок и т.д. Переходим по ссылке, выбираем версию под любимый обозреватель и устанавливаем. Перезагружаем браузер и готово.
Статья Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Сегодня мы научимся определять фреймворк и веб-приложение, а так же составим карту архитектуры приложения. На этом «разведка перед боем» будет завершена и следующих статьях приступим непосредственно к тестированию.
Определение фреймворка и веб-приложения.
Каркас (фреймворк) веб-приложений (Web application framework, WAF) — это каркас, предназначенный для создания динамических веб-сайтов, сетевых приложений, сервисов или ресурсов. Он упрощает разработку и избавляет от необходимости написания рутинного кода. Многие каркасы упрощают доступ к базам данных, разработку интерфейса, и также уменьшают дублирование кода.
Существует очень большое количество разных фреймворков. Приводить в этой статье списки фреймворков и их описания не вижу смысла, так как их очень много. Информацию о некоторых из них вы можете получить в
Если тестировщику известен фреймворк тестируемого приложения, и он уже знаком с этим фреймворком (может быть тестировал ранее, или сам разрабатывал на нем приложения), то он получает некоторое преимущество. Как и в случае с веб-сервером, фреймворк может иметь известные уязвимости или неверную конфигурацию, что в конечном счете может привести ко взлому тестируемого сайта.
Информация об используемом фреймворке может быть получена путем анализа некоторых точек веб-приложения, в которых могут находиться маркеры, указывающие на конкретный фреймворк, и анализа структуры приложения в целом. Инструменты для автоматического определения фреймворка находят эти маркеры и сравнивают их с записями в своей базе данных. Для более точного определения обычно сравниваются сразу несколько маркеров.
Рапространенные места для поиска маркеров, указывающих на конкретный фреймворк:
— HTTP-заголоки
— cookies
— исходный код веб-страниц приложения
— специфические файлы и папки
— расширения файлов
— сообщения об ошибках
HTTP-заголовки
Самый простой сбособ определить фреймворк — посмотреть на заголовок X-Powered-By в ответе сервера. По традиции будем использовать netcat.
Рассмотрим следующий запрос:
По заголовку X-Powered-By мы можем предположить, что фреймворк в данном случае — Mono. Однако такой способ определения не всегда позволяет точно определить фреймворк, так как такой заголовок может вообще отсутствовать, если так захотел админ тестируемого приложения, либо намерено показывать неверную информацию.
Например, мы можем получить такой ответ от сервера:
В ходе тестирования стоит обратить внимание и на другие заголовки в ответе сервера. В следующем примере в заголовке X-Powered-By мы можем видеть версию PHP, но в заголовке X-Generator мы снова определили фреймворк Mono:
Определение фреймворка по файлам cookies является более надежным способом. Для каждого фреймворка они специфичны.
По значению заголовка Set-Cookie в ответе сервера мы можем понять, что используется фреймворк CAKEPHP. Хотя и файлы cookie тоже могут быть изменены администратором сервера и приложения, это менее вероятно, чем изменение заголовка X-Powered-By, поэтому данный способ является более надежным.
Этот метод основан на поиске определенных шаблонов в исходном коде веб-страниц. Обычно в исходниках содержится много информации, помогающей определить фреймворк. Одним из распространенных маркеров являются комментарии в исходном коде, которые добавляются в код автоматически и непосредственно ведут к раскрытию версии фреймворка. Так же можно найти специфичные пути к файлам и папкам, присущие конкретному фреймворку или CMS, например пути к файлам .css и .js. Кроме того, названия переменных в скриптах так же могут указывать на определенный фреймворк.
По исходному коду нашего форума мы можем видеть, что на Codeby используется движок XenForo:
Однако, в коде веб-страниц форума можно найти названия директорий, указывающие на WordPress:
Это не должно сбивать с толку, так как форум ссылается на блог, который находится по адресу codeby.net/blogs и сделан на WordPress, то есть это уже другое веб-приложение.
Несколько сложнее определить фреймворк магазина hack.codeby.net. Внешне он очень похож на OpenCart, что вводит в заблуждение. Если присмотреться к исходникам, то можно обнаружить такие названия директорий в путях, как wa-data, wa-content, wa-apps:
Эти названия указывают на CMS Shop-Script, построеной на фреймворке Webasyst.
Директории на сайте можно попробовать сбрутить с помощью словарей, которые содержат известные для разных фреймворков пути, названия файлов и директорий. Данная техника называется Dirbusting. Для брута можно воспользоваться утилитой dirb:
В результате сканирования сайта не найдены специфичные для фреймворков и CMS файлы, но найден файл error_log, который мы можем просмотреть и так же определить используемую CMS по путям в нем:
Как видите, в этом файле есть много чего интересного. Раскрытые пути до корня, файлы и директории, используемые плагины и СУБД. Если покопаться, можно найти еще больше.
Словари для брутфорса можно взять тут — danielmiessler/SecLists или тут — fuzzdb-project/fuzzdb.
Кстати, файл robots.txt так же содержит информацию о возможно используемой CMS:
Расширения файлов
URL может включать в себя расширения файлов. Это может помочь определить используемую технологию. Например owasp.org использует PHP:
Следующий сайт, судя по расширению, использует Python:
Автоматизированные инструменты.
WhatWeb
Один из лучших инструментов для определения используемых технологий на тестируемом сайте. Предустановлен в Kali Linux. Поддерживает множество опций, описывать которые тут нет смысла. Подробно о WhatWeb с примерами запуска можно почитать тут —
WhatWeb определил, что Owasp использует движок MediWiki.
Wappalyzer
Wappalyzer — это плагин для браузеров Firefox и Chrome. На скриншоте результат его работы для codeby:
В ходе этого этапа тестирования лучше использовать несколько разных подходов и инструментов, что бы точнее определить технологию.
Например, несмотря на то, что на форуме Codeby все указывает на движок XenForo, утилита WhatWeb определяет тут WordPress:
Имейте ввиду, что разработчики тестируемого сайта могут намерено запутывать вас, изменяя файлы cookie, HTTP-заголовки, добавляя в исходники пути и названия папок от других платформ, создавая фальшивые страницы (например фальшивую админку) и т.д.
Карта архитектуры приложения.
Одна комплексная и разнородная инфраструктура может включать в себя десятки или даже сотни взаимосвязанных веб-приложений, веб-серверов, систем управления базами данных и так далее. Требуется всего лишь одна уязвимость, что бы подорвать безопасность всей инфраструктуры. Казалось бы даже несущественные проблемы в одном компоненте инфраструктуры могут перерасти в серьезные проблемы для всех остальных частей системы. Поэтому так важно определить все компоненты инфраструктуры, понять, как они взаимодействуют с тестируемым приложением и как они влияют на его безопасность.
В простом случае мы можем иметь один физический сервер, на котором расположены веб-сервер и сервер БД и одно веб-приложение, размещенное на веб-сервере.
Схема может быть такой:
В более сложных случаях инфраструктура может включать балансироващик нагрузки, обратный прокси-сервер, веб-сервер, сервер приложений, сервер БД, сервер LDAP. Все эти элементы могут быть физически разграничены, находиться в разных сетях, иметь межсетевые экраны между ними.
Получение информации об архитектуре приложения может быть сложным делом в случае тестирования методом Black Box. В таком случае пентестер сначала предполагает простую структуру, состоящую из одного сервера. В дальнейшем, при получении дополнительной информации в ходе тестирования, тестировщик ставит под сомнение свое первое предположение и расширяет карту архитектуры.
Нужно задавать себе простые вопросы и стараться ответить на них: существует ли между клиентом и сервером брандмауэр, защищающий веб-сервер? Такая информация может быть получена в результате сканирования портов сервера, анализа ответов от него.
Какой это тип брандмауэра? Есть ли между клиентом и сервером другое физическое устройство? Как оно настроено? Можно ли его обойти?
Обратный прокси-сервер перед веб-сервером можно обнаружить по заголовкам HTTP-ответов. Например непосредственно на обратный прокси указывает заголовок «server: WebSEAL», как на скриншоте ниже:
Если нам известно, какой именно сервер используется в веб-приложении, и известно, как он должен отвечать на некорректные запросы (например ошибкой 404), но при этом нам приходят ответы, отличные от ожидаемых, это так же может указывать на прокси-сервер перед веб-сервером.
Другой пример, когда веб-сервер возвращает набор доступных HTTP-методов, включая TRACE или PUT, но при попытке использования этих методов возвращается ошибка — такое поведение тоже может быть связано с наличием прокси-сервера.
В некоторых случаях прокси-сервер выдает себя таким образом:
Другой элемент инфраструктуры, который можно попытаться обнаружить — это балансировщик нагрузки. Балансировщики используются для распределения нагрузки между несколькими серверами, для оптимизации использования ресурсов, сокращения времени обработки запросов и обеспечения отказоустойчивости.
Он может быть обнаружен, если, например, между всеми серверами единой инфраструктуры не синхронизировано время. Отправив несколько одинаковых запросов на тестируемый адрес и сравнив ответы, можно увидеть различия во времени в заголовке «Date». Это будет означать, что ответы поступают от разных серверов.
Иногда при использовании балансировщика в ответы сервера могут включаться заголовки, явно указывающие на балансировщик, например балансировщик Alteon добавляет в ответы свои cookies:
Несколько сложнее обнаружить серверы баз данных, серверы LDAP или сереверы RADIUS, поскольку для тестировщика они будут скрыты самим приложением. Но нужно попробовать.
Большинство современных веб-приложений используют базы данных. Предположение о их наличии можно сделать, взаимодействуя с приложением и наблюдая за его поведением. Например, если вы можете сохранить в приложении какой-то контент и использовать его спустя какое-то время, то вероятно ваш контент сохранился в БД. Однако версию используемой системы управления базами данных вы узнаете, если только будут обнаружены ошибки в приложении, генерируемые самой СУБД, либо при сканировании открытых портов сервера либо при обнаружении других уязвимостей (как в одном из примеров выше, где в файле error_log можно найти строки с ошибками, явно говорящие о MySQL).
Пример того, как может выглядить карта архитектуры приложения в простом случае, вы можете видеть ниже:
На этом этап сбора информации можно считать завершенным.
Следующим нашим шагом будет тестирование управления конфигурацией инфраструктуры, а именно проверка дефолтных настроек, поиск админок, подбор паролей к ним, поиск бэкапов и тестовых версий сайта, тестирование HTTP-методов и некоторые другие задачи.