Веб-безопасность 200
В информационной безопасности есть казалось бы очевидные вещи. Но они все еще часто встречаются, в том числе в крупных компаниях и государственных организациях. На эту тему эксперт по информационной безопасности и преподаватель Иван Юшкевич провел мастер-класс по безопасности на конференции РИТ++ на платформе hacktory.ai.
Практическую часть МК о том, как накрутить лайки в социальных сетях, украсть криптовалюту и получить доступ к самым большим секретам пользователей, вы можете посмотреть здесь и здесь.
Теоретическую часть пришлось разбить на 3 части. Сегодня рассказ будет о том, что злоумышленник может сделать с найденными файлами и директориями. А также, как используется удаленное выполнение кода (инъекции), в том числе и в SQL.
Поиск файлов и директорий
Одна из самых распространенных проблем, связанная с информационной безопасностью — файлы хранятся в общедоступном виде. Это касается файлов с чувствительной информацией или тех, про которые забыли, например:
Файлы административной панели (/admin.php);
Бэкапы и логи (/log.txt; /back.sql; /backup.tar.gz);
Структура веб проекта;
Файлы систем контроля версий (/.git);
Отладочные файлы (test.php);
Скрытые копии редактируемых файлов (/admin.php-).
Это в принципе может быть всё что угодно. Но это то, что не должно находиться в открытом доступе и может стать угрозой, если файл кто-то обнаружит.
Угрозы могут быть самыми разными. Начиная от того, что человек может получить доступ к интересной информации о сервере, например, php-info. И заканчивая серьезными вещами. Например, если он сможет найти систему контроля версий, то при некоторых особенностях он сможет получить даже доступ к исходному коду самого веб-приложения.
Важно всегда держать в голове:
1. Не полагайтесь на то, что если вы переименовали какой-то ресурс, то подобрать название крайне сложно. Злоумышленник может найти любой ресурс, каким бы замысловатым его название ни было.
2. Никогда не храните бэкапы и файлы конфигураций в общей директории веб-ресурсов. Это очевидно.
3. Иногда дополнительное расширение или новые панели могут создавать собственные файлы и ресурсы. Их тоже необходимо закрывать от публичного доступа.
Ищем файлы и директории
Предположим, есть некоторый ресурс. Мы на него зашли и обнаружили, что есть файл index.html, папки со скриптами и стилями (/css/, /js/) и несколько api-ручек (/api/v1/user/: login, register, info/:id/).
В принципе, ничего интересного. Однако если применить один из инструментов (его мы рассмотрим чуть позже) для поиска файлов и скрытых директорий, можно обнаружить еще 5 интересных адресов.
Рассмотрим каждую из них и подумаем, какую угрозу они в принципе могут нести. Начнем снизу.
Test.php
Test.php, да и любые отладочные файлы могут представлять абсолютно разную функциональность, начиная от простой информации или вывода на страничку «Привет, мир», и заканчивая теми, что помогут злоумышленнику скомпрометировать сервер.
Исследуя веб-ресурс, можно найти поддомены, например, тестовые, и на них поискать скрипты, которые использовались для отладки, тестирования или чего-то еще. С их помощью можно получить доступ к серверу. Довольно много ресурсов были таким образом скомпрометированы.
Например, один из исследователей зарепортил уязвимость, обнаружив на сайте скрипт check.php, и получив с его помощью доступ к информации о сервере. Скорее всего, это было самое тривиальное PHP-info, но все же такие вещи встречаются в реальной жизни.
Рассмотрим следующую папку.
Директория /.git/
/.git/ cодержит изменения и артефакты системы контроля версий. Если её обнаружат, а ее не почистили, не удалили или не закрыли к ней доступ, то можно получить доступ даже к исходным кодам всего проекта. Нужно будет просто восстановить те или иные файлы по их артефактам. Звучит интересно, потому что так возможен доступ к исходному коду файла test.php.
А проанализировав test.php, мы могли бы узнать, например, что он создавал бэкапы с определенным названием в папке /backup/.
Директория /backup/
Ее название говорит само за себя. Там может оказаться что угодно, начиная от исходных данных самого приложения и заканчивая бэкапами БД. И она может нанести непоправимый ущерб, если находится в открытом доступе. В этом случае можно получить доступы к учетным записям, исходным кодам, БД — к чему угодно.
Может показаться, что эта уязвимость прямо из 90-х. Однако нет, она встречается повсеместно. Например, на одном из сайтов — к слову, на сайте Министерства безопасности США — исследователь нашел такую папку и получил доступ к бэкапам.
Директория /access/
Можно найти папку /access/ с говорящим файлом access.log, в котором, собирается какая-то информация (логи). Эти логи иногда могут содержать тоже очень интересную информацию, критичную для веб-ресурса.
Проанализировав access.log, можно найти некоторую папку, явно указывающую, что она принадлежит к административной панели. И если после анализа директории /backup/ у нас доступ к backup БД, то мы знаем, какие пользователи и их пароли нужны, чтобы получить доступ к этой административной панели. То есть из одной уязвимости можно получить доступ к административной панели, даже если у нее странное название, которое нелегко подобрать.
Один исследователь исследовал ресурс мессенджера Slack и нашел файл, или даже ручку под названием debug (тоже вполне говорящее название). С его помощью он получил информацию о том, какие пользователи сейчас находятся в системе, их API адреса, идентификаторы сессий и многое другое Вознаграждение составило $1500.
Директория /api/v1/user/
Не только файлы или папки могут являться угрозой. Иногда проблема может крыться в API-ручках. Поскольку считается правильным делать ручки (названия функций) говорящими, чтобы можно было легко понять, к чему они относятся, то злоумышленник может попробовать поперебирать те или иные составляющие части адреса ручек.
Например, заменить user на admin, чтобы получить доступ к другой ручке, изначально скрытой, и которая может использоваться в той самой административной панели. Если она не требует никакой авторизации и на ней не проверяется контроль доступа, то, совершить с её помощью какие-то противоправные действия.
То есть, хотя изначально сайт состоял всего из 7 адресов, за каждым из них может быть огромное количество скрытой информации, которая может позволить скомпрометировать сервер. Не надейтесь, что переименовав скрипт во время тестирования сайта или переноса данных, вы закроете доступ к данным. Всё это можно найти.
Инструменты
Инструментов для поиска файлов и директорий огромное количество. В другой статье на Хабре подробно рассказано об этом.
В интернете также можно найти подборки словарей с интересными файлами, которые могут быть не удалены с сервера или, скорее всего, существуют на многих серверах.
Как избежать нахождения информации
Как обезопасить наше веб-приложение от того, чтобы кто-то не нашел чувствительную информацию и не использовал ее во вред?
Не хранить чувствительные данные в открытом доступе – самое очевидное решение.
А если мы что-то и храним, например, по каким-то ручкам или в каких-то файлах, то всегда проверять, что эта информация в сети интернет не находится в публичном доступе. Что файлы и ручки прикрыты, может быть, паролями или настройки на веб-сервере не позволяют получить к ним доступ по прямым ссылкам.
Если ставим дополнительные плагины, директории и т.п., то нужно проверять, что они не создают какую-то информацию или сама настройка веб-сервера не раскрывает эту информацию. Например, если был ресурс, настроенный на работу с веб-сервером Apache, а потом эту настройку перенесли на Nginx, то иногда некоторые файлы и директории могут стать станут доступными для сторонних пользователей.
В любом случае, если мы пытаемся что-то скрыть, это всегда, скорее всего, будет найдено. Поэтому при разработке стоит учитывать, что если куда-то у пользователя доступа быть не должно, он туда и ходить не должен.
Перейдем к следующей уязвимости.
Удаленное выполнение кода (инъекции)
Внедрение команд — одна из самых распространенных и уязвленных уязвимостей. Она относится в OWASP к классу А1 под названием инъекция, и на самом деле, неважно, чего — кода или команд. Инъекция может быть абсолютно везде.
Сначала рассмотрим самое простое и тривиальное внедрение команд.
Внедрение команд
Суть уязвимости крайне проста: пользователь передает некоторые данные и они попадают в какую-то строку, которая потом передается на выполнение в оболочку ОС. То есть атака возможна, когда приложение формирует команду к ОС и подставляет в неё небезопасные данные, контролируемые пользователем — GET/POST параметры, HTTP-заголовки, Cookies, и т. д. В результате все данные из не доверенных источников попадают куда бы то ни было без валидации этих данных.
В большинстве случаев это возможно из-за недостаточной валидации входных данных. Если мы куда-то передаем пользовательские данные, никак их не обрабатываем и не проверяем, то, скорее всего, в огромном количестве случаев это приведет к проблемам.
Предотвратить внедрение команд возможно, если принимать меры безопасности на стадиях проектирования и разработки приложения.
Ищем возможность внедрения команд
Уязвимость можно обнаружить, проверяя код. Проверьте, вызываются ли какие-либо методы исполнения команд и принимается ли в качестве данных для этих команд не прошедший валидацию пользовательский ввод.
Рассмотрим хрестоматийный пример. Допустим, у нас есть сайт vuln.com и скрипт /ping.php:
Этот скрипт вызывает утилиту ping, которая отправляет запросы на ip-адрес, а он попадает в скрипт в качество аргумента. Затем скрипт возвращает вывод команды на экран. То есть это некоторый сервис, который что-то пингует. В нормальном случае мы подставляем туда ip-адрес 8.8.8.8:
В результате выполняется команда: ‘ping — с 4’ 8.8.8.8. Как вы можете заметить, в этом коде данные подставляются, как есть. Поэтому нам ничто не мешает вместо 8.8.8.8 (ведь никто не проверяет, что это ip-адрес и что он содержит некорректные управляющие символы) передать при отправке в качестве аргумента значения 123;whoami. “;” будет являться управляющим символом, который свидетельствует о разделении команд.
Тогда сформированная команда будет выглядеть следующим образом:
‘ping — с 4’ 123;whoami
Команда попробует пропинговать адрес 123, и естественно, сделать это не сможет. А так как “;” говорит, что предыдущая команда закончилась и началась следующая, то скрипт выполнит “whoami”. Собственно, в этом и заключается суть уязвимости. Она крайне простая, но в результате данные пользователей попадают в необработанном виде куда-то, где и исполняются.
Может показаться, что это тоже архаизм, и сейчас его найти невозможно. Однако нет. В качестве примера есть такой report.
Рассмотрим его подробнее.
Nextcloud
Существует ПО Nextcloud, которое позволяет создавать свое облако и шарить файлы — такое standalone решение. В 2018 году исследователь нашел в нем уязвимость как раз через внедрения команды.
Посмотрите на 11 строку. Выполняются функция “exec”, команда “unrar” и передаются значения переменных “file” и “dir”. Последние получаются, как показывает этот код, из архива “rar”, который, скорее всего, может как-то передавать пользователей. То есть если исследователь сможет сформировать такой архив “rar”, в котором будет содержаться имя “file с ;”, то при распаковке он сможет выполнить свою стороннюю команду и получить доступ к серверу.
Да, наверное, он не сможет это сделать штатными способами, но есть ПО, которое это сделает за него. А если там содержатся приватные данные или сервер используется как корпоративный dropbox?
Но не только PHP уязвим к данному классу атак. Например, если вы используете какие-то библиотеки, уязвимость может открыться в них.
Image Magick
Набор утилит (ПО) Image Magick отвечает за конвертацию изображения и их обработку. Огромное количество компаний использовала его для обработки изображений.
И также много исследователей нашли уязвимости внутри Image Magick, которые позволяла выполнять произвольные команды.
Рассмотрим, в чем суть данной уязвимости.
ImageMagick в конфигурации использовал некоторые сторонние утилиты, в которые он подставлял строки из файлов или метаданных файла и дальше собирал какие-то данные. В итоге получалось, что в некоторую конфигурацию он подставлял те данные, которые приходили от пользователя, и вызывал те или иные команды, чтобы получить результат.
В итоге пользователь мог передать какую-нибудь картинку (например, аватарку) в формате SVG, внутри которой была ссылка на стороннюю картинку. При конвертации картинки, которая внутри SVG, ImageMagick пытался ее запросить с помощью команды wget, и подставлял адрес той картинки. Что приводило к тому, что можно было поставить двойную кавычку и выполнить стороннюю команду.
Компоненты
Под капотом всех приложений, которые сейчас издаются, кроется огромное количество разнообразных взаимосвязанных компонент и библиотек.
https://engineering.videoblocks.com/web-architecture-101-a3224e126947
Каждая компонента состоит из множества библиотек, даже из таких, которые мы просто скачали и начали использовать. Уязвимости могут крыться как раз в этих библиотеках. Мы можем быть не виноваты, но наше ПО все равно будет уязвимо.
Сами посудите, есть некоторый сервис, который может заниматься абсолютно какой-нибудь ерундой, если смотреть в рамках всего приложения. Однако в нем какой-то компонент использует библиотеку, о существовании которой мы не знаем — и в ней кроется уязвимость. По цепочке это приводит к тому, что всё наше приложение, как бы круто оно ни было написано, становится уязвимым.
Поиск уязвимости blackbox методом
Инъекции могут быть в разных местах команды. Иногда инъекция может выполниться даже после правильного завершения команды.
Существуют разные спецсимволы, которые позволяют разделить команды:; ,&,&&, | , 11 , >. Выбор спецсимвола влияет на условия — параллельное или последовательное выполнение, в зависимости или вне от того, что возвращает первая команда, перенаправление вывода и так далее.
Например, можно внедрить команду “sleep” и посмотреть, увеличится ли время выполнения (базовое время выполнения скрипта ping.php — около 4 секунд). Если поставить символ &, который говорит, что команда должна выполняться параллельно, то сервер вернет ответ за 5 секунд. А если восьмерки обернуть кавычками, то команда завершится неправильно:
В принципе можно сформировать несколько небольших универсальных векторов, используя команды, которые есть почти в любой ОС типа sleep, и проверять вектора на эксплуатацию. Естественно, для эксплуатации той или иной совместимости надо выполнять нормальные команды, например, “sleep”. Они помогут подтвердить, что уязвимость присутствует.
Если можно увидеть ответ от сервера, то станет ясно, от какого пользователя выполнялось приложение или скрипт. Если результат выполнения команды не отображается на странице, речь идет о слепой инъекции. Об исполнении команды можно понять по косвенным признакам:
По времени. Для этого используйте функции sleep<), benchmark) и аналогичные.
Запрос на внешний сервис и разрешение DNS имени. Попробуйте команды ping, nslookup, dig, whois.
В большинстве случаев выполнение произвольных, но безвредных команд вроде sleep, id, hostname, whoami достаточно для подтверждения критичности уязвимости.
Поиск уязвимости при наличии исходных текстов (White Box)
Если у нас есть доступ к коду, почему бы не проанализировать его?
Абсолютно во всех языках программирования есть функции, которые отвечают за вызов командной оболочки или за исполнение стороннего кода. У всех этих функций, что хорошо, имеются говорящие названия: exec, system, start. Поэтому, даже не имея навыков разработки на определенном языке программирования, можно поискать функции с говорящими названиями и, возможно, это будет иметь успех.
Инструменты
При наличии исходных текстов уязвимость можно обнаружить поиском небезопасных функций, специфичных для данного языка программирования. Здесь помогут даже grep или notepad++.
Однако есть довольно много инструментов, которые позволяют автоматизировать такой поиск и исследовать исходный код на наличие тех или иных уязвимостей:
Cppcheck для C++ и C;
Rats, который работает типа «грепалки»;
RIPS – крутой анализатор для PHP (сейчас есть в платном и бесплатном варианте);
Findbugs для языка Java;
Однако обратите внимание, что многие из них выполняют статический анализ и ищут уязвимости, связанные именно с программированием. Например, как используется переменная: не используется вообще или вызывается 3 раза и при этом ни для чего не работает. Многие из этих инструментов заточены только под статический анализ, а не под безопасность. Скорее всего, они найдут какие-то уязвимости, но далеко не все.
Исправление и предотвращение внедрения команд
Весь пользовательский ввод или любые данные, которые приходят из не доверенных источников, мы должны обрабатывать, и эти данные должны проходить валидацию.
Во всех языках программирования и фреймворках есть специальные функции, которые позволяют безопасно выполнять те или иные команды, например, ProcessBuilder в Java. Для построения команды эти функции должны использоваться обязательно.
Но если в какой-то команде есть ряд параметров, из-за которых команда сама по себе может представлять угрозу, то злоумышленнику, понятное дело, достаточно её и нет смысла вызывать стороннюю команду.
Также желательно, чтобы веб-приложение и его компоненты работали по принципу наименьших привилегий. То есть если мы запускаем наше приложение от root, не стоит потом говорить, что жизнь не очень легка. Если даже злоумышленник найдет уязвимость, проэксплуатирует ее и получит доступ к серверу, нужно, чтобы он потратил еще уйму времени и несколько раз просигнализировал о себе. Чтобы мы смогли его обнаружить и закрыть ту или иную дыру.
Посмотрим теперь на другой вид инъекций.
SQL-инъекции
В общем смысле с помощью SQL-инъекции злоумышленник может контролировать запросы, которые приложение выполняет в базе данных. Инъекция возникает, когда приложение подставляет неотфильтрованные данные из запроса пользователя (например GET/POSТ параметры, HTTP заголовки) в запрос к базе данных без какой-либо обработки.
Это позволяет злоумышленнику внедрить свой стиль команды, изменить логику SQL запроса и таким образом получить доступ к чувствительным данным, хранящимся в БД, например: данным пользователей, платежным данным, сохраненным паролям, если они лежат не в зашифрованном виде.
В ряде случаев злоумышленник может не только получить данные, но изменить и удалить их, а также — более редкий кейс, но тоже бывает — выполнить код на уровне ОС. Здесь злоумышленник может развить атаку и скомпрометировать весь сервер или другие объекты инфраструктуры.
Как выглядит уязвимость?
Представим, что у нас есть таблица “Users”для двух пользователей (Боба и Алисы), а также скрипт, который получает от клиента идентификатор userid и выводит имя пользователя по этому значению:
Скрипт возвращает «Bob», потому что у Боба userid=1. И вроде бы код хорош, но это не так, так как он уязвим по SQL-инъекции. Итоговый SQL запрос имеет следующий вид:
Так как 1 подставляется как есть, то можно передать туда какой-то текст. Если коде нет ни санитизации, ни фильтрации пользовательского ввода, то значение GET-параметра id попадет в $sqlQuery как есть. Для эксплуатации злоумышленник должен изменить значение параметра id так, чтобы он содержал вредоносный SQL-код для исполнения.
Это был условно практический пример, теперь перейдем к практическому. Представим стандартную панель входа в сервис, куда нужно ввести имя пользователя и пароль. И есть скрипт аутентификации и таблица с пользователями, у которых есть логины и пароли:
После получения логин и пароль вставляются как есть в SQL запрос к БД. Если запрос будет валидным, то он исполнится, как и должен был. Но если попытаться найти Боба с паролем куча единиц, то получим ошибку, потому что такого пароля нет. И это место для SQL-инъекции.
Как можно использовать эту уязвимость? Например, отправить в качестве логина admin’ и знак комментария:
Благодаря одинарной кавычке запрос закроется раньше, чем это предполагалось. Двойной дефис в MySQL является комментарием, то есть эту часть запроса СУБД при исполнении просто отбросит, а там была проверка пароля. Запрос выполнится успешно и приложение нас пропустит.
Некоторые разновидности SQL-инъекций
UNION BASED
Способ основан на использовании оператора UNION. Предположим, в приложении присутствует две таблицы — статьи (Articles) и пользователи (Users). SQL-инъекция присутствует в запросе к таблице Articles, при этом необходимо извлечь данные из таблицы Users. В этом случае поможет применение SQL-оператора UNION, который объединяет два запроса в один. Важное правило — количество колонок в обоих запросах должно совпадать.
Как это происходит на практике. Представим, что первый запрос содержит 4 столбца. Попытка UNION с запросом из трех столбцов будет неудачна, поскольку БД вернет ошибку. Если Debug Mode включен, мы можем эту ошибку даже увидеть. Но объединение четырех колонок слева и четырех справа будет успешным.
Если колонок в таблице пользователей меньше, можно добавить их с помощью констант, написав 1, 2, 3 и т.д. Или же придётся из таблицы пользователей выбирать нужные колонки.
ERROR BASED
Этот способ основан на эксплуатации того, что ошибка в SQL-запросе попадает в содержимое HTML-страницы. То есть мы видим ошибку, которая происходит в нашей СУБД.
В MySQL существует функция extroctvolue(), которая ожидает в качестве аргумента данные в XML представлении, иначе она выбрасывает ошибку. Нетрудно догадаться, что этим можно воспользоваться. Если передать туда невалидные данные, она выполнит запрос и можно будет увидеть версию системы, на которой крутится СУБД. Или пользователя, от имени которого выполняется запрос в СУБД.
TIME BASED
Наверное, это самый интересный способ, который основан на времени исполнения запроса. Он применяется, если инъекция «слепая» и на страницу ничего не выводится. То есть можно только по косвенным признакам понять, что там существует SQL-инъекция. Для этого можно воспользоваться функциями:
sleep() — запрос выполняется долго, как и при использовании обычной консоль-утилиты sleep в Bash;
benchmark() — что-то выполняет очень много раз, например, может считать миллион раз MD5 от 1.
Также можно использовать конструкции вида:
IF(expr1,expr2,expr3) — ЕСЛИ «ехрг1» ИСТИНА, то выполни «ехрг2», ИНАЧЕ «ехргЗ»
Таким образом можно подбирать логин пользователя по букве. Например, если поставить первую букву «А» и запрос не уснет на 10 с, то значит, буква не «А», и т.д., пока запрос не уснет. Как только мы угадаем первую букву пользователя, запрос подвиснет на 10 с.
При этом такую рутину можно автоматизировать утилитой SQLMAP.
Инструменты
SQLMAP поддерживает большинство техник эксплуатации и умеет обходить WAF. У нее автоматическая выгрузка дампа БД, если она найдет уязвимые места SQL-инъекции. Обычно мы должны ей указать какой-то параметр, который по нашему мнению может быть уязвим.
С ее помощью можно выполнять команды (RCE), и она может работать с запросом из Burp. И при этом не нужно вручную составлять все атрибуты командной строки.
Исправление и предотвращение SQL-инъекций
Мы можем использовать:
Параметризированные запросы, когда запросы готовятся заранее, и мы им потом «скармливаем» наши данные;
ORM — она сделает всё за нас, и нам не нужно будет беспокоиться;
Query-билдеры, то есть составители запросов, которые нам предоставляют фреймворки. PHP-фреймворки этим богаты, такие как Symfony, Laravel и Spring. На выходе получается производительность обычных запросов.
В следующей статье рассказ будет про Cross Site Request forgery (CSRF), XSS (Cross Site Scripting или межсайтовый скриптинг) и XXE: XML External Entity Processing.
FrontendConf 2021 — это два дня интересных докладов, ярких встреч и много-много нетворкинга. Расписание. Билеты. Доклады.
Встречаемся 11-12 октября в Москве!
Сканер каталогов веб-сайтов
Сканируйте сайт на наличие технических ошибок и получите список задач с подробными инструкциями по их устранению.
Сканирование каталогов веб-сайтов и конфиденциальных файлов — одна из важных задач при тестировании вашего сайта. Сканирование необходимо для обнаружения конфиденциальных каталогов или поиска скрытых каталогов на веб-сайте. С помощью нашего инструмента вы можете сканировать и находить такие файлы, как PHP Robots.txt и другую информацию;
Если мошенники просканируют ваш сайт и найдут загруженные файлы, они могут загрузить на ваш сайт вредоносный код. Если на вашем сайте есть скрытые файлы, о которых вы не знаете, вы можете стать легкой добычей для киберпреступников. Они могут получить доступ к конфиденциальной информации и использовать ее в незаконных целях.
По этой причине очень важно знать, как найти скрытые файлы на веб-сайте и в каталогах.
Мы объясним, как просмотреть каталог веб-сайта со сканером. Это простой и бесплатный способ получить полный список скрытых каталогов, которые могут стать уязвимостью для вашего сайта.
Что такое сканер каталогов веб-сайтов?
Как найти скрытые страницы на сайте?
Отличная идея — просканировать веб-сайт на наличие скрытых каталогов и файлов (скрытых — это каталоги и файлы, на которые нет ссылок и о которых знает только владелец сайта!) с помощью онлайн-сканера каталогов веб-сайтов. Как минимум, вы можете узнать что-то новое о сайте, просмотреть структуру каталогов сайта, а иногда просто выпадает суперприз — архив сайта или базы данных, резервная копия конфиденциальных документов и т.д.
Что такое каталог сайта?
Это основная папка, в которой хранятся все каталоги и файлы сайта. Именно в эту папку загружается архив с файлами сайта и базой данных. Если вы поместите файлы сайта не в ту папку, вместо сайта будет отображаться ошибка 403.
Средство поиска каталогов помогает найти указанный каталог в системе для файлов, содержащих сообщения (например, в формате XML или JSON). Когда сообщения прочитаны, они могут быть переданы в основной конвейер сообщений, где на них может воздействовать весь спектр фильтров обработки сообщений.
Средство просмотра файлов веб-сайта обычно используется в тех случаях, когда внешнее приложение сбрасывает файлы (возможно, по FTP) в файловую систему, чтобы их можно было проверить, изменить и, возможно, перенаправить через HTTP или JMS.
Это помогает профессионально сканировать каталог веб-сайтов. Особенно, когда вы запускаете тесты, ориентированные на безопасность, и просматриваете каталог веб-сайта, он закрывает некоторые дыры, которые не покрываются классическими веб-сканерами уязвимостей. Он ищет определенные веб-объекты, но не ищет уязвимости и не ищет веб-контент, который может быть уязвимым.
Что могут быть «скрытые файлы»?
В общем случае это могут быть следующие каталоги:
- Файлы конфигурации проекта, которые создает интегрированная среда разработки (IDE).
- Специальная конфигурация и файлы конфигурации для данного проекта или технологии.
Вы должны регулярно сканировать сайты, чтобы увидеть, не передаются ли какие-либо конфиденциальные и проприетарные файлы. Просмотр каталога веб-сайта — это действительно простое правило, которое поможет защитить вас от хакерских атак и сохранить ваши файлы в полной безопасности.
Различные типы сканеров каталогов веб-сайтов
Как просмотреть каталог сайта? Сканеры работают по разным принципам. Есть инструменты для сканирования вашего сайта (и это авторизованные инструменты), а есть и хакерские. С этической точки зрения вы не можете сканировать каталоги других сайтов. Юридически это считается взломом и мошенничеством.
Посмотрим, по какому принципу будут работать разные типы сканеров каталогов.
- Словарь сканировать сайт на наличие файлов .
- Сканирование чистым сканером.
- Сканирование веб-сканером.
- Сканирование с реализацией библиотеки запросов Python.
Как видите, есть несколько способов сканирования и поиска скрытых файлов на вашем сайте. Вы можете выбрать наиболее удобный для вас или воспользоваться нашим простым инструментом Website Directory Scanner. С помощью нашего бесплатного сканера вы легко сможете просмотреть все директории сайта и найти все скрытые файлы, которые могут стать вашими уязвимыми местами.
Руководство по эффективному использованию нашего сканера каталогов
Если вы хотите найти скрытые страницы на веб-сайте и знаете, как просмотреть список каталогов веб-сайтов, используйте наш инструмент сканера каталогов веб-сайтов.
Это достаточно просто:
-
Введите URL-адрес веб-сайта, который вы хотите отсканировать, в заполнитель ниже и начните бесплатную пробную версию. Это супербыстро и абсолютно бесплатно;
Вот и все. Так просто выглядит процесс поиска в каталоге веб-сайтов.
Специальные функции нашего сканера каталогов веб-сайтов
Что ж, давайте кратко рассмотрим основные функции нашего сканера каталогов веб-сайтов.
Как только сканирование остановится, вы увидите оценку вашего сайта, количество просканированных страниц и количество страниц в индексе Google. Например, мы просканировали наш сайт sitechecker.pro. Результаты сканирования вы можете увидеть на скриншоте ниже.
Прокручивая ниже, вы можете увидеть проблемы на уровне сайта. Если на вашем веб-сайте есть скрытые файлы, которые может сканировать наш инструмент, вы также увидите их в этом списке.
Следующей особенностью нашего инструмента является то, что вы можете просматривать ошибки, разделенные на три категории. Это критические ошибки, которые говорят вам о важности их исправления как можно скорее.
Это предупреждения, информирующие владельца сайта о том, что можно улучшить. А второстепенные — это уведомления, которые не являются важными предупреждениями.
Так вы можете просмотреть все файлы в каталоге веб-сайта. Это очень просто и не займет у вас много времени. Кроме того, это позволит избежать неприятных ситуаций с доступом к вашему сайту.
10 инструментов, которые помогут найти удалённую страницу или сайт
Если, открыв нужную страницу, вы видите ошибку или сообщение о том, что её больше нет, ещё не всё потеряно. Мы собрали сервисы, которые сохраняют копии общедоступных страниц и даже целых сайтов. Возможно, в одном из них вы найдёте весь пропавший контент.
Поисковые системы
Поисковики автоматически помещают копии найденных веб‑страниц в специальный облачный резервуар — кеш. Система часто обновляет данные: каждая новая копия перезаписывает предыдущую. Поэтому в кеше отображаются хоть и не актуальные, но, как правило, довольно свежие версии страниц.
1. Кеш Google
Чтобы открыть копию страницы в кеше Google, сначала найдите ссылку на эту страницу в поисковике с помощью ключевых слов. Затем кликните на стрелку рядом с результатом поиска и выберите «Сохранённая копия».
Есть и альтернативный способ. Введите в браузерную строку следующий URL: http://webcache.googleusercontent.com/search?q=cache:lifehacker.ru . Замените lifehacker.ru на адрес нужной страницы и нажмите Enter.
2. Кеш «Яндекса»
Введите в поисковую строку адрес страницы или соответствующие ей ключевые слова. После этого кликните по стрелке рядом с результатом поиска и выберите «Сохранённая копия».
3. Кеш Bing
В поисковике Microsoft тоже можно просматривать резервные копии. Наберите в строке поиска адрес нужной страницы или соответствующие ей ключевые слова. Нажмите на стрелку рядом с результатом поиска и выберите «Кешировано».
4. Кеш Yahoo
Если вышеупомянутые поисковики вам не помогут, проверьте кеш Yahoo. Хоть эта система не очень известна в Рунете, она тоже сохраняет копии русскоязычных страниц. Процесс почти такой же, как в других поисковиках. Введите в строке Yahoo адрес страницы или ключевые слова. Затем кликните по стрелке рядом с найденным ресурсом и выберите Cached.
Специальные архивные сервисы
Указав адрес нужной веб‑страницы в любом из этих сервисов, вы можете увидеть одну или даже несколько её архивных копий, сохранённых в разное время. Таким образом вы можете просмотреть, как менялось содержимое той или иной страницы. В то же время архивные сервисы создают новые копии гораздо реже, чем поисковики, из‑за чего зачастую содержат устаревшие данные.
Чтобы проверить наличие копий в одном из этих архивов, перейдите на его сайт. Введите URL нужной страницы в текстовое поле и нажмите на кнопку поиска.
1. Wayback Machine (Web Archive)
Сервис Wayback Machine, также известный как Web Archive, является частью проекта Internet Archive. Здесь хранятся копии веб‑страниц, книг, изображений, видеофайлов и другого контента, опубликованного на открытых интернет‑ресурсах. Таким образом основатели проекта хотят сберечь культурное наследие цифровой среды.
2. Arhive.Today
Arhive.Today — аналог предыдущего сервиса. Но в его базе явно меньше ресурсов, чем у Wayback Machine. Да и отображаются сохранённые версии не всегда корректно. Зато Arhive.Today может выручить, если вдруг в Wayback Machine не окажется копий необходимой вам страницы.
3. WebCite
Ещё один архивный сервис, но довольно нишевый. В базе WebCite преобладают научные и публицистические статьи. Если вдруг вы процитируете чей‑нибудь текст, а потом обнаружите, что первоисточник исчез, можете поискать его резервные копии на этом ресурсе.
Другие полезные инструменты
Каждый из этих плагинов и сервисов позволяет искать старые копии страниц в нескольких источниках.
1. CachedView
Сервис CachedView ищет копии в базе данных Wayback Machine или кеше Google — на выбор пользователя.
2. CachedPage
Альтернатива CachedView. Выполняет поиск резервных копий по хранилищам Wayback Machine, Google и WebCite.
Как найти архивные копии сайтов интернета или машина времени для сайтов
Существует настоящая, реальная машина времени, в которой можно ненадолго вернуться в прошлое и увидеть, например, как выглядел тот или иной сайт несколько лет назад. Думаете, никому не нужны копии сайтов многолетней давности? Ошибаетесь! Для очень многих людей сервис по архивированию информации весьма полезен.
Во-первых, это просто интересно! Из чистого любопытства и от избытка свободного времени можно посмотреть, как выглядел любимый, популярный ресурс на заре его рождения.
Во-вторых, далеко не все веб-мастера ведут свои архивы. Знать место, где можно найти информацию, которая была на сайте в какой-то момент, а потом пропала, не просто полезно, а очень важно.
В-третьих, само по себе сравнение является важнейшим методом анализа, который позволяет оценить ход и результаты нашей деятельности. Кстати, при проведении анализа веб-ресурса очень эффективно использовать ряд методов сравнения.
Поэтому наличие уникальнейшего архива веб-страниц интернета позволяет нам получить доступ к огромному количеству аудио-, видео- и текстовых материалов. По утверждению разработчиков, «интернет-архив» хранит больше материалов, чем любая библиотека мира. Мы попали в правильное место!
Что нужно, чтобы найти копии сайтов интернета?
Для того, чтобы отправиться в прошлое, нужно перейти на сайт https://web-beta.archive.org/ и воспользоваться поисковой строкой.
Простой поиск в архиве сохраненных сайтов выдает нам ссылки на все сохраненные копии запрашиваемой страницы.
Из этого скриншота видно, что сайт http://pikabu.ru был создан в 2009 году. Переключаясь на нужный нам год, можно увидеть даты, выделенные кружочками, это и есть даты сохранения копии сайта. Например, в 2009 году, пока можно будет увидеть только две копии от 28 и 29 июня.
Конечно, это потрясающий ресурс! Ведь здесь индексируются и архивируются все сайты интернета! Это не только скриншоты… Имея в руках такой инструмент, можно восстановить массу потерянной со временем информации.
Надо заметить, что, безусловно все восстановить однозначно не получится, так как если на страницах сайта используются элементы Java Script, или скрипты или графика взяты со стороннего сервера, то на восстановление такой информации рассчитывать не придется. Поэтому к сохранению данных своего сайта нужно относиться с особенным вниманием, несмотря ни на что.