Overview

Giới thiệu

Lưu ý: Tài liệu này hiện vẫn đang trong quá trình phát triển. Chúng tôi có thể cải thiện trong tương lai gần.

Duyệt web An toàn của Google phiên bản 5 là phiên bản cải tiến của tính năng Duyệt web An toàn của Google phiên bản 4. Hai thay đổi quan trọng được thực hiện trong phiên bản 5 là độ mới của dữ liệu và quyền riêng tư đối với IP. Ngoài ra, giao diện API cũng được cải thiện để tăng tính linh hoạt, hiệu quả và giảm tình trạng cồng kềnh. Ngoài ra, tính năng Duyệt web An toàn của Google phiên bản 5 được thiết kế để giúp bạn dễ dàng di chuyển từ phiên bản 4.

Hiện tại, Google cung cấp cả v4 và v5, và cả hai đều được coi là sẵn sàng phát hành công khai. Bạn có thể sử dụng v4 hoặc v5. Chúng tôi chưa công bố ngày ngừng cung cấp phiên bản 4. Nếu có, chúng tôi sẽ thông báo ít nhất là một năm. Trang này sẽ mô tả phiên bản 5 cũng như hướng dẫn di chuyển từ phiên bản 4 sang phiên bản 5; tài liệu đầy đủ về phiên bản 4 vẫn có sẵn.

Độ mới của dữ liệu

Một điểm cải tiến đáng kể của tính năng Duyệt web An toàn của Google phiên bản 5 so với phiên bản 4 (cụ thể là API Cập nhật phiên bản 4) là độ mới và mức độ phù hợp của dữ liệu. Vì khả năng bảo vệ phụ thuộc nhiều vào cơ sở dữ liệu cục bộ do ứng dụng duy trì, nên độ trễ và quy mô của bản cập nhật cơ sở dữ liệu cục bộ là nguyên nhân chính gây ra tình trạng bảo vệ bị thiếu. Trong phiên bản 4, ứng dụng thông thường mất từ 20 đến 50 phút để lấy phiên bản mới nhất của danh sách mối đe doạ. Thật không may, các cuộc tấn công giả mạo lan truyền rất nhanh: tính đến năm 2021, 60% trang web tiến hành các cuộc tấn công chỉ diễn ra trong chưa đầy 10 phút. Phân tích của chúng tôi cho thấy rằng khoảng 25-30% trường hợp bị thiếu biện pháp bảo vệ chống lừa đảo là do dữ liệu lỗi thời. Ngoài ra, một số thiết bị không được trang bị để quản lý toàn bộ danh sách mối đe doạ của chế độ Duyệt web An toàn của Google. Danh sách này ngày càng lớn hơn theo thời gian.

Ở phiên bản 5, chúng tôi ra mắt một chế độ hoạt động được gọi là bảo vệ theo thời gian thực. Điều này tránh được vấn đề về tình trạng lỗi thời của dữ liệu nêu trên. Trong phiên bản 4, ứng dụng dự kiến sẽ tải xuống và duy trì cơ sở dữ liệu cục bộ, kiểm tra danh sách các mối đe doạ đã tải xuống cục bộ, sau đó khi có kết quả trùng khớp một phần tiền tố, hãy yêu cầu tải toàn bộ hàm băm xuống. Trong phiên bản 5, mặc dù người dùng nên tiếp tục tải xuống và duy trì cơ sở dữ liệu cục bộ của các danh sách mối đe doạ, nhưng ứng dụng giờ đây cũng sẽ tải xuống danh sách các trang web có khả năng vô hại (được gọi là Global Cache), thực hiện cả kiểm tra cục bộ cho Global Cache này cũng như kiểm tra danh sách các mối đe doạ cục bộ và cuối cùng khi có kết quả so khớp một phần tiền tố cho danh sách mối đe doạ hoặc không khớp trong Global Cache, hãy thực hiện yêu cầu tải xuống toàn bộ hàm băm. (Để biết chi tiết về quy trình xử lý cục bộ mà khách hàng yêu cầu, vui lòng xem quy trình được cung cấp bên dưới.) Điều này thể hiện sự thay đổi từ cho phép theo mặc định sang kiểm tra theo mặc định, giúp cải thiện khả năng bảo vệ khi các mối đe doạ trên web được phát tán nhanh hơn. Nói cách khác, đây là giao thức được thiết kế để mang lại khả năng bảo vệ gần như theo thời gian thực: chúng tôi hướng đến việc mang lại cho khách hàng lợi ích từ dữ liệu Duyệt web An toàn mới hơn của Google.

Quyền riêng tư trong IP

Tính năng Duyệt web An toàn của Google (phiên bản 4 hoặc phiên bản 5) không xử lý bất kỳ thông tin nào liên quan đến danh tính của người dùng trong quá trình phân phát yêu cầu. Nếu được gửi, các cookie sẽ bị bỏ qua. Google biết được địa chỉ IP ban đầu của những yêu cầu này, nhưng Google chỉ sử dụng địa chỉ IP này cho các nhu cầu kết nối mạng thiết yếu (tức là để gửi phản hồi) và cho mục đích chống DoS.

Đồng thời với phiên bản 5, chúng tôi ra mắt một API đồng hành có tên là Safe Browsing Oblivious HTTP Gateway API (API cổng vào HTTP Oblivious HTTP của tính năng Duyệt web an toàn). Chế độ cài đặt này sử dụng HTTP rõ ràng để ẩn địa chỉ IP của người dùng cuối khỏi Google. Phương thức này hoạt động bằng cách để một bên thứ ba không liên kết xử lý phiên bản đã mã hoá của yêu cầu của người dùng, sau đó chuyển tiếp phiên bản đó đến Google. Vì vậy, bên thứ ba chỉ có quyền truy cập vào các địa chỉ IP và Google chỉ có quyền truy cập vào nội dung của yêu cầu. Bên thứ ba vận hành Oblivious HTTP Relay (chẳng hạn như dịch vụ này của Fastly) và Google vận hành Oblivious HTTP Gateway. Đây là một API đồng hành không bắt buộc. Khi sử dụng tính năng này cùng với tính năng Duyệt web An toàn của Google, địa chỉ IP của người dùng cuối sẽ không còn được gửi đến Google nữa.

Cách sử dụng phù hợp

Trường hợp sử dụng được phép

Safe Browsing API chỉ dành cho mục đích phi thương mại (có nghĩa là "không dành cho mục đích bán hàng hoặc tạo doanh thu"). Nếu bạn cần một giải pháp cho mục đích thương mại, vui lòng tham khảo phần Rủi ro web.

Giá

Tất cả API Duyệt web An toàn của Google đều miễn phí.

Hạn mức

Nhà phát triển được phân bổ một hạn mức sử dụng mặc định khi bật Safe Browsing API. Bạn có thể xem mức phân bổ và mức sử dụng hiện tại trong Google Developer Console. Nếu muốn sử dụng nhiều hơn hạn mức hiện được phân bổ, bạn có thể yêu cầu hạn mức bổ sung từ giao diện Hạn mức của Developer Console. Chúng tôi xem xét những yêu cầu này và cần liên hệ khi đăng ký tăng hạn mức để đảm bảo rằng dịch vụ của chúng tôi có thể đáp ứng nhu cầu của tất cả người dùng.

URL phù hợp

Tính năng Duyệt web An toàn của Google được thiết kế để thao tác trên các URL sẽ hiển thị trong thanh địa chỉ của trình duyệt. API này không được thiết kế để dùng để kiểm tra các tài nguyên phụ (chẳng hạn như JavaScript hoặc hình ảnh được một tệp HTML tham chiếu hoặc URL WebSocket do JavaScript khởi tạo). Bạn không nên kiểm tra các URL tài nguyên phụ như vậy dựa trên tính năng Duyệt web An toàn của Google.

Nếu việc truy cập vào một URL dẫn đến lệnh chuyển hướng (chẳng hạn như HTTP 301), thì bạn nên kiểm tra URL được chuyển hướng đó dựa trên tính năng Duyệt web An toàn của Google. Thao tác với URL phía máy khách (chẳng hạn như History.pushState) không dẫn đến việc kiểm tra các URL mới dựa trên tính năng Duyệt web An toàn của Google.

Cảnh báo người dùng

Nếu bạn sử dụng tính năng Duyệt web An toàn của Google để cảnh báo người dùng về các rủi ro từ các trang web cụ thể, thì các nguyên tắc sau sẽ được áp dụng.

Các nguyên tắc này giúp bảo vệ cả bạn và Google khỏi hiểu lầm bằng cách làm rõ rằng trang web không được xác định 100% là tài nguyên web không an toàn và các cảnh báo chỉ xác định rủi ro có thể xảy ra.

• Trong cảnh báo hiển thị cho người dùng, bạn không được khiến người dùng tin rằng trang được đề cập chắc chắn là một tài nguyên web không an toàn. Khi đề cập đến trang được xác định hoặc các rủi ro tiềm ẩn mà trang đó có thể gây ra cho người dùng, bạn phải đáp ứng điều kiện về cảnh báo bằng cách sử dụng các cụm từ như: đáng ngờ, có thể xảy ra, có thể, có khả năng xảy ra.
• Cảnh báo của bạn phải cho phép người dùng tìm hiểu thêm bằng cách xem xét định nghĩa của Google về các mối đe doạ khác nhau. Bạn nên dùng các đường liên kết sau:
  • Tấn công phi kỹ thuật: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
  • Phần mềm độc hại và phần mềm không mong muốn: https://developers.google.com/search/docs/monitor-debug/security/malware
  • Ứng dụng có khả năng gây hại (chỉ dành cho Android): https://developers.google.com/android/play-protect/potentially-harmful-applications
• Khi hiển thị cảnh báo cho những trang được Dịch vụ duyệt web an toàn xác định là gây rủi ro, bạn phải ghi nhận tác giả cho Google bằng cách thêm dòng "Tư vấn do Google cung cấp" kèm theo một đường liên kết đến Tư vấn về tính năng Duyệt web an toàn. Nếu sản phẩm của bạn cũng hiển thị cảnh báo dựa trên các nguồn khác, bạn không được đưa thuộc tính Google vào cảnh báo bắt nguồn từ dữ liệu không phải của Google.

• Trong tài liệu về sản phẩm, bạn phải cung cấp thông báo để người dùng biết rằng khả năng bảo vệ mà tính năng Duyệt web An toàn của Google cung cấp là không hoàn hảo. Trang web phải cho người dùng biết rằng có khả năng xảy ra cả kết quả dương tính giả (trang web an toàn bị gắn cờ là rủi ro) và âm tính giả (trang web nguy hiểm không bị gắn cờ). Bạn nên sử dụng ngôn ngữ sau đây:

  Google nỗ lực cung cấp thông tin chính xác và mới nhất về các tài nguyên không an toàn trên web. Tuy nhiên, Google không thể đảm bảo rằng thông tin của mình là toàn diện và không có lỗi: một số trang web nguy hiểm có thể không được xác định và một số trang web an toàn có thể bị xác định nhầm.

Phương thức hoạt động

Tính năng Duyệt web An toàn của Google phiên bản 5 cho phép khách hàng chọn một trong ba chế độ hoạt động.

Chế độ thời gian thực

Khi chọn sử dụng tính năng Duyệt web An toàn của Google phiên bản 5 ở chế độ thời gian thực, khách hàng sẽ duy trì trong cơ sở dữ liệu cục bộ của mình: (i) Bộ nhớ đệm toàn cục của các trang web có khả năng là dữ liệu độc hại, được định dạng dưới dạng hàm băm SHA256 của biểu thức URL host-suffix/path-prefix, (ii) một nhóm danh sách các mối đe doạ có định dạng là tiền tố hàm băm SHA256 của biểu thức URL có tiền tố host-suffix/đường dẫn. Ý tưởng cấp cao là bất cứ khi nào ứng dụng muốn kiểm tra một URL cụ thể, một bước kiểm tra cục bộ sẽ được thực hiện bằng Bộ nhớ đệm chung. Nếu bước kiểm tra đó đạt, thì hệ thống sẽ thực hiện việc kiểm tra danh sách mối đe doạ cục bộ. Nếu không, máy khách sẽ tiếp tục kiểm tra hàm băm theo thời gian thực như trình bày chi tiết bên dưới.

Ngoài cơ sở dữ liệu cục bộ, máy khách sẽ duy trì một bộ nhớ đệm cục bộ. Bộ nhớ đệm cục bộ như vậy không cần phải nằm trong bộ nhớ liên tục và có thể bị xoá trong trường hợp áp lực bộ nhớ.

Dưới đây là thông tin chi tiết về quy trình.

Chế độ danh sách cục bộ

Khi ứng dụng chọn sử dụng tính năng Duyệt web An toàn của Google phiên bản 5 ở chế độ này, hoạt động của ứng dụng sẽ tương tự như API Cập nhật phiên bản 4, ngoại trừ việc sử dụng giao diện API đã cải tiến là phiên bản 5. Ứng dụng sẽ duy trì trong cơ sở dữ liệu cục bộ một bộ danh sách các mối đe doạ có định dạng là tiền tố hàm băm SHA256 của biểu thức URL có tiền tố host-suffix/đường dẫn. Bất cứ khi nào máy khách muốn kiểm tra một URL cụ thể, quy trình kiểm tra sẽ được thực hiện bằng cách sử dụng danh sách mối đe doạ cục bộ. Nếu và chỉ khi có kết quả trùng khớp, máy khách sẽ kết nối với máy chủ để tiếp tục kiểm tra.

Tương tự như trên, máy khách cũng sẽ duy trì một bộ nhớ đệm cục bộ không cần lưu trong bộ nhớ liên tục.

Chế độ thời gian thực không cần bộ nhớ

Khi sử dụng tính năng Duyệt web An toàn của Google phiên bản 5 ở chế độ thời gian thực không cần lưu trữ, ứng dụng không cần duy trì bất kỳ cơ sở dữ liệu cục bộ nào. Bất cứ khi nào máy khách muốn kiểm tra một URL cụ thể, máy khách luôn kết nối với máy chủ để thực hiện kiểm tra. Chế độ này tương tự như chế độ mà các ứng dụng khách của Lookup API phiên bản 4 có thể triển khai.

Đang kiểm tra URL

Phần này trình bày các đặc điểm chi tiết về cách khách hàng kiểm tra URL.

Chuẩn hoá URL

Trước khi kiểm tra bất kỳ URL nào, ứng dụng cần thực hiện một số bước chuẩn hoá trên URL đó.

Để bắt đầu, chúng tôi giả định rằng máy khách đã phân tích cú pháp URL và làm cho URL đó hợp lệ theo RFC 2396. Nếu URL sử dụng tên miền quốc tế hoá (IDN), thì khách hàng phải chuyển đổi URL đó thành mã đại diện ASCII Punycode. URL phải bao gồm một thành phần đường dẫn; tức là URL phải có ít nhất một dấu gạch chéo sau miền (http://google.com/ thay vì http://google.com).

Trước tiên, hãy xoá các ký tự tab (0x09), CR (0x0d) và LF (0x0a) khỏi URL. Không xoá chuỗi ký tự thoát cho những ký tự này (ví dụ: %0a).

Thứ hai, nếu URL kết thúc trong một phân đoạn, hãy xoá phân đoạn đó. Ví dụ: rút ngắn http://google.com/#frag thành http://google.com/.

Thứ ba, liên tục huỷ thoát URL theo phần trăm cho đến khi URL đó không còn số lần thoát nữa. (Điều này có thể khiến URL không hợp lệ.)

Cách chuẩn hoá tên máy chủ:

Trích xuất tên máy chủ từ URL rồi sau đó:

1. Xoá tất cả các dấu chấm ở đầu và cuối.
2. Thay thế các dấu chấm liên tiếp bằng một dấu chấm.
3. Nếu có thể phân tích cú pháp tên máy chủ dưới dạng địa chỉ IPv4, hãy chuẩn hoá thành 4 giá trị thập phân được phân tách bằng dấu chấm. Ứng dụng phải xử lý mọi phương thức mã hoá địa chỉ IP hợp pháp, bao gồm hệ bát phân, hệ thập lục phân và ít hơn 4 thành phần.
4. Nếu có thể phân tích cú pháp tên máy chủ dưới dạng địa chỉ IPv6 trong dấu ngoặc, hãy chuẩn hoá tên máy chủ bằng cách xoá các số 0 ở đầu không cần thiết trong các thành phần và thu gọn những thành phần 0 bằng cách sử dụng cú pháp dấu hai chấm. Ví dụ: [2001:0db8:0000::1] phải được chuyển đổi thành [2001:db8::1]. Nếu tên máy chủ là một trong hai loại địa chỉ IPv6 đặc biệt sau đây, hãy chuyển đổi các địa chỉ đó thành IPv4:
   • Một địa chỉ IPv6 được ánh xạ IPv4, chẳng hạn như [::ffff:1.2.3.4], cần được chuyển đổi thành 1.2.3.4;
   • Địa chỉ NAT64 sử dụng tiền tố phổ biến 64:ff9b::/96, chẳng hạn như [64:ff9b::1.2.3.4], sẽ được chuyển đổi thành 1.2.3.4.
5. Viết thường toàn bộ chuỗi.

Cách chuẩn hoá đường dẫn:

1. Phân giải các trình tự /../ và /./ trong đường dẫn bằng cách thay thế /./ bằng / và xoá /../ cùng với thành phần đường dẫn trước đó.
2. Thay thế các dấu gạch chéo liên tiếp bằng một ký tự dấu gạch chéo.

Đừng áp dụng những chuẩn hoá đường dẫn này cho các tham số truy vấn.

Trong URL, thoát phần trăm tất cả các ký tự <= ASCII 32, >= 127, # hoặc %. Các ký tự thoát phải sử dụng ký tự hex viết hoa.

Biểu thức tiền tố đường dẫn lưu trữ-hậu tố

Khi URL được chuẩn hoá, bước tiếp theo là tạo biểu thức hậu tố/tiền tố. Mỗi biểu thức hậu tố/tiền tố bao gồm một hậu tố máy chủ (hoặc máy chủ lưu trữ đầy đủ) và một tiền tố đường dẫn (hoặc đường dẫn đầy đủ).

Ứng dụng khách sẽ tạo tối đa 30 tổ hợp hậu tố máy chủ và tiền tố đường dẫn khác nhau. Những cách kết hợp này chỉ sử dụng các thành phần máy chủ lưu trữ và đường dẫn của URL. Lược đồ, tên người dùng, mật khẩu và cổng sẽ bị loại bỏ. Nếu URL bao gồm tham số truy vấn, thì ít nhất một kết hợp sẽ bao gồm đường dẫn và tham số truy vấn đầy đủ.

Đối với máy chủ, ứng dụng sẽ thử tối đa 5 chuỗi khác nhau. Các yếu tố này là:

• Nếu tên máy chủ không phải là giá trị cố định IPv4 hoặc IPv6, thì tối đa 4 tên máy chủ được hình thành bằng cách bắt đầu bằng miền eTLD+1 và thêm các thành phần đầu liên tiếp. Cách xác định eTLD+1 phải dựa trên Danh sách hậu tố công khai. Ví dụ: a.b.example.com sẽ dẫn đến miền eTLD+1 của example.com cũng như máy chủ lưu trữ có thêm một thành phần máy chủ lưu trữ b.example.com.
• Tên chính xác trong URL. Tiếp nối ví dụ trước, a.b.example.com sẽ được kiểm tra.

Đối với đường dẫn, ứng dụng sẽ thử tối đa 6 chuỗi. Các yếu tố này là:

• Đường dẫn chính xác của URL, bao gồm cả các tham số truy vấn.
• Đường dẫn chính xác của URL, không có tham số truy vấn.
• Bốn đường dẫn được hình thành bằng cách bắt đầu từ gốc (/) và liên tiếp thêm các thành phần đường dẫn, bao gồm cả dấu gạch chéo ở cuối.

Các ví dụ sau minh hoạ hành vi kiểm tra:

Đối với URL http://a.b.com/1/2.html?param=1, ứng dụng sẽ thử các chuỗi có thể dùng sau:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

Đối với URL http://a.b.c.d.e.f.com/1.html, ứng dụng sẽ thử các chuỗi có thể dùng sau:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(Lưu ý: bỏ qua b.c.d.e.f.com, vì chúng ta chỉ lấy 5 thành phần tên máy chủ cuối cùng và tên đầy đủ.)

Đối với URL http://1.2.3.4/1/, ứng dụng sẽ thử các chuỗi có thể dùng sau:

1.2.3.4/1/
1.2.3.4/

Đối với URL http://example.co.uk/1, ứng dụng sẽ thử các chuỗi có thể dùng sau:

example.co.uk/1
example.co.uk/

Băm

Tính năng Duyệt web An toàn của Google chỉ sử dụng SHA256 làm hàm băm. Hàm băm này sẽ được áp dụng cho các biểu thức ở trên.

Hàm băm 32 byte đầy đủ, tùy thuộc vào trường hợp, sẽ được cắt ngắn thành 4 byte, 8 byte hoặc 16 byte:

• Hiện tại, khi sử dụng phương thức băm.search, chúng tôi yêu cầu bạn phải cắt bớt các hàm băm trong yêu cầu xuống đúng 4 byte. Việc gửi thêm byte trong yêu cầu này sẽ xâm phạm quyền riêng tư của người dùng.

• Khi tải danh sách cho cơ sở dữ liệu cục bộ xuống bằng phương thức hashList.get hoặc phương thức bămLists.batchGet, độ dài của hàm băm do máy chủ gửi chịu ảnh hưởng của cả tính chất của danh sách và lựa chọn ưu tiên của khách hàng về độ dài hàm băm (thông qua tham số desired_hash_length).

Quy trình kiểm tra URL theo thời gian thực

Quy trình này được dùng khi ứng dụng chọn chế độ hoạt động theo thời gian thực.

Quy trình này lấy một URL duy nhất u và trả về SAFE, UNSAFE hoặc UNSURE. Nếu trả về SAFE, URL đó sẽ được dịch vụ Duyệt web An toàn của Google coi là an toàn. Nếu trả về UNSAFE, URL đó bị tính năng Duyệt web An toàn của Google cho là có thể không an toàn. Do đó, bạn cần thực hiện hành động thích hợp, chẳng hạn như hiển thị cảnh báo cho người dùng cuối, chuyển thư đã nhận vào thư mục thư rác hoặc yêu cầu người dùng xác nhận thêm trước khi tiếp tục. Nếu hàm này trả về UNSURE, thì bạn nên sử dụng quy trình kiểm tra cục bộ sau đây.

1. Đặt expressions là danh sách biểu thức hậu tố/tiền tố do URL u tạo.
2. Đặt expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của mỗi biểu thức trong expressions.
3. Đối với mỗi hash của expressionHashes:
   1. Nếu có thể tìm thấy hash trong bộ nhớ đệm chung, hãy trả về UNSURE.
4. Đặt expressionHashPrefixes là một danh sách, trong đó các phần tử là 4 byte đầu tiên của mỗi hàm băm trong expressionHashes.
5. Đối với mỗi expressionHashPrefix của expressionHashPrefixes:
   1. Tra cứu expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục được lưu vào bộ nhớ đệm:
      1. Xác định xem thời gian hiện tại có lớn hơn thời gian hết hạn hay không.
      2. Nếu giá trị lớn hơn:
         1. Xoá mục nhập đã lưu vào bộ nhớ đệm được tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục với vòng lặp.
      3. Nếu không lớn hơn:
         1. Xoá expressionHashPrefix cụ thể này khỏi expressionHashPrefixes.
         2. Kiểm tra xem có tìm thấy hàm băm đầy đủ tương ứng trong expressionHashes trong mục đã lưu vào bộ nhớ đệm hay không.
         3. Nếu tìm thấy, hãy trả về UNSAFE.
         4. Nếu không tìm thấy, hãy tiếp tục với vòng lặp.
   3. Nếu không tìm thấy mục được lưu vào bộ nhớ đệm, hãy tiếp tục với vòng lặp.
6. Gửi expressionHashPrefixes đến máy chủ Duyệt web An toàn của Google phiên bản 5 bằng RPC SearchHashes hoặc phương thức REST hashes.search. Nếu xảy ra lỗi (bao gồm cả lỗi mạng, lỗi HTTP, v.v.), hãy trả về UNSURE. Nếu không, hãy nhập phản hồi là response nhận được từ máy chủ SB. Đây là danh sách các hàm băm đầy đủ cùng với một số thông tin phụ trợ xác định bản chất của mối đe doạ (tấn công phi kỹ thuật, phần mềm độc hại, v.v.), cũng như thời gian hết hạn của bộ nhớ đệm expiration.
7. Đối với mỗi fullHash của response:
   1. Chèn fullHash vào bộ nhớ đệm cục bộ, cùng với expiration.
8. Đối với mỗi fullHash của response:
   1. Đặt isFound là kết quả của việc tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục với vòng lặp.
   3. Nếu giá trị isFound là True, hãy trả về UNSAFE.
9. Trả lại SAFE.

Quy trình kiểm tra URL của danh sách mối đe doạ cục bộ

Quy trình này được dùng khi ứng dụng chọn chế độ hoạt động của danh sách cục bộ. Hàm này cũng được dùng khi máy khách, quy trình RealTimeCheck ở trên trả về giá trị UNSURE.

Quy trình này lấy một URL duy nhất u và trả về SAFE hoặc UNSAFE.

1. Đặt expressions là danh sách biểu thức hậu tố/tiền tố do URL u tạo.
2. Đặt expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của mỗi biểu thức trong expressions.
3. Đặt expressionHashPrefixes là một danh sách, trong đó các phần tử là 4 byte đầu tiên của mỗi hàm băm trong expressionHashes.
4. Đối với mỗi expressionHashPrefix của expressionHashPrefixes:
   1. Tra cứu expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục được lưu vào bộ nhớ đệm:
      1. Xác định xem thời gian hiện tại có lớn hơn thời gian hết hạn hay không.
      2. Nếu giá trị lớn hơn:
         1. Xoá mục nhập đã lưu vào bộ nhớ đệm được tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục với vòng lặp.
      3. Nếu không lớn hơn:
         1. Xoá expressionHashPrefix cụ thể này khỏi expressionHashPrefixes.
         2. Kiểm tra xem có tìm thấy hàm băm đầy đủ tương ứng trong expressionHashes trong mục đã lưu vào bộ nhớ đệm hay không.
         3. Nếu tìm thấy, hãy trả về UNSAFE.
         4. Nếu không tìm thấy, hãy tiếp tục với vòng lặp.
   3. Nếu không tìm thấy mục được lưu vào bộ nhớ đệm, hãy tiếp tục với vòng lặp.
5. Đối với mỗi expressionHashPrefix của expressionHashPrefixes:
   1. Tra cứu expressionHashPrefix trong cơ sở dữ liệu danh sách mối đe doạ cục bộ.
   2. Nếu không tìm thấy expressionHashPrefix trong cơ sở dữ liệu danh sách mối đe doạ cục bộ, hãy xoá khỏi expressionHashPrefixes.
6. Gửi expressionHashPrefixes đến máy chủ Duyệt web An toàn của Google phiên bản 5 bằng RPC SearchHashes hoặc phương thức REST hashes.search. Nếu xảy ra lỗi (bao gồm cả lỗi mạng, lỗi HTTP, v.v.), hãy trả về SAFE. Nếu không, hãy nhập phản hồi là response nhận được từ máy chủ SB. Đây là danh sách các hàm băm đầy đủ cùng với một số thông tin phụ trợ xác định bản chất của mối đe doạ (tấn công phi kỹ thuật, phần mềm độc hại, v.v.), cũng như thời gian hết hạn của bộ nhớ đệm expiration.
7. Đối với mỗi fullHash của response:
   1. Chèn fullHash vào bộ nhớ đệm cục bộ, cùng với expiration.
8. Đối với mỗi fullHash của response:
   1. Đặt isFound là kết quả của việc tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục với vòng lặp.
   3. Nếu giá trị isFound là True, hãy trả về UNSAFE.
9. Trả lại SAFE.

Quy trình kiểm tra URL theo thời gian thực không có cơ sở dữ liệu cục bộ

Quy trình này được dùng khi ứng dụng chọn chế độ hoạt động theo thời gian thực không lưu trữ.

Quy trình này lấy một URL duy nhất u và trả về SAFE hoặc UNSAFE.

1. Đặt expressions là danh sách biểu thức hậu tố/tiền tố do URL u tạo.
2. Đặt expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của mỗi biểu thức trong expressions.
3. Đặt expressionHashPrefixes là một danh sách, trong đó các phần tử là 4 byte đầu tiên của mỗi hàm băm trong expressionHashes.
4. Đối với mỗi expressionHashPrefix của expressionHashPrefixes:
   1. Tra cứu expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục được lưu vào bộ nhớ đệm:
      1. Xác định xem thời gian hiện tại có lớn hơn thời gian hết hạn hay không.
      2. Nếu giá trị lớn hơn:
         1. Xoá mục nhập đã lưu vào bộ nhớ đệm được tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục với vòng lặp.
      3. Nếu không lớn hơn:
         1. Xoá expressionHashPrefix cụ thể này khỏi expressionHashPrefixes.
         2. Kiểm tra xem có tìm thấy hàm băm đầy đủ tương ứng trong expressionHashes trong mục đã lưu vào bộ nhớ đệm hay không.
         3. Nếu tìm thấy, hãy trả về UNSAFE.
         4. Nếu không tìm thấy, hãy tiếp tục với vòng lặp.
   3. Nếu không tìm thấy mục được lưu vào bộ nhớ đệm, hãy tiếp tục với vòng lặp.
5. Gửi expressionHashPrefixes đến máy chủ Duyệt web An toàn của Google phiên bản 5 bằng RPC SearchHashes hoặc phương thức REST hashes.search. Nếu xảy ra lỗi (bao gồm cả lỗi mạng, lỗi HTTP, v.v.), hãy trả về SAFE. Nếu không, hãy nhập phản hồi là response nhận được từ máy chủ SB. Đây là danh sách các hàm băm đầy đủ cùng với một số thông tin phụ trợ xác định bản chất của mối đe doạ (tấn công phi kỹ thuật, phần mềm độc hại, v.v.), cũng như thời gian hết hạn của bộ nhớ đệm expiration.
6. Đối với mỗi fullHash của response:
   1. Chèn fullHash vào bộ nhớ đệm cục bộ, cùng với expiration.
7. Đối với mỗi fullHash của response:
   1. Đặt isFound là kết quả của việc tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục với vòng lặp.
   3. Nếu giá trị isFound là True, hãy trả về UNSAFE.
8. Trả lại SAFE.

Bảo trì cơ sở dữ liệu cục bộ

Duyệt web An toàn của Google phiên bản 5 mong muốn ứng dụng duy trì cơ sở dữ liệu cục bộ, trừ phi ứng dụng chọn Chế độ thời gian thực không cần bộ nhớ. Định dạng và việc lưu trữ cơ sở dữ liệu cục bộ này là tuỳ thuộc vào máy khách. Trên lý thuyết, nội dung của cơ sở dữ liệu cục bộ này có thể được coi là một thư mục chứa nhiều danh sách dưới dạng tệp và nội dung của các tệp này là hàm băm SHA256 hoặc tiền tố băm.

Cập nhật cơ sở dữ liệu

Ứng dụng sẽ thường xuyên gọi phương thức hashList.get hoặc phương thức hashLists.batchGet để cập nhật cơ sở dữ liệu. Vì ứng dụng thông thường sẽ muốn cập nhật nhiều danh sách cùng một lúc, bạn nên sử dụng phương thức hashLists.batchGet.

Danh sách được xác định bằng tên riêng biệt. Tên là các chuỗi ASCII ngắn và dài vài ký tự.

Không giống như V4, trong đó các danh sách được xác định theo bộ dữ liệu về kiểu mối đe doạ, loại nền tảng, kiểu mục nhập mối đe doạ, trong danh sách phiên bản 5 chỉ đơn giản là được xác định theo tên. Điều này mang lại sự linh hoạt khi nhiều danh sách phiên bản 5 có thể có cùng một kiểu mối đe doạ. Các loại nền tảng và loại mục nhập mối đe doạ sẽ bị xoá trong phiên bản 5.

Sau khi bạn chọn một tên cho danh sách, tên đó sẽ không bao giờ được đổi tên. Hơn nữa, một khi danh sách đã xuất hiện, danh sách đó sẽ không bao giờ bị xoá (nếu danh sách không còn hữu ích, danh sách sẽ trở nên trống nhưng sẽ tiếp tục tồn tại). Do đó, bạn nên mã hoá cứng các tên này trong mã ứng dụng khách của dịch vụ Duyệt web An toàn của Google.

Cả phương thức hashList.get và phương thức hashLists.batchGet đều hỗ trợ việc cập nhật gia tăng. Việc sử dụng các bản cập nhật gia tăng sẽ giúp tiết kiệm băng thông và cải thiện hiệu suất. Cập nhật gia tăng hoạt động bằng cách phân phối delta giữa phiên bản danh sách của ứng dụng khách và phiên bản mới nhất của danh sách. (Nếu ứng dụng mới được triển khai và chưa có phiên bản nào, thì bản cập nhật đầy đủ sẽ có sẵn.) Bản cập nhật gia tăng chứa các chỉ mục xoá và bổ sung. Trước tiên, ứng dụng dự kiến sẽ xoá các mục nhập tại các chỉ mục được chỉ định khỏi cơ sở dữ liệu cục bộ, sau đó áp dụng các mục bổ sung.

Cuối cùng, để tránh bị hỏng, máy khách phải kiểm tra dữ liệu đã lưu trữ với giá trị tổng kiểm do máy chủ cung cấp. Bất cứ khi nào giá trị tổng kiểm không khớp, ứng dụng sẽ thực hiện cập nhật đầy đủ.

Giải mã nội dung danh sách

Tất cả danh sách đều được phân phối bằng mã hóa đặc biệt để giảm kích thước. Về mặt lý thuyết, chế độ mã hoá này hoạt động bằng cách nhận ra rằng danh sách Duyệt web An toàn của Google chứa một nhóm các tiền tố băm hoặc tiền tố băm mà về mặt thống kê không thể phân biệt được với số nguyên ngẫu nhiên. Nếu chúng ta sắp xếp các số nguyên này và lấy sự khác biệt liền kề của chúng, thì sự khác biệt liền kề như vậy được dự kiến là "nhỏ" theo nghĩa. Sau đó, phương thức mã hoá Golomb-Rice sẽ khai thác độ nhỏ này.

Duyệt web An toàn của Google phiên bản 5 có bốn loại riêng biệt để xử lý dữ liệu 4 byte, dữ liệu 8 byte, dữ liệu 16 byte và dữ liệu 32 byte. Hãy xem ví dụ trong đó ba số nguyên 4 byte liên tiếp được mã hóa. Hãy để tham số gạo, được biểu thị bằng k, là 3. Thương số của quá trình mã hoá chỉ đơn giản là giá trị chênh lệch liền kề được dịch chuyển sang phải k bit. Vì các số nguyên đã cho liên tiếp, hiệu số liền kề của chúng là 1, và sau khi dịch chuyển 3 bit thì phần thương số sẽ bằng 0. Các bit k có ý nghĩa nhỏ nhất là 001. Thương số 0 được mã hoá dưới dạng một bit 0. Số còn lại là 1 và được mã hoá là 100. Thao tác này được lặp lại một lần nữa để tạo thành luồng bit 01000100. Luồng bit thu được được mã hoá bằng ít endian dưới dạng 00100010. Do đó, dữ liệu này tương ứng với dữ liệu sau:

rice_parameter: 3
entries_count: 2
encoded_data: "\x22"

Sau bước giải mã ở trên cho số nguyên 32 bit, kết quả có thể sử dụng trực tiếp làm chỉ mục xoá hoặc bổ sung. Không giống như v4, bạn không cần thực hiện hoán đổi byte sau đó.

Danh sách hiện có

Bạn nên sử dụng các danh sách sau đây trong phiên bản 5alpha1:

Tên danh sách	Enum ThreatType tương ứng	Nội dung mô tả
gc	Không có	Đây là một danh sách trên Bộ nhớ đệm chung. Đây là một danh sách đặc biệt chỉ được dùng trong chế độ Thời gian thực hoạt động.
se	SOCIAL_ENGINEERING	Danh sách này chứa các mối đe doạ thuộc kiểu mối đe doạ SOCIAL_EngineERING.
mw	MALWARE	Danh sách này chứa các mối đe doạ thuộc kiểu mối đe doạ MALWARE dành cho nền tảng máy tính.
uws	UNWANTED_SOFTWARE	Danh sách này chứa các mối đe doạ thuộc kiểu mối đe doạ UNWANTED_SOFTWARE đối với nền tảng máy tính.
uwsa	UNWANTED_SOFTWARE	Danh sách này chứa các mối đe doạ thuộc kiểu mối đe doạ UNWANTED_SOFTWARE đối với các nền tảng Android.
pha	POTENTIALLY_HARMFUL_APPLICATION	Danh sách này chứa các mối đe doạ thuộc kiểu mối đe doạ POTENTIALLY_HARMFUL_APPLICATION cho các nền tảng Android.

Các danh sách bổ sung sẽ có sẵn trong tương lai, trong thời gian đó bảng ở trên sẽ được mở rộng.

Tần suất cập nhật

Ứng dụng phải kiểm tra giá trị được trả về của máy chủ trong trường minimum_wait_duration rồi sử dụng trường đó để lên lịch cập nhật cơ sở dữ liệu tiếp theo. Giá trị này có thể bằng 0. Trong trường hợp đó, ứng dụng nên thực hiện cập nhật khác ngay lập tức.

Ví dụ về yêu cầu

Phần này trình bày một số ví dụ về cách trực tiếp sử dụng API HTTP để truy cập tính năng Duyệt web An toàn của Google. Bạn nên sử dụng liên kết ngôn ngữ đã tạo vì liên kết này sẽ tự động xử lý việc mã hoá và giải mã theo cách thuận tiện. Vui lòng tham khảo tài liệu về mối liên kết đó.

Dưới đây là một yêu cầu HTTP mẫu bằng phương pháp băm.search:

GET https://safebrowsing.googleapis.com/v5/hashes:search?key=INSERT_YOUR_API_KEY_HERE&hashPrefixes=WwuJdQ

Nội dung phản hồi là một tải trọng được định dạng bộ đệm giao thức mà sau đó bạn có thể giải mã.

Dưới đây là một yêu cầu HTTP mẫu sử dụng phương thức hashLists.batchGet:

GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet?key=INSERT_YOUR_API_KEY_HERE&names=se&names=mw

Nội dung phản hồi một lần nữa là một tải trọng được định dạng vùng đệm giao thức mà sau đó bạn có thể giải mã.

Hướng dẫn di chuyển

Nếu đang sử dụng API Cập nhật phiên bản 4, bạn có thể di chuyển liền mạch từ phiên bản 4 sang phiên bản 5 mà không cần đặt lại hoặc xoá cơ sở dữ liệu cục bộ. Phần này trình bày cách làm việc đó.

Cập nhật danh sách chuyển đổi

Trong phiên bản 4, người dùng sẽ sử dụng phương thức threatListUpdates.fetch để tải danh sách xuống. Trong phiên bản 5, một phương thức sẽ chuyển sang phương thức hashLists.batchGet.

Các thay đổi sau đây sẽ được thực hiện đối với yêu cầu:

1. Xoá hoàn toàn đối tượng ClientInfo phiên bản 4. Thay vì cung cấp thông tin nhận dạng khách hàng thông qua một trường chuyên biệt, chỉ cần sử dụng tiêu đề Tác nhân người dùng phổ biến. Mặc dù không có định dạng được quy định nào để cung cấp mã nhận dạng khách hàng trong tiêu đề này, nhưng bạn chỉ nên bao gồm mã ứng dụng khách ban đầu và phiên bản ứng dụng khách được phân tách bằng ký tự dấu cách hoặc dấu gạch chéo.
2. Đối với mỗi đối tượng ListUpdateRequest phiên bản 4:
   • Tra cứu tên danh sách v5 tương ứng trong bảng trên và cung cấp tên đó trong yêu cầu v5.
   • Xoá các trường không cần thiết như threat_entry_type hoặc platform_type.
   • Trường state trong phiên bản 4 tương thích trực tiếp với trường versions của phiên bản 5. Bạn có thể dùng trường versions để gửi cùng một chuỗi byte sẽ được gửi tới máy chủ thông qua trường state trong v4.
   • Đối với các điều kiện ràng buộc bằng v4, v5 sử dụng một phiên bản được đơn giản hoá có tên là SizeConstraints. Bạn nên bỏ các trường bổ sung như region.

Các thay đổi sau đây sẽ được thực hiện đối với phản hồi:

1. enum ResponseType v4 chỉ được thay thế bằng trường boolean có tên partial_update.
2. Trường minimum_wait_duration hiện có thể bằng 0 hoặc bị bỏ qua. Nếu có, ứng dụng sẽ được yêu cầu ngay lập tức gửi một yêu cầu khác. Điều này chỉ xảy ra khi ứng dụng chỉ định trong SizeConstraints một quy tắc ràng buộc nhỏ hơn về kích thước bản cập nhật tối đa so với kích thước tối đa của cơ sở dữ liệu.
3. Thuật toán giải mã gạo cho số nguyên 32 bit sẽ cần được điều chỉnh. Sự khác biệt là dữ liệu đã mã hoá được mã hoá với tính chất cuối khác. Trong cả v4 và v5, các tiền tố băm 32 bit được sắp xếp theo từ vựng. Nhưng trong v4, các tiền tố đó được xử lý là endian nhỏ khi được sắp xếp, trong khi trong v5, các tiền tố đó được coi là endian lớn khi được sắp xếp. Điều này có nghĩa là ứng dụng không cần thực hiện bất kỳ sắp xếp nào, vì cách sắp xếp theo từ vựng giống hệt với việc sắp xếp số với ký tự cuối lớn. Bạn có thể xem ví dụ về loại này trong quá trình triển khai Chromium phiên bản 4 tại đây. Bạn có thể xoá cách sắp xếp như vậy.
4. Bạn cần triển khai thuật toán giải mã gạo cho các độ dài hàm băm khác.

Chuyển đổi tìm kiếm hàm băm

Trong phiên bản 4, bạn cần sử dụng phương thức fullHashes.find để có được toàn bộ hàm băm. Phương thức tương đương trong phiên bản 5 là phương thức băm.search.

Các thay đổi sau đây sẽ được thực hiện đối với yêu cầu:

1. Cấu trúc mã để chỉ gửi các tiền tố băm có độ dài chính xác 4 byte.
2. Xoá hoàn toàn các đối tượng ClientInfo phiên bản 4. Thay vì cung cấp thông tin nhận dạng khách hàng thông qua một trường chuyên biệt, chỉ cần sử dụng tiêu đề Tác nhân người dùng phổ biến. Mặc dù không có định dạng được quy định nào để cung cấp mã nhận dạng khách hàng trong tiêu đề này, nhưng bạn chỉ nên bao gồm mã ứng dụng khách ban đầu và phiên bản ứng dụng khách được phân tách bằng ký tự dấu cách hoặc dấu gạch chéo.
3. Xoá trường client_states. Dữ liệu này không còn cần thiết nữa.
4. Bạn không cần đưa threat_types và các trường tương tự vào nữa.

Các thay đổi sau đây sẽ được thực hiện đối với phản hồi:

1. Trường minimum_wait_duration đã bị xoá. Máy khách luôn có thể tạo yêu cầu mới khi cần.
2. Đối tượng ThreatMatch phiên bản 4 đã được đơn giản hoá thành đối tượng FullHash.
3. Chức năng lưu vào bộ nhớ đệm đã được đơn giản hoá thành một thời lượng lưu vào bộ nhớ đệm. Xem các quy trình ở trên để tương tác với bộ nhớ đệm.