Цифровым маркетологам очень легко отделиться от ИТ-команды / WebDevs при улучшении сайта. Расписание становится напряженным, организационные разрозненные процессы замедляют вас, или, может быть, вы просто никогда не разговариваете друг с другом. Многие организации используют межведомственные решения для совместной работы, чтобы предотвратить это, но даже в тех случаях можно легко забыть о безопасности сайта и о том, как он влияет на SEO. Плохая безопасность может привести к увеличению времени загрузки страницы, времени простоя и потенциального проникновения вредоносных ресурсов или перенаправлений на ваш сайт. Чтобы обеспечить наилучшее взаимодействие с пользователем, обязательно, чтобы ваш сайт оставался безопасным, даже если вы никогда не касаетесь кредитных карт и другой информации PCI или PII.

Честно говоря, создание веб-сайта, использующего HTTPS, становится нормой, поэтому мы не будем вдаваться в подробности. Если вы хотите узнать о HTTPS, OnCrawl Есть отличная статья о том, как HTTPS улучшает ваше SEO, но есть некоторые второстепенные темы безопасности сайта, которые могут быть не столь очевидными и могут быть потенциальными выгодами для вас, ваших клиентов и вашей организации.

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

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

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

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

IIS , платформа Windows Server, немного сложнее и предполагает получение некоторых ресурсов непосредственно от Microsoft. Это может быть немного неприятно, но оно того стоит.
Первый шаг - включить «Совместимость с метабазой» (что можно сделать, выполнив инструкции от Microsoft .)
Далее вы установите ресурс URLScan (также находится на Сайт поддержки Microsoft )
Как только это будет сделано, откройте файл URLScan.ini в текстовом редакторе и найдите ключ «RemoveServerHeader». По умолчанию это значение равно 0, что позволяет отправлять заголовок, поэтому просто установите значение 1, чтобы прекратить отправку заголовка сервера.

Apache / Lighttpd : К сожалению, у меня недостаточно опыта работы с Apache или Lighttpd, чтобы предоставить руководство по их настройке, но я призываю вас поработать с командой разработчиков, чтобы решить эту проблему, если вы используете любой из их.

Теперь перейдем к конкретным заголовкам безопасности . Итак, есть некоторые заголовки безопасности, помимо тех, о которых я расскажу ниже, но вот те, с которыми у меня есть СПЕЦИАЛЬНЫЙ опыт. Я НАСТОЯТЕЛЬНО советую вам провести аудит заголовков безопасности вашего сервера с вашей командой разработчиков (желательно за пончиками и кофе), потому что они, вероятно, знают больше, чем я, и вы можете вместе работать над реализацией решений.

Открытые ключи Pins:
Закрепление открытого ключа HTTP защищает ваш сайт от атак MiTM с использованием поддельных сертификатов X.509. За счет внесения в белый список только тех идентификаторов, которым должен доверять браузер, ваши пользователи защищены в случае, если центр сертификации скомпрометирован. Чтобы начать использовать эти преимущества, вам нужно установить следующий заголовок «pin-sha256 =» base64 == »; max-age = expireTime [; IncludeSubdomains] [; report-uri = ”reportURI”] ” Вы также найдете полезным найти программную реализацию для Apache, Lighttpd и IIS, чтобы максимизировать совместимость.

Строгий-Transport-Security:
HTTP Strict Transport Security усиливает вашу реализацию TLS, заставляя агента пользователя принудительно использовать HTTPS. (Я знаю, я знаю. Я должен был включить что-то о HTTPS!)
Он защищает от атак с использованием более ранних версий протоколов, а также создает еще один уровень безопасности файлов cookie, предотвращая угон.
Хотя есть некоторые «серые области» вокруг некоторых людей, использующих эту функцию для создания «суперкучек», которые могут проталкивать через браузер «инкогнито» и «скрытые» сеансы, я все же лично считаю это ценным дополнением для безопасности сервера. Если вы не против, ваши пользователи будут вам благодарны.
Я рекомендую использовать следующее значение: «strict-transport-security: max-age = 31536000; IncludeSubdomains».

Content-Security-Policy:
Это отличный способ защитить ваш сайт от атак XSS. Когда вы вносите в белый список утвержденные источники контента, вы можете запретить браузерам загружать вредоносные ресурсы, которые могут быть вставлены без вашего разрешения, что создает проблемы безопасности для ваших пользователей и вашего хост-сервера. Чтобы сервер разрешил только ресурсы, размещенные на вашем сайте (или доверенной третьей стороне), просто измените заголовок Content-Security-Policy на: Content-Security-Policy script-src 'self' YOURDOMAIN.com. Просто добавьте обслуживающий домен ваших сторонних активов после вашего собственного, чтобы включить их тоже.
Быстрая заметка! Если ваш заголовок все еще читает X-Content-Security-Policy, вы должны обновить его, так как браузеры теперь в основном поддерживают нефиксированную версию. Вы можете найти другие учебники, которые покажут вам ВСЕ поддерживаемые политики и переменные, которые вы можете включить здесь, но это самый базовый для внесения в белый список ваших собственных ресурсов.

X-Content-Type-Options:
X-Content-Type-Options не позволяет браузеру пытаться MIME-сниффить типы контента. Безумно просто. В качестве дополнительного бонуса он заставляет браузер разрешать только объявленные типы контента. На самом деле есть только одно действительное значение для этого заголовка, о котором я знаю, и это «X-Content-Type-Options: nosniff» .

X-Frame-Options:
Заголовок X-Frame-Options информирует браузер, хотите ли вы разрешить создание вашего сайта в рамке или нет. Если вы удерживаете браузер от создания вашего сайта, вы можете предотвратить ClickJacking . »Вы должны установить это так: « x-frame-options: SAMEORIGIN ».

X-XSS-Protection:
Этот заголовок устанавливает конфигурацию фильтров межсайтовых сценариев, встроенных в большинство браузеров, за исключением неподдерживаемых версий IE и Netscape. Но кто больше использует Netscape, если честно? Рекомендуемое значение для этого заголовка: «X-XSS-Protection: 1; Режим = блок».

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

Похожие

Комментарии