Междудомейнна комуникация: Модели за сигурност с PostMessage API

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

Разбиране на Политиката за същия произход (SOP)

Политиката за същия произход е фундаментална концепция за сигурност в уеб браузърите. Тя ограничава уеб страниците да правят заявки към домейн, различен от този, който е обслужил уеб страницата. Произходът се определя от схемата (протокола), хоста (домейна) и порта. Ако някой от тези елементи се различава, произходите се считат за различни. Например:

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

Всички това са различни произходи и SOP ограничава директния достъп на скриптове между тях.

Представяне на PostMessage API

postMessage API предоставя безопасен и контролиран механизъм за междудомейнна комуникация. Той позволява на скриптове да изпращат съобщения до други прозорци (напр. iframes, нови прозорци или табове), независимо от техния произход. Получаващият прозорец може да слуша за тези съобщения и да ги обработва съответно.

Основният синтаксис за изпращане на съобщение е:

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. Инжектиране на данни

Третирането на получените данни (event.data) като изпълним код или директното им инжектиране в DOM може да доведе до уязвимости от тип Cross-Site Scripting (XSS). Винаги почиствайте (sanitize) и валидирайте получените данни, преди да ги използвате.

Пример (Уязвим код):

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. Атаки от типа „Човек по средата“ (Man-in-the-Middle - MITM)

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

4. Фалшифициране на заявки между сайтове (Cross-Site Request Forgery - CSRF)

Ако получателят извършва действия въз основа на полученото съобщение без подходяща валидация, нападател може потенциално да фалшифицира съобщения, за да подмами получателя да извърши нежелани действия. Приложете механизми за защита от CSRF, като например включване на таен токен в съобщението и неговата проверка от страна на получателя.

5. Използване на заместващи символи (Wildcards) в targetOrigin

Задаването на targetOrigin на * позволява на всеки произход да получи съобщението. Това трябва да се избягва, освен ако не е абсолютно необходимо, тъй като обезсмисля целта на сигурността, базирана на произход. Ако трябва да използвате *, уверете се, че прилагате други силни мерки за сигурност, като например кодове за удостоверяване на съобщения (MACs).

Пример (Избягвайте това):

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

Модели за сигурност и най-добри практики

За да смекчите рисковете, свързани с postMessage, следвайте тези модели за сигурност и най-добри практики:

1. Стриктна валидация на произхода

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

2. Почистване и валидация на данни

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

3. Кодове за удостоверяване на съобщения (MACs)

Включете Код за удостоверяване на съобщение (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 и времеви маркери (Timestamps)

За да предотвратите атаки с повторно възпроизвеждане (replay attacks), включете уникален nonce (число, използвано веднъж) и времеви маркер в съобщението. Получателят може да провери дали nonce не е бил използван преди и дали времевият маркер е в рамките на приемлив период. Това смекчава риска нападател да възпроизведе повторно прихванати съобщения.

5. Принцип на най-малките привилегии

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

6. Политика за сигурност на съдържанието (Content Security Policy - CSP)

Използвайте Политика за сигурност на съдържанието (CSP), за да ограничите източниците, от които могат да се зареждат скриптове, и действията, които скриптовете могат да извършват. Това може да помогне за смекчаване на въздействието на XSS уязвимости, които могат да възникнат от неправилна обработка на данни от postMessage.

7. Валидация на входа

Винаги валидирайте структурата и формата на получените данни. Определете ясен формат на съобщението и се уверете, че получените данни отговарят на този формат. Това помага за предотвратяване на неочаквано поведение и уязвимости.

8. Сигурна сериализация на данни

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

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

Ограничете размера на съобщенията, изпращани чрез postMessage. Големите съобщения могат да консумират прекомерни ресурси и потенциално да доведат до атаки за отказ на услуга (denial-of-service).

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 за удостоверяване на съобщения.

Заключение

postMessage API е мощен инструмент за осъществяване на междудомейнна комуникация в уеб приложения. Въпреки това е изключително важно да се разбират потенциалните рискове за сигурността и да се прилагат подходящи модели за защита, за да се смекчат тези рискове. Като следвате моделите за сигурност и най-добрите практики, описани в това ръководство, можете сигурно да използвате postMessage за изграждане на стабилни и сигурни уеб приложения.

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