HTTPS повсюду

Интернет – это триллионы сайтов и миллиарды ежедневных пользователей. Он является основным способом общения для большинства людей в мире. Однако, когда интернет только создавался, никто и не предполагал, что он станет таким, как сейчас. Безопасность, конфиденциальность, способы перевода средств и другие элементы не были заложены в протоколы, так как никто не думал, что они понадобятся. Изначально в интернете не было шифрования (использовался открытый текст), потому что разработчики и представить себе не могли нынешние инструменты для отслеживания и просмотра трафика в сетях и интернете («сниффинг» сетевого трафика), которые можно использовать также для прерывания, изменения и последующего отправления трафика по назначению без ведома и участия получателя. Именно поэтому сейчас шифрование всего трафика в интернете – насущная необходимость. Тем не менее пока не все согласны с этой идеей, поэтому, прежде чем обсуждать «как», обратимся к «почему».

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

Трафик может быть перехвачен в ситуациях, когда люди пользуются незащищенной сетью, например в кафе или когда соседи делятся Wi-Fi друг с другом. Неизвестно, кто еще находится в сети и может наблюдать за посещающими ваш сайт людьми.

Существует также множество ситуаций, когда можно с полной уверенностью сказать об отслеживании трафика, например при использовании интернета в отеле и на работе или при подключении к любой сети, где производится Deep Packet Inspection (глубокая проверка пакетов).

СОВЕТ. Deep Packet Inspection означает обработку данных, которая проверяет передаваемые по сети пакеты (данные), что приводит к таким действиям, как блокирование, перенаправление и протоколирование.

Когда кто-то отслеживает сетевой трафик, он может не только видеть то, что видит пользователь (нарушая его конфиденциальность), но и изменять передаваемую ему информацию. В настоящее время в крупных отелях распространена практика замены всей рекламы на незашифрованных сайтах на свою собственную рекламу. Это один из возможных вариантов изменения информации, которую видят пользователи. Другим примером может быть внедрение вредоносных программ, скриптов или дезинформации на сайт, который они посещают. Возможный ущерб пользователям удивительно высок, даже несмотря на довольно низкую вероятность совершения серьезной атаки (если только речь не идет про очень большой либо популярный сайт). Если это все еще звучит недостаточно убедительно, то стоит напомнить: когда трафик идет по HTTP, а не по HTTPS, современные браузеры предупреждают пользователей о том, что посещаемый ими сайт небезопасен (либо с помощью графических элементов, либо с помощью текста). Вред для бизнеса очевиден.

Теперь, когда мы убедились, что всегда нужно использовать HTTPS, определим Правило:

Необходимо разрешать доступ к сайту только через HTTPS. Если кто-то пытается использовать HTTP-соединение, следует перенаправить соединение на HTTPS. Это можно сделать с помощью заголовков безопасности в коде или серверных настроек, о чем было рассказано ранее в разделе «Заголовки безопасности: ремни безопасности для веб-приложений».

Настройки TLS

Следует убедиться, что для шифрования используется последняя версия TLS (в настоящее время 1.3, но если она не поддерживается провайдером, то на момент написания книги еще можно использовать 1.2). Поскольку версии часто обновляются, рекомендуем поискать в интернете информацию о текущих передовых практиках.

О других передовых практиках в этой области можно узнать в главе 3 «Проектирование защиты».

СОВЕТЫ ПО TLS

Рекомендации по применению TLS находятся на bettercrypto.org/#webservers и https://ssl-config.mozilla.org/.

Получить помощь в настройке совместимости можно на wiki.mozilla.org/Security/Server_Side_TLS.

Проверить конфигурацию можно на testssl.sh.

Разработчики пишут комментарии (обычный невыполняемый текст по всему коду), чтобы помочь себе и другим понять, что происходит в программе. Однако иногда такие комментарии содержат то, чего там не должно быть: пароли баз данных или другие секреты, сведения о компании или пользователях, которыми не следует делиться, или иную конфиденциальную информацию. Комментарии, помещенные во внешний код (JavaScript, HTML, CSS), не всегда удаляются во время упаковки, и реверс-инженер легко может их найти. Поэтому никогда нельзя разглашать конфиденциальные сведения в комментариях. Никогда.

СОВЕТ. Существует множество инструментов, доступных для CI/CD-конвейера или для сканирования репозитория, которые ищут секретную информацию в коде. Всегда используйте один из них!

Резервное копирование и восстановление

Следует регулярно производить резервное копирование всех данных, которые использует, создает или хранит приложение (в соответствии с политикой классификации данных организации), причем для этой цели обычно выделяется второе, географически удаленное место. Система должна быть способна восстановить данные в случае внедрения вредоносного ПО, вируса-вымогателя или нарушения безопасности. Процедуры резервного копирования и восстановления должны быть протестированы и отработаны на практике.