Giảm thiểu tập lệnh trên nhiều trang web (XSS) bằng một Chính sách bảo mật nội dung (CSP) nghiêm ngặt

Lukas Weichselbaum
Lukas Weichselbaum
X GitHub Trang chủ

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

Tấn công tập lệnh trên nhiều trang web (XSS), khả năng chèn tập lệnh độc hại vào ứng dụng web, là một trong những lỗ hổng bảo mật web lớn nhất trong hơn một thập kỷ qua.

Chính sách bảo mật nội dung (CSP) là một lớp bảo mật bổ sung giúp giảm thiểu XSS. Để định cấu hình CSP, hãy thêm tiêu đề HTTP Content-Security-Policy vào một trang web và đặt các giá trị kiểm soát những tài nguyên mà tác nhân người dùng có thể tải cho trang đó.

Trang này giải thích cách sử dụng CSP dựa trên số chỉ dùng một lần hoặc hàm băm để giảm thiểu XSS, thay vì các CSP dựa trên danh sách cho phép của máy chủ thường dùng, thường khiến trang bị lộ trước XSS vì chúng có thể bị bỏ qua trong hầu hết các cấu hình.

Thuật ngữ chính: Nonce là một số ngẫu nhiên chỉ được dùng một lần mà bạn có thể sử dụng để đánh dấu thẻ <script> là đáng tin cậy.

Thuật ngữ chính: Hàm băm là một hàm toán học chuyển đổi giá trị đầu vào thành một giá trị số nén được gọi là băm. Bạn có thể sử dụng hàm băm (ví dụ: SHA-256) để đánh dấu thẻ <script> cùng dòng là đáng tin cậy.

Chính sách bảo mật nội dung dựa trên số chỉ dùng một lần hoặc hàm băm thường được gọi là CSP nghiêm ngặt. Khi một ứng dụng sử dụng CSP nghiêm ngặt, những kẻ tấn công tìm thấy lỗi chèn HTML thường không thể sử dụng các lỗi đó để buộc trình duyệt thực thi tập lệnh độc hại trong một tài liệu dễ bị tấn công. Điều này là do CSP nghiêm ngặt chỉ cho phép các tập lệnh băm hoặc tập lệnh có giá trị số chỉ dùng một lần chính xác được tạo trên máy chủ, vì vậy, kẻ tấn công không thể thực thi tập lệnh mà không biết số chỉ dùng một lần chính xác cho một phản hồi nhất định.

Tại sao bạn nên sử dụng CSP nghiêm ngặt?

Nếu trang web của bạn đã có CSP giống như script-src www.googleapis.com, thì có thể CSP đó không hiệu quả trong việc chống lại các cuộc tấn công trên nhiều trang web. Loại CSP này được gọi là CSP danh sách cho phép. Các giải pháp này đòi hỏi nhiều hoạt động tuỳ chỉnh và có thể bị kẻ tấn công vượt qua.

CSP nghiêm ngặt dựa trên số chỉ dùng một lần hoặc hàm băm mật mã học sẽ tránh được những lỗi này.

Cấu trúc CSP nghiêm ngặt

Chính sách bảo mật nội dung nghiêm ngặt cơ bản sử dụng một trong các tiêu đề phản hồi HTTP sau:

CSP nghiêm ngặt dựa trên số chỉ dùng một lần

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';
Cách hoạt động của CSP nghiêm ngặt dựa trên số chỉ dùng một lần.

CSP nghiêm ngặt dựa trên hàm băm

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Các thuộc tính sau đây tạo nên một CSP "nghiêm ngặt" và do đó bảo mật:

  • Chính sách này sử dụng số chỉ dùng một lần 'nonce-{RANDOM}' hoặc hàm băm 'sha256-{HASHED_INLINE_SCRIPT}' để cho biết thẻ <script> nào mà nhà phát triển trang web tin tưởng để thực thi trong trình duyệt của người dùng.
  • Chính sách này đặt 'strict-dynamic' để giảm bớt công sức triển khai CSP dựa trên số chỉ dùng một lần hoặc hàm băm bằng cách tự động cho phép thực thi các tập lệnh mà một tập lệnh đáng tin cậy tạo ra. Điều này cũng cho phép sử dụng hầu hết các thư viện và tiện ích JavaScript của bên thứ ba.
  • Chính sách này không dựa trên danh sách cho phép URL, vì vậy, chính sách này không gặp phải các trường hợp bỏ qua CSP phổ biến.
  • Chính sách này chặn các tập lệnh cùng dòng không đáng tin cậy, chẳng hạn như trình xử lý sự kiện cùng dòng hoặc URI javascript:.
  • Chính sách này hạn chế object-src để tắt các trình bổ trợ nguy hiểm như Flash.
  • Chính sách này hạn chế base-uri để chặn việc chèn thẻ <base>. Điều này ngăn kẻ tấn công thay đổi vị trí của tập lệnh được tải từ URL tương đối.

Áp dụng CSP nghiêm ngặt

Để áp dụng CSP nghiêm ngặt, bạn cần:

  1. Quyết định xem ứng dụng của bạn có nên đặt CSP dựa trên số chỉ dùng một lần hay dựa trên hàm băm hay không.
  2. Sao chép CSP từ mục Cấu trúc CSP nghiêm ngặt rồi đặt CSP đó làm tiêu đề phản hồi trên ứng dụng của bạn.
  3. Tái cấu trúc các mẫu HTML và mã phía máy khách để xoá các mẫu không tương thích với CSP.
  4. Triển khai CSP.

Bạn có thể sử dụng quy trình kiểm tra Các phương pháp hay nhất của Lighthouse (phiên bản 7.3.0 trở lên có cờ --preset=experimental) trong suốt quá trình này để kiểm tra xem trang web của bạn có CSP hay không và liệu CSP đó có đủ nghiêm ngặt để chống lại XSS một cách hiệu quả hay không.

Cảnh báo trong báo cáo của Lighthouse cho biết không tìm thấy CSP nào ở chế độ thực thi.
Nếu trang web của bạn không có CSP, Lighthouse sẽ hiển thị cảnh báo này.

Bước 1: Quyết định xem bạn có cần CSP dựa trên số chỉ dùng một lần hay dựa trên hàm băm hay không

Dưới đây là cách hoạt động của hai loại CSP nghiêm ngặt:

CSP dựa trên số chỉ dùng một lần

Với CSP dựa trên số chỉ dùng một lần, bạn tạo một số ngẫu nhiên trong thời gian chạy, đưa số đó vào CSP và liên kết số đó với mọi thẻ tập lệnh trong trang. Kẻ tấn công không thể thêm hoặc chạy tập lệnh độc hại trong trang của bạn vì chúng cần đoán đúng số ngẫu nhiên cho tập lệnh đó. Cách này chỉ hiệu quả nếu số đó không thể đoán được và được tạo mới trong thời gian chạy cho mỗi phản hồi.

Sử dụng CSP dựa trên số chỉ dùng một lần cho các trang HTML được kết xuất trên máy chủ. Đối với các trang này, bạn có thể tạo một số ngẫu nhiên mới cho mỗi phản hồi.

CSP dựa trên hàm băm

Đối với CSP dựa trên hàm băm, hàm băm của mọi thẻ tập lệnh cùng dòng sẽ được thêm vào CSP. Mỗi tập lệnh có một hàm băm khác nhau. Kẻ tấn công không thể thêm hoặc chạy tập lệnh độc hại trong trang của bạn, vì hàm băm của tập lệnh đó cần phải có trong CSP để chạy.

Sử dụng CSP dựa trên hàm băm cho các trang HTML được phân phát tĩnh hoặc các trang cần được lưu vào bộ nhớ đệm. Ví dụ: bạn có thể sử dụng CSP dựa trên hàm băm cho các ứng dụng web một trang được xây dựng bằng các khung như Angular, React hoặc các khung khác, được phân phát tĩnh mà không cần kết xuất phía máy chủ.

Bước 2: Thiết lập CSP nghiêm ngặt và chuẩn bị tập lệnh

Khi thiết lập CSP, bạn có một số lựa chọn:

  • Chế độ chỉ báo cáo (Content-Security-Policy-Report-Only) hoặc chế độ thực thi (Content-Security-Policy). Ở chế độ chỉ báo cáo, CSP sẽ chưa chặn tài nguyên, vì vậy, không có gì trên trang web của bạn bị hỏng, nhưng bạn có thể thấy lỗi và nhận báo cáo về mọi nội dung lẽ ra đã bị chặn. Tại máy của bạn, khi bạn đặt CSP, điều này không thực sự quan trọng vì cả hai chế độ đều cho bạn thấy lỗi trong bảng điều khiển của trình duyệt. Nếu có, chế độ thực thi có thể giúp bạn tìm thấy các tài nguyên mà CSP nháp của bạn chặn, vì việc chặn một tài nguyên có thể khiến trang của bạn có vẻ như bị hỏng. Chế độ chỉ báo cáo sẽ trở nên hữu ích nhất trong giai đoạn sau của quy trình (xem Bước 5).
  • Tiêu đề hoặc thẻ HTML <meta>. Để phát triển cục bộ, thẻ <meta> có thể thuận tiện hơn cho việc điều chỉnh CSP và nhanh chóng xem CSP ảnh hưởng đến trang web của bạn như thế nào. Tuy nhiên, bạn cần lưu ý:
    • Sau này, khi triển khai CSP trong môi trường thực tế, bạn nên đặt CSP làm tiêu đề HTTP.
    • Nếu muốn đặt CSP ở chế độ chỉ báo cáo, bạn cần đặt CSP làm tiêu đề vì thẻ meta CSP không hỗ trợ chế độ chỉ báo cáo.

Cách A: CSP dựa trên số chỉ dùng một lần

Đặt tiêu đề phản hồi HTTP Content-Security-Policy sau đây trong ứng dụng của bạn: 

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Tạo số chỉ dùng một lần cho CSP

Số chỉ dùng một lần là một số ngẫu nhiên chỉ được dùng một lần cho mỗi lượt tải trang. CSP dựa trên số chỉ dùng một lần chỉ có thể giảm thiểu XSS nếu kẻ tấn công không thể đoán được giá trị số chỉ dùng một lần. Giá trị chỉ dùng một lần của CSP phải:

  • Một giá trị ngẫu nhiên mạnh về mặt mật mã (lý tưởng nhất là có độ dài từ 128 bit trở lên)
  • Được tạo mới cho mỗi câu trả lời
  • Được mã hoá Base64

Dưới đây là một số ví dụ về cách thêm số chỉ dùng một lần của CSP trong các khung phía máy chủ:

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response.set("Content-Security-Policy", csp);

  // Every <script> tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

Thêm thuộc tính nonce vào các phần tử <script>

Với CSP dựa trên số chỉ dùng một lần, mọi phần tử <script> đều phải có thuộc tính nonce khớp với giá trị số chỉ dùng một lần ngẫu nhiên được chỉ định trong tiêu đề CSP. Tất cả tập lệnh đều có thể có cùng một số chỉ dùng một lần. Bước đầu tiên là thêm các thuộc tính này vào tất cả tập lệnh để CSP cho phép.

Cách B: Tiêu đề phản hồi CSP dựa trên hàm băm

Đặt tiêu đề phản hồi HTTP Content-Security-Policy sau đây trong ứng dụng của bạn: 

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

Đối với nhiều tập lệnh cùng dòng, cú pháp như sau: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'.

Tải tập lệnh có nguồn gốc một cách linh động

Bạn có thể tải tập lệnh của bên thứ ba một cách linh động bằng cách sử dụng tập lệnh cùng dòng.

Ví dụ về cách chèn tập lệnh cùng dòng.
Được CSP cho phép 
<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.head.appendChild(s);
  });
</script>
 Để cho phép tập lệnh này chạy, bạn phải tính toán hàm băm của tập lệnh cùng dòng và thêm hàm băm đó vào tiêu đề phản hồi CSP, thay thế phần giữ chỗ {HASHED_INLINE_SCRIPT}. Để giảm số lượng hàm băm, bạn có thể hợp nhất tất cả tập lệnh cùng dòng thành một tập lệnh duy nhất. Để xem cách hoạt động của tính năng này, hãy tham khảo ví dụ này và mã của ví dụ đó.
Bị CSP chặn
<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>
 CSP chặn các tập lệnh này vì chúng không được thêm động và không có thuộc tính integrity khớp với một nguồn được cho phép.

Những điều cần lưu ý khi tải tập lệnh

Ví dụ về tập lệnh cùng dòng thêm s.async = false để đảm bảo rằng foo thực thi trước bar, ngay cả khi bar tải trước. Trong đoạn mã này, s.async = false không chặn trình phân tích cú pháp trong khi tập lệnh tải, vì các tập lệnh được thêm một cách linh động. Trình phân tích cú pháp chỉ dừng khi tập lệnh thực thi, giống như đối với tập lệnh async. Tuy nhiên, khi sử dụng đoạn mã này, bạn cần lưu ý:

  • Một hoặc cả hai tập lệnh có thể thực thi trước khi tài liệu tải xuống xong. Nếu bạn muốn tài liệu sẵn sàng khi tập lệnh thực thi, hãy đợi sự kiện DOMContentLoaded trước khi bạn thêm tập lệnh. Nếu việc này gây ra vấn đề về hiệu suất do tập lệnh không bắt đầu tải xuống đủ sớm, hãy sử dụng thẻ tải trước ở phần đầu trang.
  • defer = true không làm gì cả. Nếu bạn cần hành vi đó, hãy chạy tập lệnh theo cách thủ công khi cần.

Bước 3: Tái cấu trúc mẫu HTML và mã phía máy khách

Bạn có thể dùng trình xử lý sự kiện cùng dòng (chẳng hạn như onclick="…", onerror="…") và URI JavaScript (<a href="javascript:…">) để chạy tập lệnh. Điều này có nghĩa là kẻ tấn công tìm thấy lỗi XSS có thể chèn loại HTML này và thực thi JavaScript độc hại. CSP dựa trên số chỉ dùng một lần hoặc hàm băm sẽ cấm sử dụng loại mã đánh dấu này. Nếu trang web của bạn sử dụng bất kỳ mẫu nào trong số này, bạn sẽ cần tái cấu trúc chúng thành các mẫu thay thế an toàn hơn.

Nếu đã bật CSP ở bước trước, bạn sẽ có thể thấy các lỗi vi phạm CSP trong bảng điều khiển mỗi khi CSP chặn một mẫu không tương thích.

Báo cáo lỗi vi phạm CSP trong bảng điều khiển dành cho nhà phát triển Chrome.
Lỗi bảng điều khiển đối với mã chặn.

Trong hầu hết các trường hợp, cách khắc phục rất đơn giản:

Tái cấu trúc trình xử lý sự kiện cùng dòng

Được CSP cho phép
<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things').addEventListener('click', doThings);
</script>
 CSP cho phép các trình xử lý sự kiện được đăng ký bằng JavaScript.
Bị CSP chặn
<span onclick="doThings();">A thing.</span>
 CSP chặn trình xử lý sự kiện cùng dòng.

Tái cấu trúc javascript: URI

Được CSP cho phép
<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo').addEventListener('click', linkClicked);
</script>
 CSP cho phép các trình xử lý sự kiện được đăng ký bằng JavaScript.
Bị CSP chặn
<a href="javascript:linkClicked()">foo</a>
 CSP chặn javascript: URI.

Xoá eval() khỏi JavaScript

Nếu ứng dụng của bạn sử dụng eval() để chuyển đổi chuỗi JSON được chuyển đổi tuần tự thành đối tượng JS, thì bạn nên tái cấu trúc các thực thể đó thành JSON.parse(), việc này cũng nhanh hơn.

Nếu không thể xoá tất cả các trường hợp sử dụng eval(), bạn vẫn có thể đặt CSP nghiêm ngặt dựa trên số chỉ dùng một lần, nhưng bạn phải sử dụng từ khoá CSP 'unsafe-eval'. Việc này khiến chính sách của bạn kém an toàn hơn một chút.

Bạn có thể tìm thấy những ví dụ này và các ví dụ khác về việc tái cấu trúc như vậy trong lớp học lập trình về CSP nghiêm ngặt này:

Bước 4 (Không bắt buộc): Thêm phương án dự phòng để hỗ trợ các phiên bản trình duyệt cũ

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

Nếu bạn cần hỗ trợ các phiên bản trình duyệt cũ:

  • Để sử dụng strict-dynamic, bạn cần thêm https: làm phương án dự phòng cho các phiên bản Safari cũ hơn. Khi đó:
    • Tất cả trình duyệt hỗ trợ strict-dynamic đều bỏ qua phương án dự phòng https:, vì vậy, điều này sẽ không làm giảm hiệu lực của chính sách.
    • Trong các trình duyệt cũ, tập lệnh có nguồn bên ngoài chỉ có thể tải nếu đến từ một nguồn gốc HTTPS. Cách này kém an toàn hơn so với CSP nghiêm ngặt, nhưng vẫn ngăn chặn được một số nguyên nhân phổ biến gây ra XSS, chẳng hạn như việc chèn URI javascript:.
  • Để đảm bảo khả năng tương thích với các phiên bản trình duyệt rất cũ (hơn 4 năm), bạn có thể thêm unsafe-inline làm phương án dự phòng. Tất cả các trình duyệt gần đây đều bỏ qua unsafe-inline nếu có số chỉ dùng một lần hoặc hàm băm CSP.
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Bước 5: Triển khai CSP

Sau khi xác nhận rằng CSP không chặn bất kỳ tập lệnh hợp lệ nào trong môi trường phát triển cục bộ, bạn có thể triển khai CSP cho môi trường thử nghiệm, sau đó cho môi trường thực tế:

  1. (Không bắt buộc) Triển khai CSP ở chế độ chỉ báo cáo bằng cách sử dụng tiêu đề Content-Security-Policy-Report-Only. Chế độ chỉ báo cáo rất hữu ích để kiểm thử một thay đổi có thể gây lỗi (chẳng hạn như CSP mới) trong môi trường thực tế trước khi bạn bắt đầu thực thi các quy định hạn chế của CSP. Ở chế độ chỉ báo cáo, CSP không ảnh hưởng đến hành vi của ứng dụng, nhưng trình duyệt vẫn tạo lỗi bảng điều khiển và báo cáo lỗi vi phạm khi gặp phải các mẫu không tương thích với CSP, nhờ đó, bạn có thể thấy những gì có thể đã bị hỏng đối với người dùng cuối. Để biết thêm thông tin, hãy xem Reporting API.
  2. Khi bạn tin chắc rằng CSP sẽ không làm hỏng trang web của bạn đối với người dùng cuối, hãy triển khai CSP bằng tiêu đề phản hồi Content-Security-Policy. Bạn nên đặt CSP bằng tiêu đề HTTP phía máy chủ vì cách này an toàn hơn thẻ <meta>. Sau khi bạn hoàn tất bước này, CSP sẽ bắt đầu bảo vệ ứng dụng của bạn khỏi XSS.

Các điểm hạn chế

CSP nghiêm ngặt thường cung cấp một lớp bảo mật bổ sung mạnh mẽ giúp giảm thiểu XSS. Trong hầu hết các trường hợp, CSP giảm đáng kể bề mặt tấn công bằng cách từ chối các mẫu nguy hiểm như URI javascript:. Tuy nhiên, tuỳ thuộc vào loại CSP bạn đang sử dụng (nonces, hashes, có hoặc không có 'strict-dynamic'), có những trường hợp CSP không bảo vệ ứng dụng của bạn:

  • Nếu bạn dùng số chỉ dùng một lần cho một tập lệnh, nhưng có một lệnh chèn trực tiếp vào phần nội dung hoặc tham số src của phần tử <script> đó.
  • Nếu có nội dung chèn vào vị trí của tập lệnh được tạo động (document.createElement('script')), bao gồm cả nội dung chèn vào bất kỳ hàm thư viện nào tạo nút DOM script dựa trên giá trị của đối số. Điều này bao gồm một số API phổ biến như .html() của jQuery, cũng như .get() và .post() trong jQuery < 3.0.
  • Nếu có lỗi chèn mẫu trong các ứng dụng AngularJS cũ. Kẻ tấn công có thể chèn vào mẫu AngularJS có thể sử dụng mẫu đó để thực thi JavaScript tuỳ ý.
  • Nếu chính sách này chứa 'unsafe-eval', thì các lệnh chèn vào eval(), setTimeout() và một số API hiếm khi được sử dụng khác.

Nhà phát triển và kỹ sư bảo mật nên đặc biệt chú ý đến các mẫu như vậy trong quá trình xem xét mã và kiểm tra bảo mật. Bạn có thể tìm thêm thông tin chi tiết về những trường hợp này trong bài viết Chính sách bảo mật nội dung: Sự kết hợp thành công giữa việc tăng cường bảo mật và giảm thiểu rủi ro.

Tài liệu đọc thêm