Kommunikation mellan olika ursprung: Säkerhetsmönster med PostMessage API

I den moderna webben behöver applikationer ofta interagera med resurser från olika ursprung. Same-Origin Policy (SOP) är en avgörande säkerhetsmekanism som hindrar skript från att komma åt resurser från ett annat ursprung. Det finns dock legitima scenarier där kommunikation mellan olika ursprung är nödvändig. postMessage-API:et erbjuder en kontrollerad mekanism för att uppnå detta, men det är avgörande att förstå dess potentiella säkerhetsrisker och implementera lämpliga säkerhetsmönster.

Förståelse för Same-Origin Policy (SOP)

Same-Origin Policy är ett grundläggande säkerhetskoncept i webbläsare. Det hindrar webbsidor från att göra förfrågningar till en annan domän än den som serverade webbsidan. Ett ursprung definieras av schemat (protokoll), värden (domän) och porten. Om någon av dessa skiljer sig åt, anses ursprungen vara olika. Till exempel:

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

Dessa är alla olika ursprung, och SOP begränsar direkt skriptåtkomst mellan dem.

Introduktion till PostMessage API

postMessage-API:et tillhandahåller en säker och kontrollerad mekanism för kommunikation mellan olika ursprung. Det tillåter skript att skicka meddelanden till andra fönster (t.ex. iframes, nya fönster eller flikar), oavsett deras ursprung. Det mottagande fönstret kan sedan lyssna efter dessa meddelanden och behandla dem därefter.

Den grundläggande syntaxen för att skicka ett meddelande är:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: En referens till målfönstret (t.ex. window.parent, iframe.contentWindow, eller ett fönsterobjekt erhållet från window.open).
• message: Datan du vill skicka. Detta kan vara vilket JavaScript-objekt som helst som kan serialiseras (t.ex. strängar, nummer, objekt, arrayer).
• targetOrigin: Anger det ursprung till vilket du vill skicka meddelandet. Detta är en avgörande säkerhetsparameter.

På mottagarsidan behöver du lyssna efter message-händelsen:

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

event-objektet innehåller följande egenskaper:

• event.data: Meddelandet som skickats av det andra fönstret.
• event.origin: Ursprunget för fönstret som skickade meddelandet.
• event.source: En referens till fönstret som skickade meddelandet.

Säkerhetsrisker och sårbarheter

Även om postMessage erbjuder ett sätt att kringgå SOP-restriktioner, introducerar det också potentiella säkerhetsrisker om det inte implementeras noggrant. Här är några vanliga sårbarheter:

1. Felmatchning av målursprung

Att misslyckas med att validera egenskapen event.origin är en kritisk sårbarhet. Om mottagaren blint litar på meddelandet kan vilken webbplats som helst skicka skadlig data. Verifiera alltid att event.origin matchar det förväntade ursprunget innan meddelandet behandlas.

Exempel (Sårbar kod):

window.addEventListener('message', function(event) {
  // GÖR INTE SÅ HÄR!
  processMessage(event.data);
});

Exempel (Säker kod):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Received message from untrusted origin:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. Datainjektion

Att behandla den mottagna datan (event.data) som körbar kod eller att direkt injicera den i DOM kan leda till Cross-Site Scripting (XSS)-sårbarheter. Sanera och validera alltid den mottagna datan innan du använder den.

Exempel (Sårbar kod):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // GÖR INTE SÅ HÄR!
  }
});

Exempel (Säker kod):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // Implementera en korrekt saneringsfunktion
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // Implementera robust saneringslogik här.
    // Använd till exempel DOMPurify eller ett liknande bibliotek
    return DOMPurify.sanitize(data);
}

3. Man-in-the-Middle (MITM)-attacker

Om kommunikation sker över en osäker kanal (HTTP) kan en MITM-angripare fånga upp och modifiera meddelandena. Använd alltid HTTPS för säker kommunikation.

4. Cross-Site Request Forgery (CSRF)

Om mottagaren utför åtgärder baserat på det mottagna meddelandet utan ordentlig validering, kan en angripare potentiellt förfalska meddelanden för att lura mottagaren att utföra oavsiktliga handlingar. Implementera CSRF-skyddsmekanismer, som att inkludera en hemlig token i meddelandet och verifiera den på mottagarsidan.

5. Använda jokertecken i targetOrigin

Att sätta targetOrigin till * tillåter vilket ursprung som helst att ta emot meddelandet. Detta bör undvikas om det inte är absolut nödvändigt, eftersom det omintetgör syftet med ursprungsbaserad säkerhet. Om du måste använda *, se till att du implementerar andra starka säkerhetsåtgärder, som meddelandeautentiseringskoder (MACs).

Exempel (Undvik detta):

otherWindow.postMessage(message, '*'); // Undvik att använda '*' om det inte är absolut nödvändigt

Säkerhetsmönster och bästa praxis

För att mildra riskerna associerade med postMessage, följ dessa säkerhetsmönster och bästa praxis:

1. Strikt ursprungsvalidering

Validera alltid egenskapen event.origin på mottagarsidan. Jämför den mot en fördefinierad lista över betrodda ursprung. Använd strikt likhet (===) för jämförelsen.

2. Datasanering och validering

Sanera och validera all data som tas emot via postMessage innan den används. Använd lämpliga saneringstekniker beroende på hur datan kommer att användas (t.ex. HTML-escapning, URL-kodning, indatavalidering). Använd bibliotek som DOMPurify för att sanera HTML.

3. Meddelandeautentiseringskoder (MACs)

Inkludera en meddelandeautentiseringskod (Message Authentication Code, MAC) i meddelandet för att säkerställa dess integritet och äkthet. Avsändaren beräknar MAC-koden med hjälp av en delad hemlig nyckel och inkluderar den i meddelandet. Mottagaren omberäknar MAC-koden med samma delade hemliga nyckel och jämför den med den mottagna MAC-koden. Om de matchar anses meddelandet vara autentiskt och oförändrat.

Exempel (Använda HMAC-SHA256):

// Avsändare
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);
}

// Mottagare
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Received message from untrusted origin:', 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('Message is authentic!');
    processMessage(message); // Fortsätt med att bearbeta meddelandet
  } else {
    console.error('Message signature verification failed!');
  }
}

Viktigt: Den delade hemliga nyckeln måste genereras och lagras säkert. Undvik att hårdkoda nyckeln i koden.

4. Använda Nonce och tidsstämplar

För att förhindra reprisattacker, inkludera ett unikt nonce (nummer som används en gång) och en tidsstämpel i meddelandet. Mottagaren kan då verifiera att noncen inte har använts tidigare och att tidsstämpeln är inom en acceptabel tidsram. Detta minskar risken för att en angripare återupprepar tidigare uppsnappade meddelanden.

5. Principen om minsta privilegium

Bevilja endast de minimala nödvändiga privilegierna till det andra fönstret. Om det andra fönstret till exempel bara behöver läsa data, tillåt det inte att skriva data. Designa ditt kommunikationsprotokoll med principen om minsta privilegium i åtanke.

6. Content Security Policy (CSP)

Använd Content Security Policy (CSP) för att begränsa från vilka källor skript kan laddas och vilka åtgärder skript kan utföra. Detta kan hjälpa till att mildra effekten av XSS-sårbarheter som kan uppstå från felaktig hantering av postMessage-data.

7. Indatavalidering

Validera alltid strukturen och formatet på den mottagna datan. Definiera ett tydligt meddelandeformat och se till att den mottagna datan överensstämmer med detta format. Detta hjälper till att förhindra oväntat beteende och sårbarheter.

8. Säker dataseriering

Använd ett säkert dataserieringsformat, som JSON, för att serialisera och deserialisera meddelanden. Undvik att använda format som tillåter kodexekvering, som eval() eller Function().

9. Begränsa meddelandestorlek

Begränsa storleken på meddelanden som skickas via postMessage. Stora meddelanden kan konsumera överdrivna resurser och potentiellt leda till överbelastningsattacker.

10. Regelbundna säkerhetsgranskningar

Genomför regelbundna säkerhetsgranskningar av din kod för att identifiera och åtgärda potentiella sårbarheter. Var särskilt uppmärksam på implementeringen av postMessage och se till att all bästa praxis för säkerhet följs.

Exempelscenario: Säker kommunikation mellan en Iframe och dess förälder

Tänk dig ett scenario där en iframe som finns på https://iframe.example.com behöver kommunicera med sin föräldrasida som finns på https://parent.example.com. Iframen behöver skicka användardata till föräldrasidan för bearbetning.

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

// Generera en delad hemlig nyckel (ersätt med en säker nyckelgenereringsmetod)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// Hämta användardata
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// Skicka användardata till föräldrasidan
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);

Föräldrasida (https://parent.example.com):

// Delad hemlig nyckel (måste matcha iframens nyckel)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('Received message from untrusted origin:', 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('Message is authentic!');
    // Bearbeta användardata
    console.log('User data:', userData);
  } else {
    console.error('Message signature verification failed!');
  }
});

Viktiga anmärkningar:

• Ersätt YOUR_SECURE_SHARED_SECRET med en säkert genererad delad hemlig nyckel.
• Den delade hemliga nyckeln måste vara densamma i både iframen och på föräldrasidan.
• Detta exempel använder HMAC-SHA256 för meddelandeautentisering.

Slutsats

postMessage-API:et är ett kraftfullt verktyg för att möjliggöra kommunikation mellan olika ursprung i webbapplikationer. Det är dock avgörande att förstå de potentiella säkerhetsriskerna och implementera lämpliga säkerhetsmönster för att mildra dessa risker. Genom att följa de säkerhetsmönster och bästa praxis som beskrivs i denna guide kan du på ett säkert sätt använda postMessage för att bygga robusta och säkra webbapplikationer.

Kom ihåg att alltid prioritera säkerhet och hålla dig uppdaterad med de senaste bästa praxis för säkerhet inom webbutveckling. Granska regelbundet din kod och dina säkerhetskonfigurationer för att säkerställa att dina applikationer är skyddade mot potentiella sårbarheter.