Các phương pháp hay nhất về Giới thiệu và Chính sách giới thiệu

Maud Nalpas

Trang này trình bày một số phương pháp hay nhất để thiết lập Referrer-Policy và sử dụng giá trị giới thiệu trong các yêu cầu đến.

Tóm tắt

• Rò rỉ thông tin ngoài ý muốn giữa các nguồn gốc gây ảnh hưởng đến quyền riêng tư của người dùng web. Chính sách giới thiệu mang tính bảo vệ có thể giúp ích.
• Hãy cân nhắc việc đặt chính sách giới thiệu là strict-origin-when-cross-origin. Thao tác này vẫn giữ được hầu hết tính hữu ích của giá trị giới thiệu, đồng thời giảm thiểu nguy cơ rò rỉ dữ liệu trên nhiều nguồn.
• Không dùng liên kết giới thiệu để bảo vệ khỏi hành vi Giả mạo yêu cầu trên nhiều trang web (CSRF). Thay vào đó, hãy sử dụng mã thông báo CSRF và các tiêu đề khác làm một lớp bảo mật bổ sung.

Referer và Referrer-Policy 101

Các yêu cầu HTTP có thể bao gồm một tiêu đề Referer không bắt buộc, cho biết nguồn gốc hoặc URL của trang web mà yêu cầu được gửi đến. Tiêu đề Referrer-Policy xác định những dữ liệu có trong tiêu đề Referer.

Trong ví dụ sau, tiêu đề Referer bao gồm URL đầy đủ của trang trên site-one mà yêu cầu được thực hiện.

Tiêu đề Referer có thể xuất hiện trong nhiều loại yêu cầu:

• Yêu cầu điều hướng, khi người dùng nhấp vào một đường liên kết.
• Yêu cầu về tài nguyên phụ, khi trình duyệt yêu cầu hình ảnh, iframe, tập lệnh và các tài nguyên khác mà một trang cần.

Đối với các thao tác điều hướng và iframe, bạn cũng có thể truy cập vào dữ liệu này bằng JavaScript thông qua document.referrer.

Bạn có thể học được nhiều điều từ các giá trị Referer. Ví dụ: một dịch vụ phân tích có thể sử dụng các thông số này để xác định rằng 50% khách truy cập trên site-two.example đến từ social-network.example. Nhưng khi URL đầy đủ, bao gồm cả đường dẫn và chuỗi truy vấn, được gửi trong Referer trên các nguồn, thì điều này có thể gây nguy hiểm cho quyền riêng tư của người dùng và tạo ra các rủi ro bảo mật:

URL từ 1 đến 5 chứa thông tin riêng tư, đôi khi là thông tin nhạy cảm hoặc thông tin nhận dạng. Việc âm thầm rò rỉ các thông tin này trên nhiều nguồn có thể xâm phạm quyền riêng tư của người dùng web.

URL số 6 là một URL chức năng. Nếu người nhận không phải là người dùng dự kiến, thì kẻ xấu có thể kiểm soát tài khoản của người dùng này.

Để hạn chế những dữ liệu về liên kết giới thiệu được cung cấp cho các yêu cầu từ trang web của bạn, bạn có thể đặt chính sách về liên kết giới thiệu.

Có những chính sách nào và chúng khác nhau như thế nào?

Bạn có thể chọn một trong 8 chính sách. Tuỳ thuộc vào chính sách, dữ liệu có sẵn từ tiêu đề Referer (và document.referrer) có thể là:

• Không có dữ liệu (không có tiêu đề Referer)
• Chỉ nguồn gốc
• URL đầy đủ: nguồn gốc, đường dẫn và chuỗi truy vấn

Một số chính sách được thiết kế để hoạt động theo cách khác nhau tuỳ thuộc vào bối cảnh: yêu cầu trên nhiều nguồn gốc hoặc trên cùng một nguồn gốc, liệu đích đến của yêu cầu có an toàn như nguồn gốc hay không, hoặc cả hai. Điều này hữu ích để giới hạn lượng thông tin được chia sẻ trên các nguồn gốc hoặc với các nguồn gốc kém an toàn hơn, đồng thời duy trì sự phong phú của liên kết giới thiệu trong trang web của riêng bạn.

Bảng sau đây cho biết cách các chính sách về thông tin giới thiệu hạn chế dữ liệu URL có sẵn trong tiêu đề Referer và document.referrer:

MDN cung cấp danh sách đầy đủ các chính sách và ví dụ về hành vi.

Sau đây là một số điều bạn cần lưu ý khi đặt chính sách giới thiệu:

• Tất cả các chính sách có tính đến lược đồ (HTTPS so với HTTP) (strict-origin, no-referrer-when-downgrade và strict-origin-when-cross-origin) đều xử lý các yêu cầu từ một nguồn HTTP đến một nguồn HTTP khác theo cách tương tự như các yêu cầu từ một nguồn HTTPS đến một nguồn HTTPS khác, mặc dù HTTP ít an toàn hơn. Đó là vì đối với các chính sách này, điều quan trọng là liệu có xảy ra tình trạng hạ cấp bảo mật hay không; tức là nếu yêu cầu có thể để lộ dữ liệu từ một nguồn gốc đã mã hoá sang một nguồn gốc không được mã hoá, như trong các yêu cầu HTTPS → HTTP. Yêu cầu HTTP → HTTP hoàn toàn không được mã hoá, nên không có trường hợp hạ cấp.
• Nếu một yêu cầu là cùng nguồn gốc, thì điều này có nghĩa là giản đồ (HTTPS hoặc HTTP) là giống nhau, nên không có sự hạ cấp bảo mật.

Chính sách trường giới thiệu mặc định trong trình duyệt

Tính đến tháng 10 năm 2021

Nếu bạn không đặt chính sách liên kết giới thiệu, trình duyệt sẽ sử dụng chính sách mặc định của trình duyệt.

Các phương pháp hay nhất để đặt chính sách giới thiệu

Bạn có thể đặt chính sách giới thiệu cho trang web của mình theo nhiều cách:

• Dưới dạng tiêu đề HTTP
• Trong HTML
• Từ JavaScript trên cơ sở mỗi yêu cầu

Bạn có thể đặt các chính sách khác nhau cho các trang, yêu cầu hoặc phần tử khác nhau.

Tiêu đề HTTP và phần tử meta đều ở cấp trang. Thứ tự ưu tiên để xác định chính sách có hiệu lực của một phần tử như sau:

1. Chính sách ở cấp phần tử
2. Chính sách cấp trang
3. Giá trị mặc định của trình duyệt

Ví dụ:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Hình ảnh được yêu cầu theo chính sách no-referrer-when-downgrade và tất cả các yêu cầu khác về tài nguyên phụ từ trang này đều tuân theo chính sách strict-origin-when-cross-origin.

Cách xem chính sách về đường liên kết giới thiệu

securityheaders.com là một công cụ hữu ích để xác định chính sách mà một trang web hoặc trang cụ thể đang sử dụng.

Bạn cũng có thể sử dụng công cụ cho nhà phát triển trong Chrome, Edge hoặc Firefox để xem chính sách giới thiệu được dùng cho một yêu cầu cụ thể. Tại thời điểm viết bài này, Safari không cho thấy tiêu đề Referrer-Policy, nhưng lại cho thấy Referer đã được gửi.

Bạn nên đặt chính sách nào cho trang web của mình?

Bạn nên đặt một chính sách nâng cao quyền riêng tư một cách rõ ràng, chẳng hạn như strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn).

Tại sao lại là "rõ ràng"?

Nếu bạn không đặt chính sách về đường liên kết giới thiệu, thì trình duyệt sẽ sử dụng chính sách mặc định. Trên thực tế, các trang web thường tuân theo chính sách mặc định của trình duyệt. Tuy nhiên, cách này không lý tưởng vì:

• Các trình duyệt khác nhau có các chính sách mặc định khác nhau, vì vậy, nếu bạn dựa vào các giá trị mặc định của trình duyệt, thì trang web của bạn sẽ không hoạt động theo cách có thể dự đoán được trên các trình duyệt.
• Các trình duyệt đang áp dụng các chế độ mặc định nghiêm ngặt hơn, chẳng hạn như strict-origin-when-cross-origin và các cơ chế như cắt thông tin giới thiệu cho các yêu cầu cross-origin. Việc chọn áp dụng một chính sách tăng cường quyền riêng tư một cách rõ ràng trước khi các chế độ mặc định của trình duyệt thay đổi sẽ giúp bạn kiểm soát và chạy các thử nghiệm theo ý muốn.

Tại sao lại là strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn)?

Bạn cần có một chính sách an toàn, tăng cường quyền riêng tư và hữu ích. Ý nghĩa của "hữu ích" tuỳ thuộc vào những gì bạn muốn từ đơn vị giới thiệu:

• Bảo mật: nếu trang web của bạn sử dụng HTTPS (nếu không, hãy ưu tiên sử dụng HTTPS), bạn không muốn URL của trang web bị rò rỉ trong các yêu cầu không phải HTTPS. Vì bất kỳ ai trên mạng đều có thể thấy những thông tin này, nên việc rò rỉ sẽ khiến người dùng của bạn gặp phải các cuộc tấn công trung gian. Các chính sách no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer và strict-origin giải quyết vấn đề này.
• Nâng cao quyền riêng tư: đối với yêu cầu trên nhiều nguồn gốc, no-referrer-when-downgrade chia sẻ toàn bộ URL, điều này có thể gây ra các vấn đề về quyền riêng tư. strict-origin-when-cross-origin và strict-origin chỉ chia sẻ nguồn gốc, còn no-referrer thì không chia sẻ gì cả. Nhờ đó, bạn có thể sử dụng strict-origin-when-cross-origin, strict-origin và no-referrer làm các lựa chọn nâng cao quyền riêng tư.
• Hữu ích: no-referrer và strict-origin không bao giờ chia sẻ URL đầy đủ, ngay cả đối với các yêu cầu cùng nguồn gốc. Nếu bạn cần URL đầy đủ, thì strict-origin-when-cross-origin là lựa chọn phù hợp hơn.

Tất cả những điều này có nghĩa là strict-origin-when-cross-origin thường là một lựa chọn hợp lý.

Ví dụ: Thiết lập chính sách strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Hoặc phía máy chủ, ví dụ: trong Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Nếu strict-origin-when-cross-origin (hoặc nghiêm ngặt hơn) không đáp ứng được tất cả các trường hợp sử dụng của bạn thì sao?

Trong trường hợp này, hãy áp dụng phương pháp tiếp cận từng bước: đặt một chính sách bảo vệ như strict-origin-when-cross-origin cho trang web của bạn và nếu cần, hãy đặt một chính sách cho phép hơn cho các yêu cầu hoặc phần tử HTML cụ thể.

Ví dụ: chính sách cấp phần tử

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit có thể giới hạn document.referrer hoặc tiêu đề Referer cho các yêu cầu trên nhiều trang web. Xem chi tiết.

Ví dụ: chính sách ở cấp yêu cầu

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Bạn nên cân nhắc những điều gì khác?

Chính sách của bạn sẽ tuỳ thuộc vào trang web và các trường hợp sử dụng của bạn, do bạn, nhóm của bạn và công ty của bạn xác định. Nếu một số URL chứa dữ liệu nhận dạng hoặc dữ liệu nhạy cảm, hãy đặt một chính sách bảo vệ.

Các phương pháp hay nhất cho yêu cầu đến

Dưới đây là một số nguyên tắc về những việc cần làm nếu trang web của bạn sử dụng URL liên kết giới thiệu của các yêu cầu đến.

Bảo vệ dữ liệu của người dùng

Referer có thể chứa dữ liệu riêng tư, cá nhân hoặc dữ liệu nhận dạng, vì vậy, hãy nhớ xử lý dữ liệu này đúng cách.

Đường liên kết giới thiệu đến có thể thay đổi {referer-can-change}

Việc sử dụng giá trị giới thiệu từ các yêu cầu đến từ nhiều nguồn có một số hạn chế:

• Nếu không kiểm soát được việc triển khai của trình phát yêu cầu, bạn không thể giả định về tiêu đề Referer (và document.referrer) mà bạn nhận được. Trình phát yêu cầu có thể quyết định chuyển sang chính sách no-referrer bất cứ lúc nào hoặc nói chung là chuyển sang một chính sách nghiêm ngặt hơn so với chính sách mà họ đã sử dụng trước đó. Điều này có nghĩa là bạn nhận được ít dữ liệu hơn từ Referer so với trước đây.
• Ngày càng có nhiều trình duyệt sử dụng strict-origin-when-cross-origin Referrer-Policy theo mặc định. Điều này có nghĩa là giờ đây, bạn có thể chỉ nhận được nguồn gốc thay vì URL đầy đủ của liên kết giới thiệu trong các yêu cầu trên nhiều nguồn gốc đến, nếu trang web gửi không đặt chính sách.
• Các trình duyệt có thể thay đổi cách quản lý Referer. Ví dụ: một số nhà phát triển trình duyệt có thể quyết định luôn cắt ngắn giá trị giới thiệu thành nguồn trong các yêu cầu về tài nguyên phụ trên nhiều nguồn gốc để bảo vệ quyền riêng tư của người dùng.
• Tiêu đề Referer (và document.referrer) có thể chứa nhiều dữ liệu hơn mức bạn cần. Ví dụ: yêu cầu có thể có một URL đầy đủ khi bạn chỉ muốn biết liệu yêu cầu đó có phải là yêu cầu từ nhiều nguồn hay không.

Các lựa chọn thay thế cho Referer

Bạn có thể cần cân nhắc các giải pháp thay thế nếu:

• Một tính năng thiết yếu của trang web sử dụng URL giới thiệu của các yêu cầu đến từ nhiều nguồn.
• Trang web của bạn không còn nhận được phần URL của liên kết giới thiệu mà trang web cần trong yêu cầu trên nhiều nguồn gốc. Điều này xảy ra khi bên phát yêu cầu thay đổi chính sách của họ hoặc khi họ không đặt chính sách và chính sách mặc định của trình duyệt đã thay đổi (chẳng hạn như trong Chrome 85).

Để xác định các lựa chọn thay thế, trước tiên, hãy phân tích phần nào của giá trị giới thiệu mà bạn đang sử dụng.

Nếu bạn chỉ cần nguồn

• Nếu bạn đang sử dụng giá trị giới thiệu trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, thì window.location.origin là một lựa chọn thay thế.
• Nếu có, các tiêu đề như Origin và Sec-Fetch-Site sẽ cung cấp cho bạn Origin hoặc mô tả xem yêu cầu có phải là yêu cầu từ nhiều nguồn hay không, đây có thể chính xác là những gì bạn cần.

Nếu bạn cần các phần tử khác của URL (đường dẫn, tham số truy vấn...)

• Các tham số yêu cầu có thể giải quyết trường hợp sử dụng của bạn, giúp bạn không phải phân tích cú pháp giá trị liên kết giới thiệu.
• Nếu bạn đang sử dụng giá trị giới thiệu trong một tập lệnh có quyền truy cập cấp cao nhất vào trang, thì window.location.pathname có thể hoạt động như một lựa chọn thay thế. Chỉ trích xuất phần đường dẫn của URL và truyền phần đó dưới dạng một đối số, để mọi thông tin nhạy cảm tiềm ẩn trong các tham số URL không được truyền đi.

Nếu không thể sử dụng các phương án thay thế này:

• Kiểm tra xem bạn có thể thay đổi hệ thống để dự kiến bộ phát yêu cầu (ví dụ: site-one.example) sẽ đặt rõ thông tin bạn cần trong một số loại cấu hình hay không.
  • Ưu điểm: rõ ràng hơn, bảo đảm quyền riêng tư hơn cho người dùng site-one.example, có khả năng thích ứng tốt hơn trong tương lai.
  • Nhược điểm: có thể bạn hoặc người dùng hệ thống của bạn sẽ phải làm nhiều việc hơn.
• Kiểm tra xem trang web phát ra các yêu cầu có thể đồng ý đặt Chính sách về đường liên kết giới thiệu no-referrer-when-downgrade cho mỗi phần tử hoặc mỗi yêu cầu hay không.
  • Nhược điểm: có thể ít đảm bảo quyền riêng tư hơn đối với người dùng site-one.example, có thể không được hỗ trợ trong tất cả các trình duyệt.

Bảo vệ chống Giả mạo yêu cầu trên nhiều trang web (CSRF)

Trình phát yêu cầu luôn có thể quyết định không gửi giá trị giới thiệu bằng cách đặt chính sách no-referrer và một tác nhân độc hại thậm chí có thể giả mạo giá trị giới thiệu.

Sử dụng mã thông báo CSRF làm biện pháp bảo vệ chính. Để tăng cường bảo vệ, hãy sử dụng SameSite và thay vì Referer, hãy sử dụng các tiêu đề như Origin (có trong các yêu cầu POST và CORS) và Sec-Fetch-Site nếu có.

Ghi nhật ký và gỡ lỗi

Đảm bảo bảo vệ dữ liệu cá nhân hoặc dữ liệu nhạy cảm của người dùng có thể nằm trong Referer.

Nếu bạn chỉ sử dụng nguồn gốc, hãy kiểm tra xem bạn có thể sử dụng tiêu đề Origin làm phương án thay thế hay không. Điều này có thể cung cấp cho bạn thông tin cần thiết cho mục đích gỡ lỗi theo cách đơn giản hơn và không cần phân tích cú pháp giá trị giới thiệu.

Thanh toán

Nhà cung cấp dịch vụ thanh toán có thể dựa vào tiêu đề Referer của các yêu cầu đến để kiểm tra tính bảo mật.

Ví dụ:

• Người dùng nhấp vào nút Mua trên online-shop.example/cart/checkout.
• online-shop.example chuyển hướng đến payment-provider.example để quản lý giao dịch.
• payment-provider.example sẽ kiểm tra Referer của yêu cầu này dựa trên danh sách các giá trị Referer được phép do người bán thiết lập. Nếu không khớp với bất kỳ mục nào trong danh sách, payment-provider.example sẽ từ chối yêu cầu. Nếu khớp, người dùng có thể tiến hành giao dịch.

Các phương pháp hay nhất để kiểm tra bảo mật quy trình thanh toán

Là một nhà cung cấp dịch vụ thanh toán, bạn có thể sử dụng Referer làm biện pháp kiểm tra cơ bản để chống lại một số cuộc tấn công. Tuy nhiên, chỉ riêng tiêu đề Referer không phải là cơ sở đáng tin cậy để kiểm tra. Trang web yêu cầu, cho dù là người bán hợp pháp hay không, đều có thể đặt chính sách no-referrer khiến nhà cung cấp dịch vụ thanh toán không thể truy cập vào thông tin Referer.

Việc xem xét Referer có thể giúp các nhà cung cấp dịch vụ thanh toán phát hiện những kẻ tấn công ngây thơ chưa đặt chính sách no-referrer. Nếu bạn dùng Referer làm bước kiểm tra đầu tiên:

• Đừng cho rằng Referer luôn có sẵn. Nếu có, hãy kiểm tra chỉ với dữ liệu tối thiểu mà nó có thể bao gồm, đó là nguồn gốc.
  • Khi đặt danh sách các giá trị Referer được phép, hãy nhớ chỉ thêm nguồn gốc và không thêm đường dẫn.
  • Ví dụ: các giá trị Referer được phép cho online-shop.example phải là online-shop.example, chứ không phải online-shop.example/cart/checkout. Bằng cách dự kiến không có Referer hoặc giá trị Referer chỉ là nguồn gốc của trang web yêu cầu, bạn sẽ ngăn chặn các lỗi có thể phát sinh do đưa ra giả định về Referrer-Policy của người bán.
• Nếu không có Referer hoặc nếu có Referer và quy trình kiểm tra nguồn gốc Referer cơ bản của bạn thành công, thì bạn có thể chuyển sang một phương thức xác minh khác đáng tin cậy hơn.

Để xác minh các khoản thanh toán một cách đáng tin cậy hơn, hãy để bên yêu cầu băm các tham số yêu cầu cùng với một khoá duy nhất. Sau đó, nhà cung cấp dịch vụ thanh toán có thể tính cùng một hàm băm ở phía bạn và chỉ chấp nhận yêu cầu nếu hàm băm đó khớp với tính toán của bạn.

Điều gì sẽ xảy ra với Referer khi một trang web của người bán HTTP không có chính sách về thông tin giới thiệu chuyển hướng đến một nhà cung cấp dịch vụ thanh toán HTTPS?

Không có Referer nào xuất hiện trong yêu cầu gửi đến nhà cung cấp dịch vụ thanh toán HTTPS, vì hầu hết các trình duyệt đều sử dụng strict-origin-when-cross-origin hoặc no-referrer-when-downgrade theo mặc định khi một trang web không đặt chính sách. Việc Chrome thay đổi sang một chính sách mặc định mới sẽ không làm thay đổi hành vi này.

Kết luận

Chính sách giới thiệu mang tính bảo vệ là một cách hiệu quả để mang lại cho người dùng nhiều quyền riêng tư hơn.

Để tìm hiểu thêm về các kỹ thuật bảo vệ người dùng, hãy xem bộ sưu tập An toàn và bảo mật của chúng tôi

Tài nguyên

• Tìm hiểu về "cùng trang web" và "cùng nguồn gốc"
• Tiêu đề bảo mật mới: Chính sách về thông tin giới thiệu (2017)
• Referrer-Policy trên MDN
• Tiêu đề giới thiệu: các mối lo ngại về quyền riêng tư và tính bảo mật trên MDN
• Thay đổi Chrome: Ý định triển khai Blink
• Thay đổi Chrome: Ý định phát hành Blink
• Thay đổi của Chrome: mục trạng thái
• Chrome change: 85 beta blogpost
• Chuỗi thảo luận về việc cắt bớt thông tin về đơn vị giới thiệu trên GitHub: hành vi của các trình duyệt
• Thông số kỹ thuật của Chính sách về người giới thiệu

Xin chân thành cảm ơn tất cả những người đánh giá đã đóng góp và phản hồi, đặc biệt là Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck và Kayce Basques.