Прогнал сайт через бесплатные сканеры уязвимостей — вылезли десятки проблем, что из этого реально надо чинить?

Бесплатные чекеры сканируют только снаружи по заголовкам HTTP-ответов. Увидят версию PHP или веб-сервера в хедере — и сразу лепят средний уровень риска. Это не уязвимость, а просто раскрытие информации. Если под эту конкретную версию нет подтверждённого эксплойта, тратить на это деньги бессмысленно.

В прошлом году на такой же панике отдали 1.600 AED фрилансеру за отчёт из 35 пунктов. По факту оказалось, что 28 из них закрылись добавлением трёх строчек заголовков в конфиг сервера. Реальной уязвимостью был только один дырявый плагин, который мы и так могли бесплатно обновить нажатием одной кнопки.

Откройте отчет и забейте в поиск: 'Injection', 'XSS' 'Bypass' 'Arbitrary File'. Отметьте строки с этими словами, наберется от силы пункта 3-4. Скажите своему специалисту, чтобы проверил и закрыл только их. На остальное пока можно забить.

Бесплатные сканеры обычно просто кошмарят пользователя чтобы впарить свои платные глубокие проверки или консультации. Если прокрутить страницу вниз, там почти всегда висит предложение вроде «исправьте это в один клик с профессионалами». Не ведитесь на всё, что подсвечено красным.

У вас сайт на готовой CMS типа WordPress или самописный движок? И еще: при приеме оплаты данные карт хранятся на вашем сервере или идет перенаправление на платежный шлюз провайдера? От этого оценка рисков меняется кардинально.

Спокойно, если сайт прямо сейчас не под атакой, не надо паниковать. Автоматические чекеры снижают баллы буквально за каждый недостающий заголовок. В вебе сайтов без единого предупреждения почти не бывает. Ваш главный приоритет всегда — база клиентов, хеширование админских паролей и поля форм.

Рядом с пунктами в отчете обычно указаны коды CVE или CWE. Если что-то непонятно сразу гуглите этот код. Почитайте пару веток на форумах на турецком или английском о том чем эта уязвимость грозит на практике — так вы будете говорить с разработчиком куда предметнее.

Попробую.

Верно. Первые три месяца все идет хорошо, проблемы всплывают на четвертом.

Если не зафиксировать это письменно с самого начала, потом возникнут споры. Пишите, если есть вопросы, отвечу по мере возможности.

Если я правильно понял, вы имеете в виду следующее: При принятии решений записывайте и худший сценарий, а не только лучший.

Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно. Я бы пошел этим путем.

Позвольте подвести итог сказанному выше. То, что делают все, не значит, что это правильно.

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

мы тоже какое-то время назад застряли на том же месте но главное не цифра, а то, на основе чего она получена.

все, кто торопится с сканер уязвимостей онлайн, спотыкаются на одном и том же потом на этом всё, извините если затянул.

Согласен. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

На этом всё, извините, если затянул.

Если я правильно понял, вы имеете в виду следующее: Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете, что именно улучшать.

Да, по теме сканер уязвимостей онлайн ситуация именно такая. Если ругать за ложные тревоги, никто больше не будет присылать уведомления.

Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Я долго занимался этим вопросом. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Надеюсь это будет полезно.

Не знал об этом. Без измерений мы всегда приходим к одному и тому же.

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

У меня нет опыта в сканер уязвимостей онлайн, поэтому и спрашиваю. Главное не цифра, а то, на основе чего она получена.

Я бы пошел этим путем.