POST-запросы между доменами: правила и защита от подделки

Быстрый ответ

Для решения задачи передачи данных между доменами с использованием POST-запросов, следует применить технологию CORS. Это потребует настройки сервера таким образом, чтобы в ответах на POST-запросы добавлялся заголовок Access-Control-Allow-Origin. В итоге, для администратора сервера это будет выглядеть следующим образом:

// Применяем CORS!
res.header("Access-Control-Allow-Origin", "*"); // вместо звёздочки укажите ваш домен

Если у вас нет доступа к настройке сервера, альтернативным решением станет использование серверного прокси. Далее представлен пример кода на PHP, который может исполнить роль прокси для перенаправления данных на внешний ресурс:

<?php
// Ваш прокси-сервер!
$context = stream_context_create(['http' => [
  'method'  => 'POST',
  'header'  => 'Content-Type: application/x-www-form-urlencoded',
  'content' => http_build_query($_POST)
]]);
// Готово, POST-запрос отправлен!
echo file_get_contents('http://externaldomain.com/target', false, $context);
?>

Нельзя полагаться исключительно на клиентских методах—если целевой сервис не поддерживает CORS или JSONP, браузерные механизмы обеспечения безопасности это легко раскроют. Уделяйте должное внимание стандартам безопасности и законодательству о конфиденциальности, столь же уважительно, как и вашим родственникам.

Основы политики одного источника

Политика одного источника — это маяк, руководящий вас в море передачи данных между доменами с использованием POST-запросов. Это принцип веб-безопасности, определяющий, каким образом скрипты и документы одного источника могут взаимодействовать с ресурсами другого происхождения.

Обход ограничений

У политики одного источника, как у любого правила, имеются исключения — она не мешает отправке POST-запросов на разные домены. Чтобы избежать этих ограничений, можно использовать атрибут action в форме, указав URL целевого сервера. Однако не забывайте: если ответ придёт не от того же источника и CORS настроен неверно, возвращённые данные могут оказаться недоступными.

Работа с токенами безопасности

Оградите вашы формы от атак межсайтовой подделки запросов, используя токены CSRF. Это поможет гарантировать, что отправка формы осуществлена прямо с вашего сайта, а не злоумышленником, направляющим поддельный запрос.

Разбираемся с атаками CSRF

Как правило, атаки CSRF совершаются через несанкционированные операции с формами. Злоумышленники могут устроить пользователям выполнить неприятные действия, используя их установленные доверительные связи с сайтом. Главная опасность атак CSRF заключается не в прочтении данных, а в их изменении, что может вызвать нежелательные последствия.

Визуализация

В качестве аналогии представьте отправку письма (📩) в иностранное государство (🌐) через различные почтовые службы:

Метод отправки | Доступность | Проверка безопасности | Скорость
----------------|-------------|----------------------|---------
Собственная почтовая служба (тот же домен) | 🏡 -> 🏡 | Минимальная | 🚀
Международная пересылка (разные домены) | 🏡 -> ✈️ -> 🌐 -> 🏡 | Тщательная | 🛩

Передача данных между доменами с помощью POST-запросов аналогична международной переписке: необходимо соблюдать определённые правила (CORS), иногда привлекать посредника (прокси или API) для корректной доставки данных.

Размышления о взаимодействии клиента и сервера

Требуется ли прочесть ответ?

При отправке прямого POST-запроса из формы, вы можете столкнуться с проблемами при получении ответа с другого домена из-за ограничений браузера.

Подробнее об этом расскажет наш спикер на видео

Бережное обращение с серверной стороной

Серверный код вашего приложения должен надёжно обрабатывать данные. Он должен правильно принимать значения из различных источников и проводить все необходимые проверки и валидацию.

Защита конфиденциальности

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

Быстрые советы и примеры кода

Проксирование на стороне сервера

Разверните на серверной стороне некое подобие рыцаря, который принимает POST-запросы и перенаправляет их на другой домен. Такой подход поможет вам контролировать запросы и реализовывать требования безопасности.

Будьте осторожны с JSONP

Метод JSONP позволяет преодолеть ограничения политики одного источника, используя тег script. Однако он предназначен только для GET-запросов и имеет более слабые механизмы безопасности, чем CORS.

Библиотеки, поддерживающие CORS

Использование таких инструментов, как jQuery, и API типа Fetch, может существенно упростить выполнение запросов CORS, помогая преодолеть проблемы совместимости между различными браузерами.

Полезные материалы

1. Методы обхода политики одного источника — обсуждения на Stack Overflow о междоменных Ajax-запросах.
2. Политика одного источника – безопасность в вебе | MDN — краткий обзор основ и целей политики одного источника.
3. Поддержка междоменных запросов (CORS) – HTTP | MDN — подробное руководство по CORS от MDN Web Docs.
4. Разъяснение JSONP с примерами от SitePoint — коллекция учебных материалов и примеров использования JSONP для обработки междоменных запросов.
5. Предотвращение межсайтовой подделки запроса (CSRF) – шпаргалка OWASP — откройте секреты безопасной обработки междоменных POST-запросов в соответствии с рекомендациями OWASP.
6. Использование Fetch API – Веб-API | MDN — обучающие статьи по использованию Fetch API для решения задач междоменных запросов, как настоящий профессионал.