![]() |
С чего начать проверку сайта на уязвимости в тестовом окружении?
Кто как обычно проверяет свои проекты или стенды перед выкатом? Я обычно делаю стандартный набор простых тестов, чтобы понять, где могут быть дыры. Сначала смотрю на основные заголовки HTTP — чтобы не лезли лишние детали сервера, отключаю отображение ошибок, чтоб не светить пути. Потом проверяю на SQL-инъекцию — подставляю простые payload'ы в формы и параметры, смотрю, как сервер реагирует. Еще всегда гляжу на XSS — вставляю скрипты в поля ввода, проверяю вывод. Заглядываю в файлы конфигурации, ищу открытые панели админки или бекдоры (если такие есть). Для сложнее — смотрю, как настроена CSP, есть ли ограничения на загрузку скриптов и стилей. Интересно, кто какие готовые чек-листы или инструменты ставит на стенды? Может, кто держит под рукой что-то удобное, чтобы быстро пройтись и без лишней воды понять, что точно требует внимания?
|
Начинаю с простого — прогоняю через автоматические сканеры вроде Nikto или OWASP ZAP, чтобы быстро понять, где косяки. Потом вручную проверяю формы на инъекции и XSS, как ты и делаешь. Еще не забываю посмотреть, как настроены права на файлы и папки, чтобы случайно что-то важное не было доступно всем подряд. Важно делать это в тестовом окружении, чтоб не сломать рабочий сайт.
|
Я обычно тоже сначала автоматикой пробегаюсь — вроде ZAP или Nikto, чтобы накидать список потенциальных проблем. Потом по формам тупо вставляю всякое простое, чтоб проверить, не валятся ли ошибки или скрипты в ответе. Ну и не забываю права на папки глянуть, чтоб случайно не вывалить серверные файлы наружу. Главное делать все это не на боевом, а на тесте.
|
Автоматикой пройтись, чтобы быстро выявить базовые уязвимости — это классика. Потом ручками пробежаться по формам, вставляя всякую дрянь — смотрю, что сервер выдает. Еще права на файлы проверить, чтобы случайно не светить важное. Главное — всё на тестовом стенде, чтоб не угробить боевой сайт.
|
| Время: 01:36 |