Междоменное взаимодействие: Паттерны безопасности с PostMessage API

В современном вебе приложениям часто требуется взаимодействовать с ресурсами из разных источников (origins). Политика одного источника (Same-Origin Policy, SOP) — это ключевой механизм безопасности, который запрещает скриптам доступ к ресурсам из другого источника. Однако существуют легитимные сценарии, когда междоменное взаимодействие необходимо. API postMessage предоставляет контролируемый механизм для этого, но крайне важно понимать его потенциальные риски безопасности и применять соответствующие паттерны защиты.

Понимание Политики одного источника (SOP)

Политика одного источника — это фундаментальная концепция безопасности в веб-браузерах. Она запрещает веб-страницам делать запросы к домену, отличному от того, с которого была загружена сама страница. Источник (origin) определяется схемой (протоколом), хостом (доменом) и портом. Если хотя бы один из этих компонентов отличается, источники считаются разными. Например:

• https://example.com
• https://www.example.com
• http://example.com
• https://example.com:8080

Все это — разные источники, и SOP ограничивает прямой доступ скриптов между ними.

Знакомство с PostMessage API

API postMessage предоставляет безопасный и контролируемый механизм для междоменного взаимодействия. Он позволяет скриптам отправлять сообщения другим окнам (например, iframe, новым окнам или вкладкам) независимо от их источника. Принимающее окно может прослушивать эти сообщения и обрабатывать их соответствующим образом.

Базовый синтаксис для отправки сообщения:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: Ссылка на целевое окно (например, window.parent, iframe.contentWindow или объект окна, полученный из window.open).
• message: Данные, которые вы хотите отправить. Это может быть любой объект JavaScript, который можно сериализовать (например, строки, числа, объекты, массивы).
• targetOrigin: Указывает источник, которому вы хотите отправить сообщение. Это критически важный параметр безопасности.

На принимающей стороне необходимо прослушивать событие message:

window.addEventListener('message', function(event) {
  // ...
});

Объект event содержит следующие свойства:

• event.data: Сообщение, отправленное другим окном.
• event.origin: Источник окна, отправившего сообщение.
• event.source: Ссылка на окно, отправившее сообщение.

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

Хотя postMessage позволяет обойти ограничения SOP, он также создает потенциальные риски безопасности при неосторожной реализации. Вот некоторые распространенные уязвимости:

1. Несоответствие целевого источника (Target Origin)

Отсутствие проверки свойства event.origin является критической уязвимостью. Если получатель слепо доверяет сообщению, любой веб-сайт может отправить вредоносные данные. Всегда проверяйте, что event.origin соответствует ожидаемому источнику, прежде чем обрабатывать сообщение.

Пример (уязвимый код):

window.addEventListener('message', function(event) {
  // НЕ ДЕЛАЙТЕ ТАК!
  processMessage(event.data);
});

Пример (безопасный код):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Получено сообщение из недоверенного источника:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. Внедрение данных (Data Injection)

Обработка полученных данных (event.data) как исполняемого кода или их прямое внедрение в DOM может привести к уязвимостям межсайтового скриптинга (XSS). Всегда очищайте и проверяйте полученные данные перед их использованием.

Пример (уязвимый код):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // НЕ ДЕЛАЙТЕ ТАК!
  }
});

Пример (безопасный код):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // Реализуйте правильную функцию очистки
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // Реализуйте надежную логику очистки здесь.
    // Например, используйте DOMPurify или подобную библиотеку
    return DOMPurify.sanitize(data);
}

3. Атаки «человек посередине» (MITM)

Если обмен данными происходит по незащищенному каналу (HTTP), злоумышленник MITM может перехватить и изменить сообщения. Всегда используйте HTTPS для безопасной связи.

4. Межсайтовая подделка запроса (CSRF)

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

5. Использование wildcard (*) в targetOrigin

Установка targetOrigin в значение * позволяет любому источнику получить сообщение. Этого следует избегать, если в этом нет крайней необходимости, так как это сводит на нет цель безопасности на основе источника. Если вы вынуждены использовать *, убедитесь, что вы применяете другие надежные меры безопасности, такие как коды аутентификации сообщений (MAC).

Пример (избегайте этого):

otherWindow.postMessage(message, '*'); // Избегайте использования '*', если в этом нет крайней необходимости

Паттерны безопасности и лучшие практики

Чтобы снизить риски, связанные с postMessage, следуйте этим паттернам безопасности и лучшим практикам:

1. Строгая проверка источника

Всегда проверяйте свойство event.origin на стороне получателя. Сравнивайте его с заранее определенным списком доверенных источников. Используйте строгое равенство (===) для сравнения.

2. Очистка и проверка данных

Очищайте и проверяйте все данные, полученные через postMessage, перед их использованием. Используйте соответствующие методы очистки в зависимости от того, как будут использоваться данные (например, экранирование HTML, кодирование URL, проверка ввода). Используйте библиотеки, такие как DOMPurify, для очистки HTML.

3. Коды аутентификации сообщений (MAC)

Включайте код аутентификации сообщения (MAC) в сообщение, чтобы обеспечить его целостность и подлинность. Отправитель вычисляет MAC с помощью общего секретного ключа и включает его в сообщение. Получатель пересчитывает MAC, используя тот же общий секретный ключ, и сравнивает его с полученным MAC. Если они совпадают, сообщение считается подлинным и неизмененным.

Пример (использование HMAC-SHA256):

// Отправитель
async function sendMessage(message, targetOrigin, sharedSecret) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: message,
    signature: signatureHex
  };

  otherWindow.postMessage(securedMessage, targetOrigin);
}

// Получатель
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Получено сообщение из недоверенного источника:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const message = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  if (signatureHex === receivedSignature) {
    console.log('Сообщение подлинное!');
    processMessage(message); // Продолжить обработку сообщения
  } else {
    console.error('Проверка подписи сообщения не удалась!');
  }
}

Важно: Общий секретный ключ должен быть безопасно сгенерирован и сохранен. Избегайте жесткого кодирования ключа в коде.

4. Использование Nonce и временных меток

Для предотвращения атак повторного воспроизведения (replay attacks) включайте в сообщение уникальный одноразовый номер (nonce) и временную метку. Получатель может проверить, что nonce не использовался ранее, и что временная метка находится в допустимом временном диапазоне. Это снижает риск того, что злоумышленник повторно отправит ранее перехваченные сообщения.

5. Принцип наименьших привилегий

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

6. Политика безопасности контента (CSP)

Используйте Политику безопасности контента (CSP), чтобы ограничить источники, из которых могут загружаться скрипты, и действия, которые скрипты могут выполнять. Это может помочь смягчить последствия уязвимостей XSS, которые могут возникнуть из-за неправильной обработки данных postMessage.

7. Проверка ввода

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

8. Безопасная сериализация данных

Используйте безопасный формат сериализации данных, такой как JSON, для сериализации и десериализации сообщений. Избегайте использования форматов, которые допускают выполнение кода, таких как eval() или Function().

9. Ограничение размера сообщения

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

10. Регулярные аудиты безопасности

Проводите регулярные аудиты безопасности вашего кода для выявления и устранения потенциальных уязвимостей. Уделяйте пристальное внимание реализации postMessage и убедитесь, что все лучшие практики безопасности соблюдаются.

Пример сценария: безопасное взаимодействие между Iframe и его родительской страницей

Рассмотрим сценарий, в котором iframe, размещенный на https://iframe.example.com, должен взаимодействовать со своей родительской страницей, размещенной на https://parent.example.com. Iframe должен отправить данные пользователя на родительскую страницу для обработки.

Iframe (https://iframe.example.com):

// Сгенерируйте общий секретный ключ (замените на безопасный метод генерации ключа)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// Получить данные пользователя
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// Отправить данные пользователя на родительскую страницу
async function sendUserData(userData) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: userData,
    signature: signatureHex
  };
  parent.postMessage(securedMessage, 'https://parent.example.com');
}

sendUserData(userData);

Родительская страница (https://parent.example.com):

// Общий секретный ключ (должен совпадать с ключом iframe)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('Получено сообщение из недоверенного источника:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const userData = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');


  if (signatureHex === receivedSignature) {
    console.log('Сообщение подлинное!');
    // Обработать данные пользователя
    console.log('Данные пользователя:', userData);
  } else {
    console.error('Проверка подписи сообщения не удалась!');
  }
});

Важные примечания:

• Замените YOUR_SECURE_SHARED_SECRET на безопасно сгенерированный общий секретный ключ.
• Общий секретный ключ должен быть одинаковым как в iframe, так и на родительской странице.
• В этом примере для аутентификации сообщений используется HMAC-SHA256.

Заключение

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

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