Перевіряти сайт на безпеку використання обов’язково потрібно. В іншому випадку може бути таке, що частина користувачів вашого сайту попереджає браузер, що сайт небезпечний і не варто на ньому залишати свої дані у формах введення. А найстрашніше, дані ваших користувачів справді можуть красти зловмисники, зливаючи їх конкурентам, списуючи гроші з картки та роблячи інші гидоти.
За допомогою інструменту 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 і шрифти, до яких звертається сторінка, використовуючи адресу, що починається з подвійного слеша (на кшталт такого: //itest.com.ua/img/itest.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 вказані дані користувача (наприклад, itest.com.ua?email-verify=oleg@gmail.com), то ці дані не захищені.
- Bad Content Type.
Сторінки та ресурси, у яких фактичний тип не відповідає типу в заголовку контенту, а також якщо вказано неприпустимий MIME-тип. Це особливо критично, коли сервер віддає заголовок відповіді “X-Content-Type-Options” зі значенням “nosniff”, оскільки браузери покладаються на заголовок Content-Type для правильного оброблення вмісту.
Пріоритетність рекомендацій
Найімовірніше, вам не вдасться вписати описані в цій статті роботи з перевірки безпеки використання сайту в список робіт із SEO. Однак, якщо ви є власником сайту або бізнесу, який представлений в інтернеті сайтом, то вкрай важливо перевірити безпеку його використання. Щоб не довелося одного разу боляче заплатити за свою безпечність.
Ах так, все перераховане вище можна вивантажити з жаби в табличку двома кліками. Просто перейдіть у меню Reports > Insecure Content і зробіть вивантаження в потрібний тип файлу.
