Проверять сайт на безопасность использования обязательно нужно. В противном случае может быть такое что часть пользователей вашего сайта предупреждает браузер что сайт небезопасен и не стоит на нем оставлять свои данные в формах ввода. А самое страшное, данные ваших пользователей действительно могут воровать злоумышленники сливая их конкурентам, списывая деньги с карточки и делая другие гадости.
С помощью инструмента Screaming Frog SEO Spider ("лягушки") можно быстро провести верхне уровневую проверку сайта на проблемы с безопасностью. И давайте расскажу как это сделать.
Настройка инструмента
Нам нужно собрать максимум информации, а потому перед запуском сканирования нужно произвести настройку.
Скорее всего у вас уже была установлена лягушка, а значит она использовалась ранее и неизвестно что вы там настроили. Поэтому нужно сбросить настройки до базовых (File > Configuration > Clear Default Configuration). Если вы только установили инструмент - этот шаг можно упустить.
Затем нам нужно изменить режим "Respect Robots.txt" на "Ignore Robots.txt but report status", для того чтобы при сканировании мы игнорировали директивы файла Robots.txt, ведь пользователи же им не следуют.. Делается это в меню Configuration > Robots.txt > Settings.
Так как нам нужно собрать максимум страниц для выявление наибольшего числа проблем, одного сканирования ссылок недостаточно, нам нужны и файлы карты сайта как источник данных о страницах. Для того чтобы скормить их лягушке идем в настройки Configuration > Spider > Crawl, и в разделе "XML Sitemaps" проставляем все галочки и указываем все файлы карты сайта в текстовом поле, каждый файл с новой строки.
Все готово, сканирование можно запускать!
Фильтры с проблемами
После завершения сканирования вам нужно перейти в отчет "Security", с ним мы и будем работать в рамках проверки безопасности использования сайта. По-умолчанию вместо фильтра выбрано значение "All", это нужно заменить на соответствующий фильтр с проблемой. Далее — рассмотрим каждый из фильтров.
— HTTP URLs
Страницы на незащищенном протоколе HTTP. Если на вашем сайте есть такие страницы и они отдают код ответа 200, то у вас точно не настроен 301 редирект с HTTP на HTTPS, а это нужно срочно сделать подключив SSL-сертификат.
В противном случае будет крайне легко получить данные ваших посетителей, а также встроить в ваш сайт контент которого там быть не должно. Кстати, этой фишкой пользуется сотовый оператор "Мегафон", встраивая рекламные блоки в любые сайты на HTTP. Это замечал даже я на своих сайтах и писал им гневные письма в поддержку.
— Mixed Content
Страницы, загруженные через безопасный протокол HTTPS, но использующие загруженные через HTTP-соединение ресурсы: изображения, шрифты, JavaScript или CSS. Такие ресурсы снижают эффективность HTTPS и облегчают злоумышленникам мониторинг действий пользователя и подмену этих ресурсов страниц. Браузеры могут автоматически блокировать загрузку ресурсов с HTTP или пытаться загрузить их через HTTPS.
У таких страниц нужно заменить загрузку ресурсов, переведя их на более безопасный HTTPS. Найти все проблемные ресурсы можно выбрав страницу и перейдя на дополнительный отчет "Outlinks" внизу.
— Form URL Insecure
Страницы, на которых размещена форма, у которой обработчик (указывается в атрибуте action) использует протокол HTTP. Это может привести к тому что любые данные которые пользователь введет в эту форму на сайте могут быть получены злоумышленниками.
Чтобы исправить проблему, укажите обработчик формы через протокол HTTPS. Сам адрес обработчика можно посмотреть выбрав страницу и перейдя на дополнительный отчет "URL Details" внизу, он будет в одном из полей "Form .. Action Link".
— Form on HTTP URL
Это форма, которая находится на протоколе HTTP. Хуже и не придумаешь, срочно настраивайте 301 редирект с HTTP на HTTPS и подключайте SSL-сертификат.
— Unsafe Cross-Origin Links
Страницы, ссылающиеся на другие сайты с атрибутом target="blank" (открытие ссылки в новой вкладке браузера), но при этом не указывающие атрибут rel="noopener" (или rel="noreferrer"). Прикол в том, что страница на которую мы попадем по такой ссылке может получить контроль над текущей через JavaScript свойство "window.opener" (например, сделать редирект на фишинговую страницу).
— Protocol-Relative Resource Links
Страницы, использующие ресурсы без указания протокола. Речь идет об изображениях, CSS, JS и шрифтах, к которым обращается страница используя адрес начинающийся с двойного слэша (вроде такого: //rocket-agency.pro/img/nature.jpg).
Раньше такое указание ссылок на ресурсы часто рекомендовалось разработчикам, но сегодня это является ошибкой и если в наследство у вас остались такие ссылки, то обязательно их исправьте указав протокол HTTPS. В противном случае ваш сайт уязвим для отслеживания (MiTM-атаки).
— Missing HSTS Header
Страницы и ресурсы, для которых не настроен заголовок HSTS. Заголовок ответа сервера "HTTP Strict-Transport-Security" (HSTS) указывает браузерам, что обращаться следует только с использованием HTTPS, а не HTTP. Если сайт доступен по протоколу HTTP, то с таким заголовком пользователи будут перенаправлены на HTTPS, даже если они по-прежнему будут пытаться открыть сайт по протоколу HTTP.
— Missing Content-Security-Policy Header
Страницы и ресурсы, для которых не настроен заголовок "Content-Security-Policy". Этот заголовок ответа сервера позволяет сайту контролировать, какие ресурсы загружаются для страницы. Он помогает защититься от атак межсайтового скриптинга (XSS), использующего доверие браузера к содержимому, полученному с сервера.
— Missing X-Content-Type-Options Header
Страницы и ресурсы, для которых не настроен заголовок "X-Content-Type-Options" со значением "nosniff". В отсутствие MIME-типа файла браузеры могут его снифать «обнюхивать», чтобы угадать тип контента, для корректной интерпретации его для пользователей. Однако этим могут воспользоваться злоумышленники, которые попытаются загрузить вредоносный код (например, JavaScript), через подставное изображение. Заголовок же указывает браузерам полагаться только на содержимое Content-Type и блокировать все, где содержимое ему не соответствует.
— Missing X-Frame-Options Header
Страницы и ресурсы, для которых не настроен заголовок "X-Frame-Options" со значением "DENY" или "SAMEORIGIN". Он указывает браузеру не отображать страницу во frame, iframe, тег embed или объект. Это помогает избежать атак типа «кликджекинг», когда ваш контент отображается на другой странице, контролируемой злоумышленником.
— Missing Secure Referrer-Policy Header
Страницы и ресурсы, для которых не настроен заголовок "Referrer-Policy" со значением "no-referrer-when-downgrade", "strict-origin-when-cross-origin", "no-referrer" или "strict-origin". Если ни один из данных заголовков не указан, то в заголовке "referrer" при переходе по ссылке с сайта можно будет отследить с какой страницы сайта произошел переход. Если при этом в URL указаны пользовательские данные (например, rocket-tools.pro?email-verify=ilya@gmail.com), то эти данные не защищены.
— Bad Content Type
Страницы и ресурсы, у которых фактический тип не соответствует типу в заголовке контента, а также если указан недопустимый MIME-тип. Это особенно критично когда сервер отдает заголовок ответа "X-Content-Type-Options" со значением "nosniff", так как браузеры полагаются на заголовок Content-Type для правильной обработки содержимого.
Приоритетность рекомендаций
Скорее всего у вас не получится вписать описанные в этой статье работы по проверке безопасности использования сайта в список работ по SEO. Однако, если вы являетесь владельцем сайта или бизнеса, который представлен в интернете сайтом, то крайне важно проверить безопасность его использования. Чтобы не пришлось однажды больно заплатить за свою беспечность.
Ах да, все вышеперечисленное можно выгрузить из лягушки в табличку двумя кликами. Просто перейдите в меню Reports > Insecure Content и сделайте выгрузку в нужный тип файла.
