Overview

Làm mới 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 v4) là độ mới và mức độ sử dụng của dữ liệu. Vì khả năng bảo vệ phụ thuộc rất lớn vào cơ sở dữ liệu cục bộ do ứng dụng duy trì, nên sự chậm trễ và kích thước của bản cập nhật cơ sở dữ liệu cục bộ là yếu tố chính khiến thiếu khả năng bảo vệ. Trong phiên bản 4, ứng dụng điển hình mất từ 20 đến 50 phút để có được phiên bản mới nhất của danh sách các mối đe doạ. Đáng tiếc là các cuộc tấn công giả mạo lại lan truyền rất nhanh: tính đến năm 2021, 60% số trang web thực hiện các cuộc tấn công diễn ra dưới 10 phút. Theo phân tích của chúng tôi, khoảng 25-30% trường hợp thiếu tính năng bảo vệ chống lừa đảo là do dữ liệu đã lỗi thời. Hơn nữa, 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 tính năng Duyệt web An toàn của Google, và danh sách này vẫn tiếp tục gia tăng 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 giúp tránh vấn đề lỗi thời của dữ liệu nêu trên. Trong phiên bản 4, ứng dụng cần tải xuống và duy trì cơ sở dữ liệu cục bộ, kiểm tra danh sách 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 với tiền tố, hãy yêu cầu tải hàm băm đầy đủ xuống. Trong phiên bản 5, mặc dù ứng 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ạ, các ứng dụng khách hiện cũng cần 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 mối đe doạ cục bộ và cuối cùng khi có một phần tiền tố phù hợp cho danh sách mối đe doạ hoặc không có kết quả trùng khớp trong Global Cache, 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ý tại địa phương theo yêu cầu của khách hàng, vui lòng xem quy trình được cung cấp bên dưới.) Điều này thể hiện sự chuyển đổi từ cho phép theo mặc định sang kiểm tra theo mặc định. Điều này có thể cải thiện khả năng bảo vệ trong bối cảnh các mối đe doạ lan truyền nhanh hơn trên web. Nói cách khác, đây là giao thức được thiết kế nhằm cung cấp khả năng bảo vệ gần như theo thời gian thực: chúng tôi mong muốn giúp khách hàng được hưởng lợi từ dữ liệu Duyệt web An toàn mới hơn của Google.

Quyền riêng tư đối với địa chỉ 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 các yêu cầu. Nếu được gửi, cookie sẽ bị bỏ qua. Google biết địa chỉ IP ban đầu của các yêu cầu nhưng chỉ sử dụng địa chỉ IP cho các nhu cầu kết nối mạng thiết yếu (ví dụ: để gửi phản hồi) và cho mục đích chống DoS.

Cùng với phiên bản 5, chúng tôi cũng ra mắt một API đồng hành có tên là Safe Browsing Oblivious HTTP Gateway API. Tùy chọn này sử dụng HTTP Oblivious để ẩn thông tin Địa chỉ IP của Google. Dịch vụ này hoạt động bằng cách có một bên thứ ba không thông 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. Do đó, bên thứ ba chỉ có quyền truy cập vào đị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 không còn được gửi tới Google nữa.

Hoạt động sử dụng được phép

Safe Browsing API chỉ dành cho mục đích sử dụng phi thương mại (nghĩa là "không nhằm 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ả các API Duyệt web An toàn của Google đều miễn phí.

Hạn mức

Nhà phát triển sẽ đượ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ổ của mình, 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à yêu cầu bạn liên hệ khi đăng ký tăng hạn mức nhằm đảm bảo rằng dịch vụ của chúng tôi có thể đáp ứng được 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ế để hoạt động trên các URL sẽ hiển thị trong thanh địa chỉ của trình duyệt. Mã này không được thiết kế để dùng để kiểm tra các nguồn phụ (chẳng hạn như JavaScript hoặc hình ảnh được tham chiếu bởi tệp HTML 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 một URL dẫn đến lệnh chuyển hướng (chẳng hạn như HTTP 301) thì có thể 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. Việc thao túng URL phía máy khách như History.pushState sẽ 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 dành cho 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ề những rủi ro từ các trang web cụ thể, thì bạn sẽ áp dụng các nguyên tắc sau.

Những 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 không được xác định một cách chắc chắn 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 tiềm ẩn.

• 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 là tài nguyên web không an toàn. Khi đề cập đến trang đang đượ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 đủ điều kiện đưa ra cảnh báo bằng cách sử dụng các cụm từ như: nghi ngờ, có khả năng, có thể, có khả năng.
• Cảnh báo của bạn phải giú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ề nhiều mối đe doạ. Bạn nên sử 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 các trang được xác định là có nguy cơ do Dịch vụ Duyệt web an toàn xác định, 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" có đường liên kết đến trang Tư vấn 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 vào các nguồn khác thì bạn không được đưa thuộc tính của 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 đưa ra thông báo để người dùng biết rằng tính năng bảo vệ của tính năng Duyệt web An toàn của Google không hoàn hảo. Bạn phải cho họ biết rằng có khả năng xảy ra cả trường hợp dương tính giả (trang web an toàn bị gắn cờ là có rủi ro) và có kết quả âm tính giả (trang web có nguy cơ không bị gắn cờ). Bạn nên dùng ngôn từ sau:

  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à đầy đủ 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ể được xác định do nhầm lẫn.

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 chung của các trang web có khả năng là vô hại, có định dạng là hàm băm SHA256 của biểu thức URL hậu tố máy chủ/path-prefix, (ii) một nhóm danh sách mối đe doạ, có định dạng là tiền tố băm SHA256 của các biểu thức URL hậu tố máy chủ/đường dẫn. Ý tưởng cấp cao là bất cứ khi nào khách hàng muốn kiểm tra một URL cụ thể, kiểm tra cục bộ sẽ được thực hiện bằng cách sử dụng Bộ nhớ đệm chung. Nếu bước kiểm tra đó thành công, thì quy trình kiểm tra danh sách mối đe doạ cục bộ sẽ được thực hiện. 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ộ. Một 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 có áp lực về bộ nhớ.

Dưới đây là thông số kỹ thuật chi tiết về quy trình này.

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

Khi khách hà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, hành vi của ứng dụng sẽ tương tự như API Cập nhật v4, ngoại trừ việc sử dụng giao diện API được cải tiến của phiên bản 5. Trong cơ sở dữ liệu cục bộ của mình, các ứng dụng sẽ lưu giữ một tập hợp danh sách các mối đe doạ có định dạng là tiền tố băm SHA256 của các biểu thức URL host-suffix/path-prefix. Bất cứ khi nào khách hàng muốn kiểm tra một URL cụ thể, ứng dụng sẽ sử dụng danh sách các mối đe doạ cục bộ để kiểm tra. 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 ở trong bộ nhớ liên tục.

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

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ế độ theo thời gian thực không lưu trữ, ứng dụng không cần duy trì bất kỳ cơ sở dữ liệu cục bộ ổn định nào. Tuy nhiên, máy khách vẫn cần duy trì một bộ nhớ đệm cục bộ. Một 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 có áp lực về bộ nhớ.

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ư các ứng dụng khách của API Lookup v4 có thể triển khai.

So với Chế độ thời gian thực, chế độ này có thể sử dụng nhiều băng thông mạng hơn nhưng có thể phù hợp hơn nếu gây bất tiện cho ứng dụng khách trong việc duy trì trạng thái cục bộ ổn định.

Chuẩn hoá URL

Trước khi kiểm tra bất kỳ URL nào, máy khách cần thực hiện một số quy trình 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), ứng dụng phải chuyển đổi URL sang dạng cách trình bày mã Puny theo ASCII. URL phải bao gồm một thành phần đường dẫn; tức là phải có ít nhất một dấu gạch chéo theo sau miền (http://google.com/ thay vì http://google.com).

Đầu tiên, xóa các ký tự tab (0x09), CR (0x0d) và LF (0x0a) khỏi URL. Không được 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 %-unescape URL cho đến khi không còn phần trăm thoát. (Đ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 và 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 duy nhất.
3. Nếu tên máy chủ có thể được phân tích cú pháp dưới dạng địa chỉ IPv4, hãy chuẩn hoá tên máy chủ thành 4 giá trị thập phân được phân tách bằng dấu chấm. Khách hà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 tên máy chủ có thể được phân tích cú pháp như một đị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 các thành phần 0 bằ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 chúng thành IPv4:
   • Địa chỉ IPv6 liên kết với 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], cần đượ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 duy nhất.

Không áp dụng các quá trình chuẩn hoá đường dẫn này cho các tham số truy vấn.

Trong URL, ký tự thoát dạng phần trăm cho tất 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ố

Sau khi URL chính tắc, 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 này sẽ tạo thành tối đa 30 tổ hợp tiền tố đường dẫn và hậu tố máy chủ lưu trữ khác nhau. Những kiểu kết hợp này chỉ sử dụng thành phần đường dẫn và máy chủ lưu trữ 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 chứa tham số truy vấn, thì ít nhất một tổ hợp sẽ có đường dẫn và tham số truy vấn đầy đủ.

Đối với máy chủ lưu trữ, ứ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à IPv4 hoặc IPv6 cố định, thì tối đa 4 tên máy chủ được tạo bằng cách bắt đầu bằng miền eTLD+1 và thêm các thành phần đứng đầu kế tiếp. Việc 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 máy chủ 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 khác nhau. 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 ở gốc (/) và nối liên tiếp các thành phần đường dẫn, bao gồm cả một dấu gạch chéo ở cuối.

Các ví dụ sau đây 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 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 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 tôi sẽ chỉ lấy 5 thành phần tên máy chủ cuối cùng và toàn bộ tên máy chủ.)

Đối với URL http://1.2.3.4/1/, ứng dụng sẽ thử các chuỗi 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 sau:

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

Băm

Tính năng Duyệt web An toàn của Google sử dụng riêng SHA256 làm hàm băm. Bạn phải áp dụng hàm băm này cho các biểu thức trên.

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

• Hiện tại, khi sử dụng phương thức hashes.search, chúng tôi yêu cầu hàm băm trong yêu cầu phải được cắt ngắn còn chính xác 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 bămList.get hoặc phương thức hashLists.batchGet, độ dài hàm băm mà máy chủ gửi sẽ chịu ảnh hưởng của cả bản chất của danh sách và lựa chọn ưu tiên của ứng dụng về độ dài hàm băm (được thông báo bằng tham số desired_hash_length).

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

Quy trình này được sử 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 u và trả về SAFE, UNSAFE hoặc UNSURE. Nếu trả về SAFE, thì URL được tính năng Duyệt web An toàn của Google coi là an toàn. Nếu trả về UNSAFE, thì URL bị tính năng Duyệt web An toàn của Google cho là có thể không an toàn và bạn cần có biện pháp xử lý 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 trả về UNSURE, thì sau đó, 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 các biểu thức hậu tố/tiền tố do URL u tạo.
2. Cho expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của từng biểu thức trong expressions.
3. Đối với mỗi hash/expressionHashes:
   1. Nếu tìm thấy hash trong bộ nhớ đệm chung, hãy trả về UNSURE.
4. Giả sử 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/expressionHashPrefixes:
   1. Tìm expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục nhập đượ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 trong bộ nhớ đệm mà hệ thống tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục vòng lặp.
      3. Nếu giá trị 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 nhập đã 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òng lặp.
   3. Nếu không tìm thấy mục nhập đã lưu vào bộ nhớ đệm, hãy tiếp tục 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 lỗi mạng, lỗi HTTP, v.v.), hãy trả về UNSURE. Nếu không, phản hồi là response nhận được từ máy chủ SB. Đây là danh sách 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 bộ nhớ đệm expiration.
7. Đối với mỗi fullHash/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/response:
   1. Cho isFound là kết quả tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục vòng lặp.
   3. Nếu isFound là True, hãy trả về UNSAFE.
9. Trả lại SAFE.

Tuy giao thức này chỉ định khi máy khách gửi expressionHashPrefixes đến máy chủ, nhưng giao thức này chủ ý không chỉ định chính xác cách gửi chúng. Ví dụ: máy khách có thể gửi tất cả expressionHashPrefixes trong một yêu cầu duy nhất và cũng có thể gửi từng tiền tố riêng lẻ trong expressionHashPrefixes đến máy chủ trong các yêu cầu riêng biệt (có thể tiến hành song song). Ứng dụng cũng có thể gửi các tiền tố băm được tạo ngẫu nhiên hoặc không liên quan cùng với tiền tố băm trong expressionHashPrefixes, miễn là số lượng tiền tố băm được gửi trong một yêu cầu không vượt quá 30.

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 sử dụng khi ứng dụng chọn chọn chế độ hoạt động danh sách cục bộ. Mã này cũng được dùng khi ứng dụng mà quy trình RealTimeCheck ở trên trả về giá trị UNSURE.

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

1. Đặt expressions là danh sách các biểu thức hậu tố/tiền tố do URL u tạo.
2. Cho expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của từng biểu thức trong expressions.
3. Giả sử 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/expressionHashPrefixes:
   1. Tìm expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục nhập đượ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 trong bộ nhớ đệm mà hệ thống tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục vòng lặp.
      3. Nếu giá trị 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 nhập đã 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òng lặp.
   3. Nếu không tìm thấy mục nhập đã lưu vào bộ nhớ đệm, hãy tiếp tục vòng lặp.
5. Đối với mỗi expressionHashPrefix/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 về danh sách mối đe doạ cục bộ, hãy xoá dữ liệu này 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 lỗi mạng, lỗi HTTP, v.v.), hãy trả về SAFE. Nếu không, phản hồi là response nhận được từ máy chủ SB. Đây là danh sách 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 bộ nhớ đệm expiration.
7. Đối với mỗi fullHash/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/response:
   1. Cho isFound là kết quả tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục vòng lặp.
   3. Nếu 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 sử dụng khi ứng dụng chọn chế độ không lưu trữ theo thời gian thực.

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

1. Đặt expressions là danh sách các biểu thức hậu tố/tiền tố do URL u tạo.
2. Cho expressionHashes là một danh sách, trong đó các phần tử là hàm băm SHA256 của từng biểu thức trong expressions.
3. Giả sử 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/expressionHashPrefixes:
   1. Tìm expressionHashPrefix trong bộ nhớ đệm cục bộ.
   2. Nếu tìm thấy mục nhập đượ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 trong bộ nhớ đệm mà hệ thống tìm thấy khỏi bộ nhớ đệm cục bộ.
         2. Tiếp tục vòng lặp.
      3. Nếu giá trị 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 nhập đã 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òng lặp.
   3. Nếu không tìm thấy mục nhập đã lưu vào bộ nhớ đệm, hãy tiếp tục 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 lỗi mạng, lỗi HTTP, v.v.), hãy trả về SAFE. Nếu không, phản hồi là response nhận được từ máy chủ SB. Đây là danh sách 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 bộ nhớ đệm expiration.
6. Đối với mỗi fullHash/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/response:
   1. Cho isFound là kết quả tìm fullHash trong expressionHashes.
   2. Nếu isFound là False, hãy tiếp tục vòng lặp.
   3. Nếu isFound là True, hãy trả về UNSAFE.
8. Trả lại SAFE.

Giống như Quy trình kiểm tra URL theo thời gian thực, quy trình này không chỉ định chính xác cách gửi tiền tố băm đến máy chủ. Ví dụ: máy khách có thể gửi tất cả expressionHashPrefixes trong một yêu cầu duy nhất và cũng có thể gửi từng tiền tố riêng lẻ trong expressionHashPrefixes đến máy chủ trong các yêu cầu riêng biệt (có thể tiến hành song song). Ứng dụng cũng có thể gửi các tiền tố băm được tạo ngẫu nhiên hoặc không liên quan cùng với tiền tố băm trong expressionHashPrefixes, miễn là số lượng tiền tố băm được gửi trong một yêu cầu không vượt quá 30.

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, nên 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 dài vài ký tự.

Không giống như phiên bản 4, trong đó danh sách được xác định theo bộ dữ liệu loại mối đe doạ, loại nền tảng, loại mục nhập mối đe doạ, trong danh sách v5 được xác định đơn giản 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 kiểu mối đe doạ. Các loại nền tảng và loại mối đe doạ sẽ bị xoá trong phiên bản 5.

Sau khi tên được chọn cho một danh sách, tên đó sẽ không bao giờ bị đổi tên. Hơn nữa, khi một 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ở thành 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 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 dần dần. Việc sử dụng 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ác bản 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 ứ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ì sẽ có bản cập nhật đầy đủ.) Bản cập nhật gia tăng chứa các chỉ mục xoá và thông tin bổ sung. Trước tiên, ứng dụng được yêu cầu xoá các mục nhập tại chỉ mục được chỉ định khỏi cơ sở dữ liệu cục bộ, sau đó áp dụng phần bổ sung.

Cuối cùng, để ngăn ngừa tình trạng hỏng, máy khách nên 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 khách phải cập nhật đầy đủ.

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

291bc5421f1cd54d99afcc55d166e2b9fe42447025895bf09dd41b2110a687dc  a.example.com/
1d32c5084a360e58f1b87109637a6810acad97a861a7769e8f1841410d2a960c  b.example.com/
f7a502e56e8b01c6dc242b35122683c9d25d07fb1f532d9853eb0ef3ff334f03  y.example.com/

001110100010010011110110100011 # Second number, remainder part
0111 # Second number, quotient part
001011111010010000000000111010 # First number, remainder part
0 # First number, quotient part

00111010001001001111011010001101110010111110100100000000001110100

0 01110100 01001001 11101101 00011011 10010111 11010010 00000000 01110100

01110100
00000000
11010010
10010111
00011011
11101101
01001001
01110100
00000000

additions_four_bytes {
  first_value: 489866504
  rice_parameter: 30
  entries_count: 2
  encoded_data: "t\000\322\227\033\355It\000"
}

Danh sách hiện có

Bạn nên sử dụng các danh sách sau trong phiên bản v5alpha1:

Danh sách bổ sung sẽ có sẵn vào ngày sau, khi đó bảng ở trên sẽ được mở rộng.

Được phép máy khách vận hành máy chủ proxy lưu vào bộ nhớ đệm để truy xuất một số hoặc tất cả danh sách ở trên, sau đó yêu cầu máy khách liên hệ với máy chủ proxy. Nếu triển khai như vậy, bạn nên sử dụng bộ nhớ đệm có thời lượng ngắn, chẳng hạn như 5 phút; trong tương lai, thời lượng bộ nhớ đệm này có thể được thông báo bằng cách sử dụng tiêu đề HTTP Cache-Control tiêu chuẩn.

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

Máy khách nên kiểm tra giá trị được máy chủ trả về trong trường minimum_wait_duration và sử dụng giá trị đó để 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 (trường minimum_wait_duration hoàn toàn bị thiếu). Trong trường hợp đó, máy khách NÊN thực hiện một thao tác cập nhật khác ngay lập tức.

Đang chuyển đổi danh sách cập nhật

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

Những thay đổi sau cần đượ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 của ứng dụng bằng một trường chuyên dụng, chỉ cần sử dụng tiêu đề User-Agent phổ biến. Mặc dù không có định dạng quy định để cung cấp nhận dạng ứng dụng khách trong tiêu đề này, chúng tôi khuyên bạn chỉ nên bao gồm ID ứ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 từng đố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 chỉ có thể gửi chuỗi byte tương tự sẽ được gửi đến máy chủ bằng trường state trong v4 trong phiên bản 5 qua trường versions.
   • Đối với các quy tắc ràng buộc v4, v5 sử dụng một phiên bản đơn giản có tên là SizeConstraints. Bạn sẽ bỏ các trường bổ sung như region.

Bạn cần thực hiện những thay đổi sau đây đối với phản hồi:

1. enum ResponseType v4 được thay thế bằng một 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 gửi ngay 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 đối với 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. Bạn sẽ cần điều chỉnh thuật toán giải mã gạo cho các số nguyên 32 bit. Sự khác biệt là dữ liệu được mã hoá được mã hoá bằng một nguồn cuối cùng khác. Trong cả v4 và v5, tiền tố băm 32 bit được sắp xếp theo từ điển. Nhưng trong v4, các tiền tố đó được coi là endian nhỏ khi được sắp xếp, trong khi ở 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ỳ cách sắp xếp nào vì kiểu sắp xếp từ điển giống hệt với sắp xếp số với một số đuôi lớn. Bạn có thể xem một ví dụ về phương pháp 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. Thuật toán giải mã gạo sẽ cần được triển khai cho các độ dài hàm băm khác.

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

Trong phiên bản 4, một người sẽ sử dụng phương thức fullHashes.find để nhận đầy đủ 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.

Những thay đổi sau cần được thực hiện đối với yêu cầu:

1. Tạo 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 của ứng dụng bằng một trường chuyên dụng, chỉ cần sử dụng tiêu đề User-Agent phổ biến. Mặc dù không có định dạng quy định để cung cấp nhận dạng ứng dụng khách trong tiêu đề này, chúng tôi khuyên bạn chỉ nên bao gồm ID ứ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 thêm threat_types và các trường tương tự nữa.

Bạn cần thực hiện những thay đổi sau đây đối với phản hồi:

1. Trường minimum_wait_duration đã bị xoá. Khách hàng có thể đưa ra yêu cầu mới bất cứ lúc nào 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. Tính năng lưu vào bộ nhớ đệm đã được đơn giản hoá thành một thời lượng bộ nhớ đệm duy nhất. Hãy xem quy trình tương tác với bộ nhớ đệm ở trên.