Вопрос или проблема
Изучая безопасность веб-сайтов, я задумался о том, чтобы спрятать свой инструмент для управления куками для аутентификации, поместив его на бэкенд-сервер “API”, и чтобы фронтенд-сервер “веб” обращался к этому бэкенд-серверу для получения/установки куков.
Например:
- ФронтендA браузер отправляет запрос на сервер ФронтендаA для входа в систему.
- Сервер ФронтендаA обращается к серверу БэкендаB с куками ФронтендаA в формате JSON.
- БэкендB принимает куки в формате JSON в запросе, обрабатывает их / выполняет аутентификацию, а затем создает “ответные” куки.
- БэкендB отправляет “ответные” куки обратно на сервер ФронтендаA.
- Сервер ФронтендаA записывает куки в заголовок куки в ответе, отправляя куки обратно корректно в браузер ФронтендаA.
Это небезопасно?
Что происходит на шаге #2? Я не эксперт в компьютерной / сетевой архитектуре, чтобы быстро это представить.
- Браузер отправляет куки, зашифрованные для бэкенд-сервера, скажем, на AWS.
- Сервер AWS отправляет их на другой ПУБЛИЧНЫЙ адрес (например, example.com/api).
- Сервер БэкендаB — это другой сервер AWS, который с этим справляется.
Таким образом, это фактически два сервера AWS, общающихся с куками в незашифрованном виде.
Не стоит ли добавить какую-то форму шифрования здесь? (Что было бы уместно)?
Или это нереально, чтобы кто-то смог перехватить это? Практически говоря, кажется, что кто-то должен стоять вне дата-центров AWS, чтобы перехватить данные. Но подождите, может быть, когда это в эфире, как радиосигналы, кто-то мог бы их поймать и перехватить куки?
Как это работает на самом деле? Пожалуйста, упростите это для меня немного.
Примечание: Все публичные интернет-домены будут использовать HTTPS.
Ответ или решение
Альтернативные способы передачи авторизационных данных между серверами: Разбор возможностей безопасности
Вопрос о безопасности передачи аутентификационных данных, таких как куки, через JSON между серверами становится всё более актуальным в контексте разработки веб-приложений. Ваша схема передачи данных включает два сервера: FrontendA (фронтенд-сервер) и BackendB (бэкэнд-сервер). Рассмотрим потенциальные угрозы в этом процессе и предложим более безопасные альтернативы.
Анализ текущей схемы передачи данных
На первом этапе ваш FrontendA сервирует клиенту запрос на авторизацию. Далее, при вызове BackendB, куки передаются в виде JSON. Рассмотрим, что происходит на этом этапе:
- Соединение создаётся между браузером и FrontendA через HTTPS, что обеспечивает начальную защиту данных.
- При передаче запросов от FrontendA к BackendB через сеть, конфиденциальные данные (включая куки) могут потенциально быть перехвачены, если соединение не защищено.
- Если FrontendA и BackendB находятся в разных регионах или на разных серверах, существует риск, что передача данных может происходить по менее безопасным каналам, даже если оба сервера защищены.
Потенциальные угрозы
- Сниффинг трафика: Если трафик не зашифрован (например, когда используется HTTP вместо HTTPS), злоумышленник может перехватить данные.
- Атаки “человек посередине” (MITM): Если злоумышленник сумеет установить соединение между вами и BackendB, он сможет манипулировать или перехватывать данные.
- Ошибки конфигурации или уязвимости: Технические ошибки в инфраструктуре могут привести к утечке данных.
Безопасные альтернативы передачи данных
Чтобы повысить уровень безопасности передаваемых данных, можно рассмотреть несколько подходов:
-
Использование токенов доступа: Вместо передачи куки напрямую, рассмотрите возможность использования JSON Web Tokens (JWT). JWT могут быть подписаны и зашифрованы, обеспечивая защиту данных на всех этапах передачи.
-
Полное шифрование данных: Если вы всё же решите использовать куки в JSON, подумайте о шифровании данных на уровне приложения. Используйте такие алгоритмы, как AES, для шифрования содержимого перед отправкой на BackendB.
-
Безопасные каналы связи: Всегда используйте HTTPS для всех коммуникаций между серверами. Это снизит риск перехвата данных в полете.
-
Установка безопасных заголовков: Используйте заголовки безопасности, такие как
Content-Security-Policy,X-Content-Type-Options, иX-Frame-Options, чтобы уменьшить риски атак на приложении. -
Регулярные аудиты безопасности: Проводите регулярные проверки и тестирования безопасности вашей инфраструктуры, чтобы выявлять и устранять уязвимости.
-
Отказ от клиентских куки для передачи: Рассмотрите возможность использования серверной сессии вместо передачи куки, что значительно уменьшит объем передаваемой информации.
Заключение
Использование протокола HTTPS и подходов, таких как токены доступа и шифрование, может значительно улучшить вашу защиту данных во время передачи. Вы также должны оценить необходимость передачи куки вообще. Всегда лучше минимизировать риски, отказываясь от ненужной передачи конфиденциальной информации.
Безопасность веб-приложений — это постоянный процесс. Следуйте лучшим практикам и оставайтесь в курсе последних угроз, чтобы обеспечить защиту для вашей организации и пользователей.