Comunicazione Cross-Origin: Pattern di Sicurezza con l'API PostMessage

Nel web moderno, le applicazioni hanno spesso bisogno di interagire con risorse provenienti da origini diverse. La Same-Origin Policy (SOP) è un meccanismo di sicurezza cruciale che impedisce agli script di accedere a risorse da un'origine diversa. Tuttavia, esistono scenari legittimi in cui la comunicazione cross-origin è necessaria. L'API postMessage fornisce un meccanismo controllato per raggiungere questo obiettivo, ma è fondamentale comprenderne i potenziali rischi per la sicurezza e implementare adeguati pattern di sicurezza.

Comprendere la Same-Origin Policy (SOP)

La Same-Origin Policy è un concetto di sicurezza fondamentale nei browser web. Limita le pagine web dall'effettuare richieste a un dominio diverso da quello che ha servito la pagina web stessa. Un'origine è definita dallo schema (protocollo), host (dominio) e porta. Se uno qualsiasi di questi differisce, le origini sono considerate diverse. Ad esempio:

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

Queste sono tutte origini diverse e la SOP limita l'accesso diretto degli script tra di loro.

Introduzione all'API PostMessage

L'API postMessage fornisce un meccanismo sicuro e controllato per la comunicazione cross-origin. Permette agli script di inviare messaggi ad altre finestre (ad es. iframe, nuove finestre o schede), indipendentemente dalla loro origine. La finestra ricevente può quindi rimanere in ascolto di questi messaggi ed elaborarli di conseguenza.

La sintassi di base per inviare un messaggio è:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: Un riferimento alla finestra di destinazione (ad es. window.parent, iframe.contentWindow, o un oggetto finestra ottenuto da window.open).
• message: I dati che vuoi inviare. Può essere qualsiasi oggetto JavaScript che può essere serializzato (ad es. stringhe, numeri, oggetti, array).
• targetOrigin: Specifica l'origine a cui vuoi inviare il messaggio. Questo è un parametro di sicurezza cruciale.

Dal lato ricevente, è necessario mettersi in ascolto dell'evento message:

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

L'oggetto event contiene le seguenti proprietà:

• event.data: Il messaggio inviato dall'altra finestra.
• event.origin: L'origine della finestra che ha inviato il messaggio.
• event.source: Un riferimento alla finestra che ha inviato il messaggio.

Rischi di Sicurezza e Vulnerabilità

Sebbene postMessage offra un modo per aggirare le restrizioni della SOP, introduce anche potenziali rischi per la sicurezza se non implementato con attenzione. Ecco alcune vulnerabilità comuni:

1. Mancata Corrispondenza dell'Origine di Destinazione

La mancata validazione della proprietà event.origin è una vulnerabilità critica. Se il ricevitore si fida ciecamente del messaggio, qualsiasi sito web può inviare dati malevoli. Verifica sempre che event.origin corrisponda all'origine prevista prima di elaborare il messaggio.

Esempio (Codice Vulnerabile):

window.addEventListener('message', function(event) {
  // NON FARE QUESTO!
  processMessage(event.data);
});

Esempio (Codice Sicuro):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Messaggio ricevuto da un\'origine non attendibile:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. Iniezione di Dati

Trattare i dati ricevuti (event.data) come codice eseguibile o iniettarli direttamente nel DOM può portare a vulnerabilità di tipo Cross-Site Scripting (XSS). Sanifica e valida sempre i dati ricevuti prima di utilizzarli.

Esempio (Codice Vulnerabile):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // NON FARE QUESTO!
  }
});

Esempio (Codice Sicuro):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // Implementare una funzione di sanificazione adeguata
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // Implementare una logica di sanificazione robusta qui.
    // Ad esempio, usare DOMPurify o una libreria simile
    return DOMPurify.sanitize(data);
}

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

Se la comunicazione avviene su un canale non sicuro (HTTP), un attaccante MITM può intercettare e modificare i messaggi. Utilizza sempre HTTPS per una comunicazione sicura.

4. Cross-Site Request Forgery (CSRF)

Se il ricevitore esegue azioni basate sul messaggio ricevuto senza una corretta validazione, un attaccante potrebbe potenzialmente falsificare messaggi per indurre il ricevitore a compiere azioni non intenzionali. Implementa meccanismi di protezione CSRF, come includere un token segreto nel messaggio e verificarlo dal lato del ricevitore.

5. Utilizzo di Caratteri Jolly in targetOrigin

Impostare targetOrigin su * consente a qualsiasi origine di ricevere il messaggio. Questo dovrebbe essere evitato a meno che non sia assolutamente necessario, poiché vanifica lo scopo della sicurezza basata sull'origine. Se devi usare *, assicurati di implementare altre misure di sicurezza robuste, come i codici di autenticazione dei messaggi (MAC).

Esempio (Evitare Questo):

otherWindow.postMessage(message, '*'); // Evitare di usare '*' a meno che non sia assolutamente necessario

Pattern di Sicurezza e Best Practice

Per mitigare i rischi associati a postMessage, segui questi pattern di sicurezza e best practice:

1. Validazione Rigorosa dell'Origine

Valida sempre la proprietà event.origin dal lato del ricevitore. Confrontala con un elenco predefinito di origini attendibili. Usa un'uguaglianza stretta (===) per il confronto.

2. Sanificazione e Validazione dei Dati

Sanifica e valida tutti i dati ricevuti tramite postMessage prima di utilizzarli. Usa tecniche di sanificazione appropriate a seconda di come verranno utilizzati i dati (ad es. escaping HTML, codifica URL, validazione dell'input). Usa librerie come DOMPurify per la sanificazione dell'HTML.

3. Codici di Autenticazione dei Messaggi (MAC)

Includi un Codice di Autenticazione del Messaggio (MAC) nel messaggio per garantirne l'integrità e l'autenticità. Il mittente calcola il MAC utilizzando una chiave segreta condivisa e lo include nel messaggio. Il ricevitore ricalcola il MAC utilizzando la stessa chiave segreta condivisa e lo confronta con il MAC ricevuto. Se corrispondono, il messaggio è considerato autentico e non manomesso.

Esempio (Usando HMAC-SHA256):

// Mittente
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);
}

// Destinatario
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('Messaggio ricevuto da un\'origine non attendibile:', 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('Il messaggio è autentico!');
    processMessage(message); // Procedere con l'elaborazione del messaggio
  } else {
    console.error('Verifica della firma del messaggio fallita!');
  }
}

Importante: La chiave segreta condivisa deve essere generata e conservata in modo sicuro. Evita di inserire la chiave direttamente nel codice (hardcoding).

4. Utilizzo di Nonce e Timestamp

Per prevenire attacchi di tipo replay, includi un nonce univoco (numero usato una sola volta) e un timestamp nel messaggio. Il ricevitore può quindi verificare che il nonce non sia stato usato prima e che il timestamp rientri in un intervallo di tempo accettabile. Ciò mitiga il rischio che un attaccante possa riutilizzare messaggi intercettati in precedenza.

5. Principio del Minimo Privilegio

Concedi solo i privilegi minimi necessari all'altra finestra. Ad esempio, se l'altra finestra ha solo bisogno di leggere i dati, non permetterle di scriverli. Progetta il tuo protocollo di comunicazione tenendo a mente il principio del minimo privilegio.

6. Content Security Policy (CSP)

Utilizza la Content Security Policy (CSP) per limitare le fonti da cui gli script possono essere caricati e le azioni che gli script possono eseguire. Questo può aiutare a mitigare l'impatto delle vulnerabilità XSS che potrebbero derivare da una gestione impropria dei dati di postMessage.

7. Validazione dell'Input

Valida sempre la struttura e il formato dei dati ricevuti. Definisci un formato di messaggio chiaro e assicurati che i dati ricevuti siano conformi a questo formato. Questo aiuta a prevenire comportamenti imprevisti e vulnerabilità.

8. Serializzazione Sicura dei Dati

Utilizza un formato di serializzazione dei dati sicuro, come JSON, per serializzare e deserializzare i messaggi. Evita di usare formati che consentono l'esecuzione di codice, come eval() o Function().

9. Limitare la Dimensione dei Messaggi

Limita la dimensione dei messaggi inviati tramite postMessage. Messaggi di grandi dimensioni possono consumare risorse eccessive e potenzialmente portare ad attacchi di tipo denial-of-service.

10. Audit di Sicurezza Regolari

Conduci audit di sicurezza regolari del tuo codice per identificare e risolvere potenziali vulnerabilità. Presta particolare attenzione all'implementazione di postMessage e assicurati che tutte le best practice di sicurezza siano seguite.

Scenario di Esempio: Comunicazione Sicura tra un Iframe e il suo Parent

Considera uno scenario in cui un iframe ospitato su https://iframe.example.com deve comunicare con la sua pagina parent ospitata su https://parent.example.com. L'iframe deve inviare i dati dell'utente alla pagina parent per l'elaborazione.

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

// Genera una chiave segreta condivisa (sostituire con un metodo di generazione di chiavi sicuro)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// Ottieni i dati dell'utente
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// Invia i dati dell'utente alla pagina parent
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);

Pagina Parent (https://parent.example.com):

// Chiave segreta condivisa (deve corrispondere alla chiave dell'iframe)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('Messaggio ricevuto da un\'origine non attendibile:', 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('Il messaggio è autentico!');
    // Elabora i dati dell'utente
    console.log('Dati utente:', userData);
  } else {
    console.error('Verifica della firma del messaggio fallita!');
  }
});

Note Importanti:

• Sostituire YOUR_SECURE_SHARED_SECRET con una chiave segreta condivisa generata in modo sicuro.
• La chiave segreta condivisa deve essere la stessa sia nell'iframe che nella pagina parent.
• Questo esempio utilizza HMAC-SHA256 per l'autenticazione del messaggio.

Conclusione

L'API postMessage è uno strumento potente per abilitare la comunicazione cross-origin nelle applicazioni web. Tuttavia, è cruciale comprendere i potenziali rischi per la sicurezza e implementare pattern di sicurezza appropriati per mitigare tali rischi. Seguendo i pattern di sicurezza e le best practice descritte in questa guida, puoi utilizzare postMessage in modo sicuro per costruire applicazioni web robuste e sicure.

Ricorda di dare sempre la priorità alla sicurezza e di rimanere aggiornato con le ultime best practice di sicurezza per lo sviluppo web. Rivedi regolarmente il tuo codice e le configurazioni di sicurezza per assicurarti che le tue applicazioni siano protette da potenziali vulnerabilità.