Giao tiếp Cross-Origin: Các Mẫu Bảo mật với PostMessage API

Trong web hiện đại, các ứng dụng thường xuyên cần tương tác với tài nguyên từ các nguồn gốc (origin) khác nhau. Chính sách Same-Origin (SOP) là một cơ chế bảo mật quan trọng nhằm hạn chế các script truy cập tài nguyên từ một nguồn gốc khác. Tuy nhiên, có những kịch bản hợp lệ mà giao tiếp cross-origin là cần thiết. API postMessage cung cấp một cơ chế được kiểm soát để đạt được điều này, nhưng điều quan trọng là phải hiểu rõ các rủi ro bảo mật tiềm ẩn và triển khai các mẫu bảo mật phù hợp.

Tìm hiểu về Chính sách Same-Origin (SOP)

Chính sách Same-Origin là một khái niệm bảo mật cơ bản trong các trình duyệt web. Nó hạn chế các trang web thực hiện yêu cầu đến một tên miền khác với tên miền đã phục vụ trang web đó. Một nguồn gốc được xác định bởi scheme (giao thức), host (tên miền) và port (cổng). Nếu bất kỳ yếu tố nào trong số này khác nhau, các nguồn gốc được coi là khác nhau. Ví dụ:

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

Đây đều là các nguồn gốc khác nhau, và SOP hạn chế quyền truy cập script trực tiếp giữa chúng.

Giới thiệu về PostMessage API

API postMessage cung cấp một cơ chế an toàn và được kiểm soát cho việc giao tiếp cross-origin. Nó cho phép các script gửi tin nhắn đến các cửa sổ khác (ví dụ: iframe, cửa sổ mới hoặc tab), bất kể nguồn gốc của chúng. Cửa sổ nhận sau đó có thể lắng nghe những tin nhắn này và xử lý chúng một cách tương ứng.

Cú pháp cơ bản để gửi một tin nhắn là:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: Một tham chiếu đến cửa sổ mục tiêu (ví dụ: window.parent, iframe.contentWindow, hoặc một đối tượng cửa sổ nhận được từ window.open).
• message: Dữ liệu bạn muốn gửi. Đây có thể là bất kỳ đối tượng JavaScript nào có thể được tuần tự hóa (ví dụ: chuỗi, số, đối tượng, mảng).
• targetOrigin: Chỉ định nguồn gốc mà bạn muốn gửi tin nhắn đến. Đây là một tham số bảo mật quan trọng.

Ở phía nhận, bạn cần lắng nghe sự kiện message:

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

Đối tượng event chứa các thuộc tính sau:

• event.data: Tin nhắn được gửi bởi cửa sổ kia.
• event.origin: Nguồn gốc của cửa sổ đã gửi tin nhắn.
• event.source: Một tham chiếu đến cửa sổ đã gửi tin nhắn.

Rủi ro và Lỗ hổng Bảo mật

Mặc dù postMessage cung cấp một cách để vượt qua các hạn chế của SOP, nó cũng giới thiệu các rủi ro bảo mật tiềm ẩn nếu không được triển khai cẩn thận. Dưới đây là một số lỗ hổng phổ biến:

1. Không khớp Nguồn gốc Mục tiêu

Việc không xác thực thuộc tính event.origin là một lỗ hổng nghiêm trọng. Nếu bên nhận tin tưởng mù quáng vào tin nhắn, bất kỳ trang web nào cũng có thể gửi dữ liệu độc hại. Luôn xác minh rằng event.origin khớp với nguồn gốc dự kiến trước khi xử lý tin nhắn.

Ví dụ (Mã có lỗ hổng):

window.addEventListener('message', function(event) {
  // KHÔNG LÀM ĐIỀU NÀY!
  processMessage(event.data);
});

Ví dụ (Mã an toàn):

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. Chèn Dữ liệu (Data Injection)

Việc xem dữ liệu nhận được (event.data) như mã có thể thực thi hoặc chèn trực tiếp vào DOM có thể dẫn đến lỗ hổng Cross-Site Scripting (XSS). Luôn làm sạch và xác thực dữ liệu nhận được trước khi sử dụng.

Ví dụ (Mã có lỗ hổng):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // KHÔNG LÀM ĐIỀU NÀY!
  }
});

Ví dụ (Mã an toàn):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // Triển khai một hàm làm sạch phù hợp
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // Triển khai logic làm sạch mạnh mẽ ở đây.
    // Ví dụ, sử dụng DOMPurify hoặc một thư viện tương tự
    return DOMPurify.sanitize(data);
}

3. Tấn công Man-in-the-Middle (MITM)

Nếu giao tiếp diễn ra qua một kênh không an toàn (HTTP), kẻ tấn công MITM có thể chặn và sửa đổi các tin nhắn. Luôn sử dụng HTTPS để giao tiếp an toàn.

4. Tấn công Giả mạo Yêu cầu Cross-Site (CSRF)

Nếu bên nhận thực hiện các hành động dựa trên tin nhắn nhận được mà không có xác thực phù hợp, kẻ tấn công có thể giả mạo tin nhắn để lừa bên nhận thực hiện các hành động không mong muốn. Triển khai các cơ chế bảo vệ CSRF, chẳng hạn như bao gồm một token bí mật trong tin nhắn và xác minh nó ở phía nhận.

5. Sử dụng Ký tự đại diện trong targetOrigin

Việc đặt targetOrigin thành * cho phép bất kỳ nguồn gốc nào cũng có thể nhận được tin nhắn. Điều này nên được tránh trừ khi thực sự cần thiết, vì nó làm mất đi mục đích của bảo mật dựa trên nguồn gốc. Nếu bạn phải sử dụng *, hãy đảm bảo bạn triển khai các biện pháp bảo mật mạnh mẽ khác, chẳng hạn như mã xác thực tin nhắn (MAC).

Ví dụ (Tránh làm điều này):

otherWindow.postMessage(message, '*'); // Tránh sử dụng '*' trừ khi thực sự cần thiết

Các Mẫu Bảo mật và Phương pháp Tốt nhất

Để giảm thiểu các rủi ro liên quan đến postMessage, hãy tuân theo các mẫu bảo mật và phương pháp tốt nhất sau:

1. Xác thực Nguồn gốc Nghiêm ngặt

Luôn xác thực thuộc tính event.origin ở phía nhận. So sánh nó với một danh sách các nguồn gốc đáng tin cậy đã được xác định trước. Sử dụng so sánh bằng nghiêm ngặt (===).

2. Làm sạch và Xác thực Dữ liệu

Làm sạch và xác thực tất cả dữ liệu nhận được qua postMessage trước khi sử dụng. Sử dụng các kỹ thuật làm sạch phù hợp tùy thuộc vào cách dữ liệu sẽ được sử dụng (ví dụ: thoát ký tự HTML, mã hóa URL, xác thực đầu vào). Sử dụng các thư viện như DOMPurify để làm sạch HTML.

3. Mã Xác thực Tin nhắn (MAC)

Bao gồm một Mã Xác thực Tin nhắn (MAC) trong tin nhắn để đảm bảo tính toàn vẹn và tính xác thực của nó. Bên gửi tính toán MAC bằng cách sử dụng một khóa bí mật được chia sẻ và bao gồm nó trong tin nhắn. Bên nhận tính toán lại MAC bằng cùng một khóa bí mật được chia sẻ và so sánh nó với MAC nhận được. Nếu chúng khớp nhau, tin nhắn được coi là xác thực và không bị giả mạo.

Ví dụ (Sử dụng HMAC-SHA256):

// Bên gửi
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);
}

// Bên nhận
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); // Tiếp tục xử lý tin nhắn
  } else {
    console.error('Message signature verification failed!');
  }
}

Quan trọng: Khóa bí mật được chia sẻ phải được tạo và lưu trữ một cách an toàn. Tránh hardcode khóa trong mã nguồn.

4. Sử dụng Nonce và Dấu thời gian

Để ngăn chặn các cuộc tấn công phát lại (replay attacks), hãy bao gồm một nonce (số chỉ sử dụng một lần) duy nhất và một dấu thời gian trong tin nhắn. Bên nhận sau đó có thể xác minh rằng nonce chưa được sử dụng trước đó và dấu thời gian nằm trong một khung thời gian chấp nhận được. Điều này giảm thiểu rủi ro kẻ tấn công phát lại các tin nhắn đã bị chặn trước đó.

5. Nguyên tắc Đặc quyền Tối thiểu

Chỉ cấp các đặc quyền tối thiểu cần thiết cho cửa sổ kia. Ví dụ, nếu cửa sổ kia chỉ cần đọc dữ liệu, đừng cho phép nó ghi dữ liệu. Thiết kế giao thức giao tiếp của bạn với nguyên tắc đặc quyền tối thiểu.

6. Chính sách Bảo mật Nội dung (CSP)

Sử dụng Chính sách Bảo mật Nội dung (CSP) để hạn chế các nguồn mà từ đó script có thể được tải và các hành động mà script có thể thực hiện. Điều này có thể giúp giảm thiểu tác động của các lỗ hổng XSS có thể phát sinh từ việc xử lý không đúng dữ liệu postMessage.

7. Xác thực Đầu vào

Luôn xác thực cấu trúc và định dạng của dữ liệu nhận được. Xác định một định dạng tin nhắn rõ ràng và đảm bảo rằng dữ liệu nhận được tuân thủ định dạng này. Điều này giúp ngăn chặn hành vi không mong muốn và các lỗ hổng.

8. Tuần tự hóa Dữ liệu An toàn

Sử dụng một định dạng tuần tự hóa dữ liệu an toàn, chẳng hạn như JSON, để tuần tự hóa và giải tuần tự hóa các tin nhắn. Tránh sử dụng các định dạng cho phép thực thi mã, chẳng hạn như eval() hoặc Function().

9. Giới hạn Kích thước Tin nhắn

Giới hạn kích thước của các tin nhắn được gửi qua postMessage. Các tin nhắn lớn có thể tiêu thụ tài nguyên quá mức và có khả năng dẫn đến các cuộc tấn công từ chối dịch vụ.

10. Kiểm tra Bảo mật Thường xuyên

Thực hiện kiểm tra bảo mật thường xuyên mã nguồn của bạn để xác định và giải quyết các lỗ hổng tiềm ẩn. Chú ý kỹ đến việc triển khai postMessage và đảm bảo rằng tất cả các phương pháp bảo mật tốt nhất được tuân thủ.

Kịch bản Ví dụ: Giao tiếp An toàn giữa Iframe và Trang Cha

Hãy xem xét một kịch bản trong đó một iframe được lưu trữ trên https://iframe.example.com cần giao tiếp với trang cha của nó được lưu trữ trên https://parent.example.com. Iframe cần gửi dữ liệu người dùng đến trang cha để xử lý.

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

// Tạo một khóa bí mật được chia sẻ (thay thế bằng một phương thức tạo khóa an toàn)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// Lấy dữ liệu người dùng
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// Gửi dữ liệu người dùng đến trang cha
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);

Trang Cha (https://parent.example.com):

// Khóa bí mật được chia sẻ (phải khớp với khóa của iframe)
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!');
    // Xử lý dữ liệu người dùng
    console.log('User data:', userData);
  } else {
    console.error('Message signature verification failed!');
  }
});

Lưu ý Quan trọng:

• Thay thế YOUR_SECURE_SHARED_SECRET bằng một khóa bí mật được chia sẻ được tạo ra một cách an toàn.
• Khóa bí mật được chia sẻ phải giống nhau ở cả iframe và trang cha.
• Ví dụ này sử dụng HMAC-SHA256 để xác thực tin nhắn.

Kết luận

API postMessage là một công cụ mạnh mẽ để cho phép giao tiếp cross-origin trong các ứng dụng web. Tuy nhiên, điều quan trọng là phải hiểu các rủi ro bảo mật tiềm ẩn và triển khai các mẫu bảo mật phù hợp để giảm thiểu những rủi ro này. Bằng cách tuân theo các mẫu bảo mật và phương pháp tốt nhất được nêu trong hướng dẫn này, bạn có thể sử dụng postMessage một cách an toàn để xây dựng các ứng dụng web mạnh mẽ và bảo mật.

Hãy nhớ luôn ưu tiên bảo mật và cập nhật các phương pháp bảo mật tốt nhất mới nhất cho phát triển web. Thường xuyên xem xét mã nguồn và cấu hình bảo mật của bạn để đảm bảo rằng các ứng dụng của bạn được bảo vệ khỏi các lỗ hổng tiềm ẩn.