- 7
- 2
- 26 Окт 2025
Приветствую всех читателей! В этой статье подробно расскажу о том как правильно искать большую часть уязвимостей сайта и как их использовать.
Во первых нужно понять что такое уязвимости. В компьютерной безопасности термин «уязвимость» используется для обозначения недостатка в системе, используя который, можно намеренно нарушить её целостность и вызвать неправильную работу. Это означает, что если мы найдём её, то у нас получится совершать какие либо действия, которые непредусмотрены системой. Приведу пример: на каком либо сайте, при вводе данных, можно прописать код, который будет произведен в серверной части. Таким образом у нас появилась бы возможность полностью управлять сервером или его частью.
Существует множество типов уязвимостей в веб-ресурсах. Рассмотрим каждый из них:
Как найти уязвимости в интернет ресурсе?
Основные этапы поиска уязвимостей:
Сбор информации (Information Gathering)
Анализ DNS-записей, IP-адресов, доменных имен
Сканирование портов (например, с помощью Nmap)
Поиск публичных уязвимостей, утечек данных, информации о сервере и приложении
Анализ уязвимостей (Vulnerability Scanning)
Используйте автоматические инструменты для поиска известных уязвимостей:
Nessus, OpenVAS, Nikto, Burp Suite, Acunetix и др.
Тестирование безопасности (Manual Testing)
Проверка входных данных на внедрение (SQL-инъекции, XSS)
Анализ настроек сервера и приложения
Отслеживание неправильных настроек безопасности (например, слабых паролей, открытых директорий)
Возьмем в пример ресурс https://wotpack.ru/:
Используемые инструменты: Nmap, Nikto, любой браузер, консоль SSH, консоль Kali Linux
Пункт 1.
- Узнаем публичный IPv4 адрес сайта с помощью команды
Итак публичный IP - 8.6.112.0
Пункт 2.
- Смотрим порты с помощью утилиты Nmap -
Мы видим что открыты 4 TCP порта для http, https, http-proxy и https-alt
Пункт 2.
- Теперь ищем известные уязвимости командой -
Разберём команду: nikto - сама утилита, -h - указывает целевой веб сервер, https://wotpack.ru - адрес сервера, -ssl - говорит Nikto использовать HTTPS при подключении к целевому серверу, -output report.html -Format html - формат вывода результат (HTML).
Пункт 3.
- Соберём всю найденную информацию в одно целое:
Целевой IPv4 адрес: 104.26.9.30
Список уязвимостей:
Пункт 4.
- Теперь мы можем использовать множество инструментов для получения доступа к серверу. Самым лучшим вариантом, основываясь на найденных уязвимостях является MIME атака (подмена расширения имени файла).
Спасибо за прочтение и уделённое время!
Во первых нужно понять что такое уязвимости. В компьютерной безопасности термин «уязвимость» используется для обозначения недостатка в системе, используя который, можно намеренно нарушить её целостность и вызвать неправильную работу. Это означает, что если мы найдём её, то у нас получится совершать какие либо действия, которые непредусмотрены системой. Приведу пример: на каком либо сайте, при вводе данных, можно прописать код, который будет произведен в серверной части. Таким образом у нас появилась бы возможность полностью управлять сервером или его частью.
Существует множество типов уязвимостей в веб-ресурсах. Рассмотрим каждый из них:
- SQL-инъекции (SQL Injection)
Позволяют злоумышленнику выполнять произвольные SQL-запросы к базе данных через уязвимые формы или параметры URL, что может привести к утечке, изменению или удалению данных.
Основные моменты по SQL-инъекциям:- Как происходит: злоумышленник вводит в поля формы, URL или другие точки входа специальные SQL-выражения, которые сервер неправильно обрабатывает и выполняет.
- Цели атаки: получить доступ к конфиденциальной информации, изменить или удалить данные, получить контроль над базой данных или сервером.
- Примеры:
- Ввод ' OR '1'='1 в поле логина позволяет авторизоваться без правильных данных.
- Ввод '; DROP TABLE users; -- удаляет таблицу users.
- Защита от SQL-инъекций:
- Использовать подготовленные выражения (prepared statements).
- Фильтровать и валидировать пользовательский ввод.
- Использовать ORM (Object-Relational Mapping) системы.
- Ограничивать права пользователя базы данных.
- Регулярно обновлять программное обеспечение.
- Кросс-сайтовый скриптинг (Cross-Site Scripting, XSS)
Позволяет злоумышленнику внедрять вредоносные скрипты в веб-страницы, которые затем выполняются у других пользователей, что может привести к краже данных, сессий или к другим атакам.
Основные типы XSS:- Stored XSS (хранимый) — вредоносный скрипт сохраняется на сервере (например, в базе данных, комментариях или профилях пользователей) и затем отображается другим пользователям.
- Reflected XSS (отражённый) — вредоносный скрипт вставляется в URL или форму, и сервер отражает его обратно в ответ, когда пользователь переходит по ссылке.
- DOM-based XSS — уязвимость возникает в клиентском скрипте, когда вредоносный код попадает в DOM (Document Object Model) через уязвимости в JavaScript.
Для защиты от XSS необходимо:- Правильная валидация и фильтрация пользовательского ввода.
- Использование безопасных методов вставки данных в HTML (например, избегать вставки raw-данных без обработки).
- Внедрение Content Security Policy (CSP) — политики безопасности контента.
- Обновление и патчинг используемых библиотек и платформ.
- Последствия XSS могут быть очень серьёзными: кража личных данных, учетных записей, финансовых данных, а также возможность управлять сессиями пользователей и распространять вредоносное ПО.
- Межсайтовая подделка запросов (Cross-Site Request Forgery, CSRF)
Атака, при которой злоумышленник заставляет пользователя выполнить нежелательное действие на доверенном сайте, в который он залогинен.
Вот как работает CSRF:- Пользователь входит в доверенный сайт и получает активную сессию.
- Злоумышленник создает вредоносный сайт или страницу, которая содержит вредоносный код (например, HTML-форму или скрипт).
- Пользователь посещает этот вредоносный сайт, будучи авторизованным на доверенном ресурсе.
- Вредоносный код посылает запрос на доверенный сайт от имени пользователя, используя его сессионные данные (например, куки).
- Доверенный сайт воспринимает запрос как легитимный и выполняет нежелательное действие (например, перевод денег, изменение настроек аккаунта).
Чтобы защититься от CSRF, применяют различные меры:- Использование уникальных токенов (CSRF-токенов), которые проверяются на сервере при выполнении чувствительных операций.
- Проверка заголовков Origin или Referer.
- Использование методов HTTP, менее уязвимых к CSRF (например, POST вместо GET).
- Ограничение действия сессий по IP или по времени.
- Уязвимости в аутентификации и управлении сессиями
Включают слабые пароли, неправильную реализацию сессионных токенов, их перехват или использование устаревших методов аутентификации.
Рассмотрим основные типы таких уязвимостей:- Перехват сессионных cookies (Session Hijacking)
Злоумышленник может похитить идентификатор сессии, например, через перехват сетевого трафика или внедрение вредоносного кода, и использовать его для доступа к аккаунту жертвы. - Слабые или предсказуемые идентификаторы сессий
Использование легко угадываемых или предсказуемых идентификаторов сессий позволяет злоумышленнику угадать или вычислить активную сессию другого пользователя. - Переприсвоение сессий (Session Fixation)
Атака, при которой злоумышленник заставляет жертву использовать определённый идентификатор сессии, а затем использует его для доступа к аккаунту после аутентификации. - Отсутствие или неправильное управление временем жизни сессии
Если сессии не истекают своевременно или не требуют повторной аутентификации, это увеличивает риск несанкционированного доступа. - Недостаточная защита при передаче данных
Передача сессионных данных по незашищённым протоколам (например, HTTP вместо HTTPS) позволяет перехватить идентификатор сессии. - Повторное использование или длительное хранение сессионных данных
Если сессии остаются активными долгое время или не очищаются после выхода, злоумышленники могут использовать старые или украденные сессии. - Отсутствие защиты от атак типа Cross-Site Request Forgery (CSRF)
Без защиты злоумышленник может заставить браузер жертвы выполнить нежелательные действия, используя активную сессию. - Недостаточная проверка аутентификации и авторизации
Отсутствие многофакторной аутентификации или неправильная реализация уровней доступа увеличивают риск компрометации.
- Перехват сессионных cookies (Session Hijacking)
- Обнаружение и использование уязвимостей в файлах и каталогах
Недостатки в настройках сервера или неправильное управление файлами, позволяющие доступ к конфиденциальным файлам или выполнение произвольного кода.- Анализ прав доступа и разрешений
Проверка настроек разрешений в файлах и каталогах (например, в Linux — права доступа chmod, владельцы файла). Неправильные разрешения могут позволить злоумышленникам читать, писать или выполнять файлы, что создаёт уязвимость. - Поиск уязвимых скриптов и конфигурационных файлов
Анализ содержимого файлов конфигурации и скриптов на наличие ошибок, таких как использование слабых паролей, открытые интерфейсы или отключённые меры безопасности. - Использование автоматизированных сканеров
Инструменты вроде Nessus, OpenVAS, или специально настроенные скрипты позволяют обнаружить потенциальные уязвимости в файлах и каталогах. - Анализ журналов и следов
Исследование логов доступа и изменений файлов для выявления подозрительных действий. - Эксплуатация неправильно настроенных разрешений
Злоумышленник может получить доступ к файлам с ослабленными правами, изменить их или выполнить вредоносный код. - Использование уязвимых скриптов или конфигурационных файлов
Например, скрипты с уязвимыми параметрами могут позволить выполнение произвольного кода или получение доступа к системе. - Подмена или модификация файлов
Вредоносные пользователи могут замещать или изменять файлы для получения контроля или внедрения вредоносных элементов. - Использование уязвимостей для получения доступа к скрытым каталогам или файлам
Например, использование уязвимостей в веб-приложениях для доступа к каталогам, которые обычно не доступны.
- Анализ прав доступа и разрешений
- Безопасность API
Уязвимости в интерфейсах программирования приложений, такие как недостаточная проверка авторизации, что позволяет злоумышленникам получать доступ к данным или выполнять нежелательные операции.
Основные аспекты безопасности API включают:- Аутентификация и авторизация:
- Использование токенов (например, OAuth 2.0, JWT) для подтверждения личности пользователей и приложений.
- Ограничение доступа к определенным ресурсам на основе прав пользователя.
- Шифрование данных:
- Передача данных по защищенным каналам (HTTPS) с использованием SSL/TLS.
- Шифрование конфиденциальных данных в базе данных и при хранении.
- Ограничение доступа и контроль лимитов:
- Установка лимитов по количеству запросов (Rate limiting) для предотвращения DDoS-атак.
- IP-фильтрация и блокировка подозрительных запросов.
- Валидация и фильтрация данных:
- Проверка входных данных на стороне сервера для предотвращения SQL-инъекций, XSS и других уязвимостей.
- Логирование и мониторинг:
- Ведение журналов запросов для анализа подозрительной активности.
- Настройка систем оповещения о возможных угрозах.
- Обновление и патчи:
- Регулярное обновление программного обеспечения и устранение известных уязвимостей.
- Использование API Gateway:
- Централизованный контроль доступа, аутентификация и мониторинг трафика.
- Аутентификация и авторизация:
- Недостаточная защита от атак типа "отказ в обслуживании" (DoS/DDoS)
Атаки, направленные на перегрузку сервера большим количеством запросов, что приводит к недоступности сайта.
Причины недостаточной защиты:- Отсутствие или неправильная настройка межсетевых экранов (файрволов) и систем обнаружения вторжений.
- Недостаточная пропускная способность каналов связи.
- Отсутствие или неправильно настроенные системы защиты от DDoS-атак, такие как системы фильтрации трафика, CDN или облачные решения.
- Недостаточное масштабирование инфраструктуры для обработки пиковых нагрузок.
- Отсутствие политики реагирования на инциденты и планов по защите от DDoS.
- Последствия недостаточной защиты:
- Перебои или полная недоступность сайта или сервиса.
- Потеря доверия пользователей и клиентов.
- Финансовые убытки из-за простоев и возможных штрафных санкций.
- Возможное использование ресурса для других целей злоумышленниками, например, для распространения вредоносного ПО или дальнейших атак.
- Как повысить защиту:
- Использование систем фильтрации трафика и мониторинга.
- Внедрение решений CDN (Content Delivery Network), которые могут распределять нагрузку.
- Настройка правил брандмауэров и систем обнаружения аномалий.
- Подключение к облачным сервисам защиты от DDoS-атак, таких как Cloudflare, Akamai, AWS Shield.
- Регулярное тестирование и обновление мер безопасности.
- Создание планов реагирования на инциденты.
- Уязвимости в конфигурации сервера и приложений
Неправильные настройки, оставленные по умолчанию, которые могут быть использованы злоумышленниками для получения несанкционированного доступа.
Основные типы уязвимостей включают:- Некорректные настройки безопасности:
- Открытые порты, которые не используются.
- Включённые ненужные сервисы.
- Использование слабых или стандартных паролей.
- Открытые доступы к административным панелям.
- Отсутствие обновлений и патчей:
- Использование устаревших версий программного обеспечения, содержащих известные уязвимости.
- Неправильная настройка прав доступа:
- Избыточные привилегии у пользователей и приложений.
- Недостаточно строгие правила доступа к файлам и директориям.
- Неправильная конфигурация приложений:
- Включённый режим отладки в продуктивной среде.
- Недостаточная защита от SQL-инъекций, XSS и других видов атак.
- Недостаточная защита данных:
- Передача данных без шифрования.
- Недостаточная защита конфиденциальных данных в конфигурационных файлах.
- Ошибки в настройке журналирования и мониторинга:
- Отсутствие или неправильная настройка логирования, что усложняет обнаружение атак.
- Некорректные настройки безопасности:
- Инъекции команд (Command Injection)
Внедрение вредоносных команд в систему через уязвимости в обработке пользовательских данных.
Как работает инъекция команд?
Злоумышленник вводит специальные команды или конструкции, которые добавляются к допустимому вводу и интерпретируются системой как команды. Например, если приложение формирует команду оболочки на основе пользовательского ввода и не фильтрует его, злоумышленник может добавить команды, которые будут выполнены на сервере или клиентской машине.
Пример
Допустим, есть веб-форма, которая принимает имя пользователя и использует его для выполнения системной команды:
ping -c 4 <имя_пользователя>
Если ввод не проверяется, злоумышленник может ввести:
127.0.0.1; rm -rf /
и команда станет:
ping -c 4 127.0.0.1; rm -rf /
что приведет к удалению файлов.
Последствия- Выполнение произвольных команд на целевой системе.
- Получение доступа к конфиденциальным данным.
- Нарушение работы системы или сервиса.
- Полное захватывание контроля над сервером.
- Уязвимости в сторонних компонентах и библиотеках
Использование устаревших или уязвимых сторонних модулей, которые могут стать точкой входа для атак.
Основные аспекты уязвимостей в сторонних компонентах и библиотеках:- Устаревшие версии: использование устаревших или неподдерживаемых версий библиотек, в которых известны уязвимости.
- Неправильная конфигурация: неправильные настройки библиотек, которые могут открывать дополнительные точки входа злоумышленникам.
- Баги и ошибки в коде: наличие ошибок или недостатков в сторонних компонентах, которые могут быть использованы для атак.
- Неактуальные компоненты: использование компонентов с известными уязвимостями, для которых уже выпущены исправления, но они не применены.
- Встроенные уязвимости: некоторые библиотеки могут содержать уязвимости по умолчанию, например, слабые пароли или уязвимости в аутентификации.
- Зависимости и цепочки зависимостей: уязвимости могут распространяться через цепочки зависимостей, когда у сторонней библиотеки есть свои сторонние компоненты.
- Почему это важно?
- Безопасность: сторонние библиотеки могут стать вектором атаки, позволяя злоумышленникам проникнуть в систему.
- Надёжность: уязвимости могут приводить к сбоям или потере данных.
- Соответствие требованиям: многие стандарты безопасности требуют регулярного обновления и аудита используемых компонентов.
- Недостатки в шифровании и хранении данных
Неправильное шифрование или хранение конфиденциальных данных, таких как пароли и личная информация.- Уязвимость к атакам
Некоторые алгоритмы шифрования со временем могут стать уязвимыми для взлома (например, из-за появления квантовых компьютеров или слабых ключей). Также ошибки в реализации могут привести к компрометации данных. - Управление ключами
Безопасное хранение и управление криптографическими ключами — одна из самых сложных задач. Потеря ключа делает данные недоступными, а его компрометация — ставит под угрозу всю систему. - Производительность
Шифрование и расшифровка требуют вычислительных ресурсов, что может замедлить работу систем, особенно при обработке больших объемов данных или в реальном времени. - Комплексность реализации
Правильное внедрение шифрования — сложная задача, требующая высокой квалификации. Ошибки в реализации могут привести к уязвимостям. - Общие риски хранения данных
Даже зашифрованные данные могут быть украдены или похищены из-за уязвимостей в системах хранения или в процессе передачи. Если ключи хранятся неправильно, это увеличивает риск компрометации. - Законодательные ограничения
В некоторых странах использование сильного шифрования регулируется законом, что может ограничивать его применение или требовать специальных разрешений. - Обновление и управление
Обновление алгоритмов и управление ключами требуют постоянных усилий для поддержания безопасности системы.
- Уязвимость к атакам
Как найти уязвимости в интернет ресурсе?
Основные этапы поиска уязвимостей:
Сбор информации (Information Gathering)
Анализ DNS-записей, IP-адресов, доменных имен
Сканирование портов (например, с помощью Nmap)
Поиск публичных уязвимостей, утечек данных, информации о сервере и приложении
Анализ уязвимостей (Vulnerability Scanning)
Используйте автоматические инструменты для поиска известных уязвимостей:
Nessus, OpenVAS, Nikto, Burp Suite, Acunetix и др.
Тестирование безопасности (Manual Testing)
Проверка входных данных на внедрение (SQL-инъекции, XSS)
Анализ настроек сервера и приложения
Отслеживание неправильных настроек безопасности (например, слабых паролей, открытых директорий)
Возьмем в пример ресурс https://wotpack.ru/:
Используемые инструменты: Nmap, Nikto, любой браузер, консоль SSH, консоль Kali Linux
Пункт 1.
- Узнаем публичный IPv4 адрес сайта с помощью команды
ping wotpack.ru:PING wotpack.ru (8.6.112.0) 56(84) bytes of data.Итак публичный IP - 8.6.112.0
Пункт 2.
- Смотрим порты с помощью утилиты Nmap -
nmap 8.47.69.6:
Код:
PORT STATE SERVICE
80/tcp open http
443/tcp open https
8080/tcp open http-proxy
8443/tcp open https-altПункт 2.
- Теперь ищем известные уязвимости командой -
nikto -h https://wotpack.ru -ssl -output report.html -Format html:Разберём команду: nikto - сама утилита, -h - указывает целевой веб сервер, https://wotpack.ru - адрес сервера, -ssl - говорит Nikto использовать HTTPS при подключении к целевому серверу, -output report.html -Format html - формат вывода результат (HTML).
| Target IP | 104.26.9.30 |
| Target hostname | wotpack.ru |
| Target Port | 443 |
| HTTP Server | cloudflare |
| Site Link (Name) | https://wotpack.ru:443/ |
| Site Link (IP) | https://104.26.9.30:443/ |
| URI | / |
| HTTP Method | GET |
| Description | /: Uncommon header 'server-timing' found, with multiple values: (cfCacheStatus;desc="DYNAMIC",cfEdge;dur=30,cfOrigin;dur=0,). |
| Test Links | https://wotpack.ru:443/ https://104.26.9.30:443/ |
| References | |
| URI | / |
| HTTP Method | GET |
| Description | /: Uncommon header 'x-fastcgi-cache' found, with contents: BYPASS. |
| Test Links | https://wotpack.ru:443/ https://104.26.9.30:443/ |
| References |
| URI | / |
| HTTP Method | GET |
| Description | /: The site uses TLS and the Strict-Transport-Security HTTP header is not defined. |
| Test Links | https://wotpack.ru:443/ https://104.26.9.30:443/ |
| References | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security |
| URI | / |
| HTTP Method | GET |
| Description | /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. |
| Test Links | https://wotpack.ru:443/ https://104.26.9.30:443/ |
| References | https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ |
| URI | /fCfJx5Lo.TXT |
| HTTP Method | GET |
| Description | /fCfJx5Lo.TXT: Drupal Link header found with value: <https://cdn.gtranslate.net/>; rel=dns-prefetch. |
| Test Links | https://wotpack.ru:443/fCfJx5Lo.TXT https://104.26.9.30:443/fCfJx5Lo.TXT |
| References | https://www.drupal.org/ |
| URI | /fCfJx5Lo. |
| HTTP Method | GET |
| Description | /fCfJx5Lo.: Uncommon header 'x-redirect-by' found, with contents: WordPress. |
| Test Links | https://wotpack.ru:443/fCfJx5Lo. https://104.26.9.30:443/fCfJx5Lo. |
| References | |
| URI | /?/ |
| HTTP Method | GET |
| Description | /?/: Retrieved x-real-ip header: 104.23.221.5. |
| Test Links | https://wotpack.ru:443/?/ https://104.26.9.30:443/?/ |
| References |
| URI | /?/ |
| HTTP Method | GET |
| Description | /?/: IP address found in the 'x-real-ip' header. The IP is "104.23.221.5". |
| Test Links | https://wotpack.ru:443/?/ https://104.26.9.30:443/?/ |
| References | https://portswigger.net/kb/issues/00600300_private-ip-addresses-disclosed |
| URI | /?/ |
| HTTP Method | GET |
| Description | /?/: Uncommon header 'x-real-ip' found, with contents: 104.23.221.5. |
| Test Links | https://wotpack.ru:443/?/ https://104.26.9.30:443/?/ |
| References |
| URI | /search/ / |
| HTTP Method | GET |
| Description | /robots.txt: Entry '/search/ /' is returned a non-forbidden or redirect HTTP code (200). |
| Test Links | https://wotpack.ru:443/search/ / https://104.26.9.30:443/search/ / |
| References | https://portswigger.net/kb/issues/00600600_robots-txt-file |
| URI | /robots.txt |
| HTTP Method | GET |
| Description | /robots.txt: contains 93 entries which should be manually viewed. |
| Test Links | https://wotpack.ru:443/robots.txt https://104.26.9.30:443/robots.txt |
| References | https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt |
| URI | / |
| HTTP Method | GET |
| Description | /: The Content-Encoding header is set to "deflate" which may mean that the server is vulnerable to the BREACH attack. |
| Test Links | https://wotpack.ru:443/ https://104.26.9.30:443/ |
| References | http://breachattack.com/ |
Пункт 3.
- Соберём всю найденную информацию в одно целое:
Целевой IPv4 адрес: 104.26.9.30
Список уязвимостей:
- X-Content-Type-Options header не определен
- Межсайтовое изменение типа контента (Content Sniffing): Браузеры могут неправильно интерпретировать тип содержимого, что позволяет злоумышленнику запускать вредоносный скрипт или выполнять другие атаки, связанные с неправильной обработкой типов данных.
- Использование XSS-атак: Без этого заголовка злоумышленник может попытаться внедрить вредоносный скрипт, который при неправильной обработке браузером может быть выполнен.
- Обойти меры защиты: Отсутствие этого заголовка снижает безопасность защиты от некоторых методов обхода, таких как MIMEType атаки.
- Открытый robots.txt
- Он позволяет владельцам сайтов указывать, какие части сайта можно индексировать, а какие — нет. Это помогает защитить конфиденциальную информацию, снизить нагрузку на сервер или управлять видимостью контента в поисковых системах. Таким образом мы можем увидеть множество каталогов, о которых могли даже не догадываться.
Сам файл:
Код:User-agent: * # общие правила для роботов, кроме Яндекса и Google, # т.к. для них правила ниже Disallow: /cgi-bin # папка на хостинге Disallow: /? # все параметры запроса на главной Disallow: /*? Disallow: /wp- # все файлы WP: /wp-json/, /wp-includes, /wp-content/plugins Disallow: /wp/ # если есть подкаталог /wp/, где установлена CMS (если нет, # правило можно удалить) Disallow: *?s= # поиск Disallow: *&s= # поиск Disallow: /search/ # поиск Disallow: /author/ # архив автора Disallow: /users/ # архив авторов Disallow: */trackback # трекбеки, уведомления в комментариях о появлении открытой # ссылки на статью Disallow: */feed # все фиды Disallow: */rss # rss фид Disallow: */embed # все встраивания Disallow: */wlwmanifest.xml # xml-файл манифеста Windows Live Writer (если не используете, # правило можно удалить) Disallow: /xmlrpc.php # файл WordPress API Disallow: *utm*= # ссылки с utm-метками Disallow: *openstat= # ссылки с метками openstat Allow: */uploads # открываем папку с файлами uploads Disallow: /*attachment* Disallow: /cart # для WooCommerce Disallow: /checkout # для WooCommerce Disallow: *?filter* # для WooCommerce Disallow: *?add-to-cart* # для WooCommerce Clean-param: add-to-cart # для WooCommerce User-agent: GoogleBot # правила для Google (комментарии не дублирую) Allow: /wp-content/themes/*.css Allow: /wp-content/themes/*.js Allow: /wp-content/themes/*.ttf Allow: /wp-content/themes/*.woff Allow: /wp-content/themes/*.woff2 Allow: /wp-content/plugins/*.css Allow: /wp-content/plugins/*.png Allow: /wp-content/plugins/*.ttf Allow: /wp-content/plugins/*.woff2 Allow: /wp-content/plugins/*.woff Allow: /wp-content/plugins/*.js Allow: /wp-content/uploads/*.css Allow: /wp-content/uploads/*.js Allow: /wp-includes/css/ Allow: /wp-includes/js/ Allow: /wp-includes/images/ Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: /*/page* Disallow: /page* Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Disallow: *utm*= Disallow: *openstat= Allow: */uploads Allow: /*/*.js # открываем js-скрипты внутри /wp- (/*/ - для приоритета) Allow: /*/*.css # открываем css-файлы внутри /wp- (/*/ - для приоритета) Allow: /wp-*.png # картинки в плагинах, cache папке и т.д. Allow: /wp-*.jpg # картинки в плагинах, cache папке и т.д. Allow: /wp-*.jpeg # картинки в плагинах, cache папке и т.д. Allow: /wp-*.gif # картинки в плагинах, cache папке и т.д. Allow: /wp-admin/admin-ajax.php # используется плагинами, чтобы не блокировать JS и CSS User-agent: Yandex # правила для Яндекса (комментарии не дублирую) Disallow: /cgi-bin Disallow: /? Disallow: /wp- Disallow: /wp/ Disallow: *?s= Disallow: *&s= Disallow: /search/ Disallow: /author/ Disallow: /users/ Disallow: */trackback Disallow: */feed Disallow: */rss Disallow: */embed Disallow: /*/page* Disallow: /page* Disallow: */wlwmanifest.xml Disallow: /xmlrpc.php Allow: */uploads Allow: /*/*.js Allow: /*/*.css Allow: /wp-*.png Allow: /wp-*.jpg Allow: /wp-*.jpeg Allow: /wp-*.gif Allow: /wp-admin/admin-ajax.php Clean-Param: utm_source&utm_medium&utm_campaign&preview&from # Яндекс рекомендует не закрывать Clean-param: cn-reloaded&html_params&unapproved&moderation-hash&ysclid # от индексирования, а удалять параметры меток, # Google такие правила не поддерживает Clean-Param: openstat # аналогично User-agent: facebookexternalhit Allow: / Crawl-delay: 0 # Укажите один или несколько файлов Sitemap (дублировать для каждого User-agent # не нужно). Google XML Sitemap создает 2 карты сайта, как в примере ниже. # Укажите главное зеркало сайта, как в примере ниже (с WWW / без WWW, если HTTPS # то пишем протокол, если нужно указать порт, указываем). Команда стала необязательной. Ранее Host понимал # Яндекс и Mail.RU. Теперь все основные поисковые системы команду Host не учитывают. Host: https://wotpack.ru Sitemap: https://wotpack.ru/sitemap.xml
- Он позволяет владельцам сайтов указывать, какие части сайта можно индексировать, а какие — нет. Это помогает защитить конфиденциальную информацию, снизить нагрузку на сервер или управлять видимостью контента в поисковых системах. Таким образом мы можем увидеть множество каталогов, о которых могли даже не догадываться.
- Порты:
- 80/tcp open http
- 443/tcp open https
- 8080/tcp open http-proxy
- 8443/tcp open https-alt
Пункт 4.
- Теперь мы можем использовать множество инструментов для получения доступа к серверу. Самым лучшим вариантом, основываясь на найденных уязвимостях является MIME атака (подмена расширения имени файла).
Спасибо за прочтение и уделённое время!
- Автор/Источник
- pithunt
