Безпека веб-сервера, SEO та Ви: Отримайте затишок з WebDevs

Цифрові маркетологи дуже легко розлучаються з IT-командою / WebDevs при вдосконаленні сайту. Графіки стають неспокійними, існують організаційні силоси, які сповільнюють вас, або ви просто ніколи не розмовляєте один з одним. Багато організацій використовують перехресні рішення для співпраці між відомствами, щоб запобігти цьому, але навіть у них можна легко забути про безпеку сайту та його вплив на SEO. Низька безпека може призвести до збільшення часу завантаження сторінки, затримки часу та потенційних зловмисних активів або перенаправлення на ваш сайт. Для того, щоб забезпечити кращий досвід користувача, необхідно, щоб ваш сайт залишався безпечним, навіть якщо ви ніколи не торкаєтеся кредитних карт та іншої інформації PCI або PII.

Створення веб-сайту, що використовує HTTPS, відверто стає нормою, тому ми не будемо в цьому вникати. Якщо ви хочете дізнатися про HTTPS, OnCrawl має чудову статтю про те, як HTTPS покращує ваш SEO спеціально, але є деякі вторинні теми безпеки сайту, які не можуть бути такими очевидними і можуть бути потенційними вигодами для вас, ваших клієнтів і вашої організації.

В ідеалі реалізація цих виправлень запобігатиме атакам на ваш сайт, підвищувати швидкість сайту, збільшувати час та багато іншого, додаючи додаткового бонусу створення хорошого робочого процесу та взаємовідносин з вашою командою Dev! Моя думка завжди полягає в тому, щоб маркетинг і розвиток працювали разом, коли це можливо, щоб створити найкращий для користувачів досвід.

Почнемо з найпоширенішої проблеми безпеки та скарги щодо конфіденційності користувача: Cookies
Теоретично можна завантажувати будь-яку кількість файлів cookie (бажано з надійних джерел, які є безпечними), але, хоча розумно обмежувати кількість файлів cookie, ви також повинні переконатися, що ваші файли cookie встановлені з "захищеним" прапором. .
Наприклад, в ASP.NET , все, що вам потрібно зробити, це встановити в Web.config наступне: <httpCookies requireSSL = ”true” /> або встановити прапор requireSSL = ”true” у web.config для конкретних елементів сторінки. Дуже просто!
У PHP можна постійно встановлювати прапор у php.ini, встановивши session.cookie_secure = True як параметр.
Там є багато інформації там на забезпеченні cookies та різних мов, таким чином я би запропонував вам поїхати Множинне зір для більш конкретної інформації, яка може бути корисною для ВАШОГО сайту, якщо ви використовуєте щось, крім ASP.NET або PHP.

Заголовки програмного забезпечення сервера:
Кожен сайт працює на сервері (невже), але чи знаєте ви, що сам сервер вашого сайту може конкретно повідомляти зловмисникам, як знайти подвиги для вашої системи? Заголовки серверів публічно показують тип сервера, його номер версії, тип вмісту та програмне забезпечення, яке він використовує. Ви можете вимкнути / зупинити надсилання заголовка сервера декількома способами, залежно від технології.

ngnix : Ви можете налаштувати вміст, який надсилає nginx, редагуючи nginx.conf. Спочатку знайдіть розділ http, який визначає конфігурацію HttpCoreModule. Далі, щоб вимкнути інформацію заголовка, все, що вам потрібно зробити, це додати thhis: server_tokens off ; як директива.

IIS , платформа Windows Server, є дещо складнішою і передбачає отримання деяких ресурсів безпосередньо від Microsoft. Це може бути трохи засмучує, але воно того варте.
Перший крок полягає в тому, щоб увімкнути “Metabase Compatibility” (що ви можете зробити, виконавши ці дії інструкції від Microsoft .)
Далі ви встановите ресурс URLScan (також знайдений на Сайт підтримки Microsoft )
Після цього відкрийте файл URLScan.ini за допомогою текстового редактора та знайдіть ключ "RemoveServerHeader". За замовчуванням вона встановлюється рівною 0, що дозволяє надсилати заголовок, тому просто встановіть значення 1, щоб припинити надсилання заголовка сервера.

Apache / Lighttpd : На жаль, я не маю достатньо досвіду роботи з Apache або Lighttpd, щоб надати керівництво щодо того, як їх налаштувати, але я радив би працювати з командою розробників, щоб вирішити це, якщо ви використовуєте або їх.

Тепер ми потрапляємо в специфічні заголовки безпеки . Таким чином, є деякі заголовки безпеки, крім тих, які я збираюся отримати нижче, але наступні є ті, з якими МНОЖУТЬ мати досвід роботи. Я дуже радив вам зробити аудит заголовків безпеки вашого сервера з вашою командою Dev (бажано над пончиками та кавою), тому що вони, напевно, знають більше, ніж я, і ви можете працювати над впровадженням рішень разом.

Нагадування публічних ключів:
Закріплення відкритого ключа HTTP захищає ваш сайт від атак MiTM, використовуючи сертифікати X.509. За допомогою білого списку лише ті особи, яким довірятимуть веб-переглядачі, ваші користувачі будуть захищені в разі порушення сертифіката. Щоб розпочати використання цих переваг, потрібно встановити наступний заголовок: “pin-sha256 =” base64 == ”; max-age = expireTime [; includeSubDomains] [; report-uri = ”reportURI”] ” Ви також знайдете корисним шукати специфічну для програмного забезпечення реалізацію для Apache, Lighttpd і IIS для максимальної сумісності.

Строгий транспорт-безпека:
HTTP Strict Transport Security підсилює реалізацію TLS, надаючи користувальницькому агенту примусове використання HTTPS. (Я знаю, я знаю. Я повинен був включити НІЧО про HTTPS!)
Він захищає від атак зниження протоколу та створює ще один рівень безпеки файлів cookie, запобігаючи викрадення.
Хоча існує деяка… сіра зона… навколо деяких людей, які використовують цю функцію для створення «Supercookies», яка може проштовхнути «інкогніто» та «приховані» сесії браузера, я все ще особисто вважаю це цінним доповненням для безпеки сервера. Якщо ви хочете це зробити, ваші користувачі будуть вам дякувати.
Я рекомендую використовувати наступне значення: «сувора транспортна безпека: max-age = 31536000; includeSubdomains ”.

Політика щодо захисту вмісту:
Це відмінний спосіб захистити свій сайт від атак XSS. Під час створення білого списку затверджених джерел вмісту можна заборонити завантажувати веб-переглядачі шкідливих активів, які, можливо, були вставлені без вашого дозволу, які спричиняють проблеми з безпекою для користувачів і вашого хост-сервера. Щоб повідомляти вашому серверу лише активації, розміщені на вашому сайті (або довіреній третій стороні), ви просто налаштуєте заголовок Content-Security-Policy, щоб прочитати: Content-Security-policy script-src 'self' YOURDOMAIN.com. Просто додайте домен об’яв із активами третіх сторін після свого власного, щоб включити їх також.
Швидка примітка! Якщо ваш заголовок все ще читає X-Content-Security-Policy, вам слід оновити його, оскільки браузери зараз підтримують головним чином версію без префікса. Ви можете знайти інші підручники, які показують вам ВСІ підтримувані політики та змінні, які можна включити сюди, але це найосновніший, щоб додати список власних ресурсів.

Параметри типу X-Content-Type:
X-Content-Type-Options зупиняє перегляд браузера MIME-типів вмісту. Божевільний простий. Як додатковий бонус, він змушує браузер вирішувати тільки заявлені типи вмісту. Насправді для цього заголовка існує тільки одне дійсне значення, про яке я знаю, і це "X-Content-Type-Options: nosniff" .

Параметри X-Frame:
Заголовок X-Frame-Options інформує веб-переглядач, чи хочете ви додати ваш сайт до обрамлення. Якщо ви забороняєте веб-переглядачу створювати веб-сайт, можна запобігти " clickjacking . ”Ви повинні встановити це, щоб прочитати “ x-frame-options: SAMEORIGIN ”.

X-XSS-захист:
Цей заголовок встановлює конфігурацію фільтрів наскрізних сценаріїв, вбудованих у більшість браузерів, за винятком непідтримуваних версій IE та Netscape. Але хто більше використовує Netscape, чесно? Рекомендованим значенням для цього заголовка є “X-XSS-Protection: 1; mode = block ”.

Процес реалізації цих виправлень може займати всього кілька днів, включаючи аудит, але після цього ви можете спокійно відпочити, знаючи, що сервер вашого сайту є більш безпечним і що користувачі захищені від експлуатації. Крім того, ми сподіваємося, що ви наблизилися до команди Dev і створили хороші відносини для кращого обслуговування вашої організації!