Lỗ hổng Cloudflare Bot Detect: Chrome, TLS và User-Agent lệch gây false positive
Thử nghiệm thực tế cho thấy Cloudflare Bot Detect có thể đánh giá bất thường khi Chrome Core, User-Agent và TLS fingerprint không đồng nhất, khiến người dùng thật liên tục bị challenge hoặc không thể truy cập website.
Chi tiết ưu đãi
Tháng 08/2026 Like4Share đã test Cloudflare Bot Detect và phát hiện một vấn đề đáng chú ý với Chrome Core, TLS và User-Agent
Trong quá trình thử nghiệm hệ thống chống bot của Cloudflare, Like4Share phát hiện một hiện tượng khá đáng chú ý:
Một người dùng hoàn toàn có thể đang sử dụng trình duyệt thật, thao tác bằng tay như bình thường, nhưng vẫn bị Cloudflare đánh giá có mức độ tin cậy thấp chỉ vì các thành phần fingerprint của trình duyệt không đồng nhất với nhau.
Các trường hợp Like4Share đã tái hiện được gồm:
- Chrome/Chromium Core quá cũ dễ gặp challenge hoặc block hơn trong một số điều kiện.
- Phiên bản Chrome Core khác phiên bản được khai báo trong User-Agent có thể làm kết quả xác minh thay đổi.
- TLS fingerprint không tương ứng với browser identity cũng ảnh hưởng tới quá trình nhận diện.
- Khi những thành phần fingerprint trở nên đồng nhất hơn, cùng môi trường thử nghiệm có thể vượt qua quá trình xác minh ổn định hơn.
Điều đáng chú ý là Cloudflare không công khai một rule đơn giản kiểu “Chrome phiên bản X sẽ bị chặn”.
Những gì Like4Share trình bày trong bài viết này là kết quả thử nghiệm độc lập, không phải tuyên bố chính thức rằng Cloudflare sử dụng chính xác một công thức hay một ngưỡng phiên bản Chrome cụ thể.
Tuy nhiên, tài liệu chính thức của Cloudflare xác nhận Bot Management sử dụng nhiều hệ thống phát hiện khác nhau, bao gồm heuristic checks, machine learning và fingerprinting để phân biệt automation với người dùng thật.
Và khi đặt tài liệu đó cạnh kết quả thử nghiệm thực tế, một vấn đề khá rõ bắt đầu xuất hiện:
Browser identity ngày nay không còn nằm ở User-Agent. Nó là sự tổng hợp của rất nhiều fingerprint khác nhau.
Vấn đề không phải chỉ là Chrome cũ
Ban đầu Like4Share thử tập trung vào phiên bản Chrome.
Một số môi trường sử dụng Chromium Core cũ gặp Cloudflare Challenge thường xuyên hơn, khó xác minh hơn hoặc đôi khi không thể hoàn tất quá trình verification.
Nếu chỉ dừng ở đây, rất dễ kết luận:
“Cloudflare chặn Chrome cũ.”
Nhưng sau nhiều trường hợp thử nghiệm, Like4Share cho rằng cách kết luận đó quá đơn giản.
Vấn đề thú vị hơn nằm ở độ đồng nhất của browser fingerprint.
Ví dụ:
Browser thực tế đang chạy Chromium Core phiên bản A.
Trong khi User-Agent lại khai báo Chrome phiên bản B.
TLS ClientHello tạo ra một fingerprint thuộc một nhóm khác.
HTTP request tiếp tục thể hiện một số đặc điểm không hoàn toàn giống phiên bản Chrome đang được khai báo.
Khi những tín hiệu này xuất hiện cùng nhau, browser có thể trở thành một client “bất thường” trong mắt hệ thống chống bot.
Cloudflare không chỉ nhìn User-Agent
Đây là điểm quan trọng nhất trong thử nghiệm của Like4Share.
Nhiều người vẫn nghĩ có thể xác định browser thông qua chuỗi:
Mozilla/5.0 (...) AppleWebKit/... Chrome/... Safari/...
Nhưng User-Agent về bản chất chỉ là một HTTP header do client gửi lên.
Nó có thể bị thay đổi.
Một ứng dụng không phải Chrome vẫn có thể tự khai mình là Chrome.
Một Chromium cũ cũng có thể khai mình là phiên bản Chrome mới.
Cloudflare thậm chí có công cụ Browser Integrity Check kiểm tra một số HTTP header bất thường và có thể challenge visitor không có User-Agent hoặc sử dụng User-Agent không tiêu chuẩn.
Nhưng Bot Management hiện đại đi xa hơn việc đọc một chuỗi User-Agent.
Cloudflare công khai cho biết engine heuristic của họ thực hiện nhiều phép kiểm tra và đối chiếu request với cơ sở dữ liệu về fingerprint độc hại.
Vì vậy câu hỏi thực tế không còn là:
“User-Agent của bạn nói bạn là trình duyệt gì?”
Mà là:
“Tất cả những tín hiệu khác có đồng ý rằng bạn thực sự là trình duyệt đó hay không?”
Thử nghiệm 1: Chrome Core cũ có thể khiến quá trình xác minh khó khăn hơn
Trong thử nghiệm của Like4Share, việc giữ một Chrome/Chromium Core quá cũ trong khi truy cập một số website được Cloudflare bảo vệ có thể làm tăng khả năng gặp:
- Managed Challenge.
- Verify you are human.
- Quá trình verification kéo dài.
- Challenge lặp lại.
- Một số request tiếp theo tiếp tục bị đánh giá bất thường.
Like4Share nhấn mạnh rằng điều này không chứng minh Cloudflare có một blacklist đơn giản cho từng phiên bản Chrome.
Cloudflare hiện công bố danh sách browser được hỗ trợ cho các cơ chế Challenge, Turnstile và JavaScript Detections.
Tài liệu troubleshooting của Cloudflare cũng thừa nhận browser không được hỗ trợ, browser configuration, extension, JavaScript bị vô hiệu hóa và việc hệ thống phát hiện tín hiệu giống bot có thể dẫn đến lỗi hoặc challenge lặp lại.
Điều Like4Share quan sát được cho thấy version browser có vẻ trở thành một phần của bức tranh fingerprint lớn hơn, chứ không đơn thuần là một điều kiện:
Chrome cũ = Block
Thử nghiệm 2: Chrome Core lệch User-Agent ảnh hưởng rõ hơn
Đây là phần Like4Share thấy thú vị hơn.
Giả sử browser thực tế sử dụng:
Chromium Core A
nhưng User-Agent lại khai:
Chrome B
Nếu chỉ nhìn chuỗi UA, website có thể nghĩ đây là Chrome B.
Nhưng việc thay đổi UA không tự động thay đổi toàn bộ engine của browser.
Browser Core thực tế vẫn có các đặc điểm riêng của nó.
Có thể hình dung đơn giản như sau:
| Tín hiệu | Browser khai báo |
|---|---|
| User-Agent | Chrome B |
| Browser Core | Chromium A |
| TLS behavior | Một fingerprint khác |
| HTTP behavior | Theo implementation thực tế |
| JavaScript environment | Theo Chromium Core thực tế |
Nếu A và B cách nhau đủ xa hoặc các thành phần bị can thiệp độc lập, browser bắt đầu tạo ra một danh tính không hoàn toàn thống nhất.
Trong quá trình thử nghiệm,Like4Share nhận thấy trường hợp này có thể làm thay đổi đáng kể kết quả Cloudflare Challenge.
Điều đó khiến Like4Share đi đến giả thuyết:
Cloudflare không chỉ quan tâm browser tự nhận mình là gì, mà còn đánh giá mức độ hợp lý của các đặc điểm đi kèm browser identity đó.
Đây là kết luận thực nghiệm của Like4Share, không phải công thức mà Cloudflare công bố.
Thử nghiệm 3: TLS fingerprint là mảnh ghép không thể bỏ qua
Sau Chrome Core và User-Agent, Like4Share tiếp tục quan sát TLS.
Đây là nơi mọi thứ trở nên thú vị hơn.
Trước khi browser gửi nội dung HTTP thông thường qua HTTPS, client và server phải thực hiện TLS handshake.
Cách một TLS client khởi tạo kết nối để lại những đặc điểm có thể fingerprint.
Cloudflare chính thức hỗ trợ JA3 và JA4 fingerprint trong Bot Management.
Theo tài liệu Cloudflare, JA3/JA4 được dùng để xác định TLS client dựa trên cách chúng khởi tạo kết nối; browser, bot và application có thể tạo ra những đặc điểm kết nối khác nhau.
Cloudflare còn có Signals Intelligence cho JA4, tổng hợp dữ liệu về một fingerprint dựa trên traffic quan sát trên mạng Cloudflare nhằm giúp giải thích tại sao request nhận một Bot Score nhất định.
Điều này đặc biệt quan trọng.
Giả sử HTTP nói:
Like4Share là Chrome B.
Nhưng TLS behavior lại không giống nhóm client mà hệ thống kỳ vọng.
Về mặt fingerprinting, đây là một mismatch đáng chú ý.
Trong test của Like4Share, thay đổi ở lớp TLS trong khi giữ một số yếu tố khác cố định có thể làm kết quả xác minh thay đổi.
Điều đó không chứng minh JA4 là biến duy nhất quyết định challenge.
Nhưng nó cho thấy TLS không thể bị xem như một tầng hoàn toàn độc lập với browser identity.
User-Agent mới nhưng TLS/Core cũ: đây mới là trường hợp đáng chú ý
Hãy tưởng tượng một môi trường như sau:
User-Agent: Chrome mới.
Browser Core: Chromium cũ hơn.
TLS: mang đặc tính từ một implementation khác hoặc phiên bản khác.
Về mặt giao diện, người sử dụng vẫn nhìn thấy một browser hoàn toàn bình thường.
Họ click chuột bằng tay.
Họ cuộn trang bằng tay.
Không chạy scraper.
Không chạy spam.
Không thực hiện request với tốc độ cao.
Nhưng đối với hệ thống chống bot, browser này có thể tạo ra một tập hợp tín hiệu không nhất quán.
Và đây chính là vấn đề Like4Share muốn chia sẻ:
Người dùng thật không đồng nghĩa với fingerprint “đẹp”
Một người hoàn toàn có thể là human 100% nhưng browser environment lại trông giống automation.
Đây là nguồn gốc tiềm năng của false positive.
Cloudflare Bot Score càng làm vấn đề này đáng quan tâm
Cloudflare Bot Management có Bot Score từ 1 đến 99.
Theo tài liệu Cloudflare, score thấp thể hiện khả năng request mang tính tự động cao hơn, còn score cao thể hiện khả năng request đến từ con người cao hơn. Bot Score có thể được sử dụng trong WAF rule để allow, challenge hoặc block traffic.
Do đó administrator hoàn toàn có thể tạo logic kiểu:
Bot Score thấp → Managed Challenge
hoặc trong môi trường nghiêm ngặt hơn:
Bot Score thấp → Block
Cloudflare cũng cung cấp các field liên quan tới:
- Bot Score.
- JA3.
- JA4.
- Detection IDs.
- JavaScript Detection.
Điều này đồng nghĩa một kết quả nhận diện không chính xác ở tầng browser có thể ảnh hưởng trực tiếp tới khả năng người dùng truy cập website nếu chủ website thiết lập rule quá mạnh.
“Trust Score” mà người dùng thường nhắc đến thực chất là gì?
Trong cộng đồng, chúng ta thường nghe cách nói:
“Browser này trust thấp.”
hoặc:
“Cloudflare trust score thấp.”
Tuy nhiên cần dùng thuật ngữ chính xác.
Cloudflare công khai Bot Score, nhưng không công bố một chỉ số duy nhất có tên chung là “Cloudflare Trust Score” cho toàn bộ visitor.
Do đó trong bài này, “trust” nên được hiểu theo nghĩa khái quát:
mức độ hệ thống tin rằng request/browser/session là hợp lệ và có khả năng đến từ người dùng thật.
Không nên hiểu đó là tên chính thức của một biến Cloudflare.
Thử nghiệm 4: Khi fingerprint đồng nhất, kết quả thay đổi
Đây là phát hiện khiến Like4Share chú ý nhất.
Sau khi thử các trường hợp:
- Chrome Core cũ.
- User-Agent lệch Core.
- TLS không tương ứng.
- Các thành phần browser identity không đồng nhất.
Like4Share tiếp tục thử theo hướng ngược lại:
làm cho các thành phần browser identity nhất quán hơn với nhau.
Kết quả cho thấy cùng một kiểu môi trường thử nghiệm có thể xác minh ổn định hơn khi fingerprint không còn xuất hiện nhiều tín hiệu mâu thuẫn.
Đây cũng là lý do Like4Share cho rằng vấn đề không đơn giản nằm ở:
“Phiên bản Chrome nào bị Cloudflare block?”
Mà câu hỏi đúng hơn phải là:
“Browser này có tạo ra một fingerprint tổng thể hợp lý với danh tính mà nó đang khai báo hay không?”
Vì lý do an toàn, Like4Share không công bố cấu hình hoặc quy trình cụ thể dùng để né cơ chế anti-bot. Điều đáng quan tâm của thử nghiệm này là cơ chế false positive và tác động đối với người dùng hợp lệ.
Đây có thực sự là một “lỗ hổng Cloudflare”?
Like4Share cho rằng cần chia vấn đề này thành hai hướng.
Góc nhìn thứ nhất: đây có thể là hành vi thiết kế
Một hệ thống chống bot buộc phải đánh giá xác suất.
Không có phương pháp fingerprinting nào biết tuyệt đối người bên kia màn hình có phải con người hay không.
Hệ thống chỉ có thể phân tích tín hiệu rồi dự đoán.
Cloudflare cũng công khai rằng Bot Management kết hợp nhiều detection engine và heuristic để nhận diện automated traffic.
Do đó việc browser có nhiều fingerprint mâu thuẫn bị đánh giá đáng ngờ là hoàn toàn hợp lý về mặt bảo mật.
Góc nhìn thứ hai: false positive lại trở thành vấn đề
Vấn đề xuất hiện khi:
người dùng thật bị chặn chỉ vì môi trường browser của họ khác với profile thông thường.
Cloudflare cũng thừa nhận WAF nói chung có khả năng xuất hiện false positives, tức request hợp lệ bị nhận diện và xử lý như request độc hại.
Nếu một browser hợp lệ nhưng cũ, WebView đặc biệt, browser privacy-focused, môi trường doanh nghiệp hoặc browser có cấu hình khác bình thường liên tục bị challenge, đây là vấn đề trải nghiệm thực sự.
Người dùng bình thường có thể bị ảnh hưởng như thế nào?
Đây mới là phần Like4Share cho rằng quan trọng nhất.
Phần lớn người dùng không biết:
- TLS fingerprint là gì.
- JA4 là gì.
- User-Agent có khớp Browser Core hay không.
- Browser engine đang sử dụng phiên bản nào.
Họ chỉ biết:
“Tại sao Like4Share vào website này mãi không được?”
Các biểu hiện có thể là:
Verify you are human xuất hiện liên tục.
Người dùng hoàn thành verification nhưng vài giây sau lại gặp challenge.
Website quay vòng ở Checking your browser.
Người dùng tưởng website bị lỗi.
Một máy vào được, một máy khác không vào được.
Mặc dù sử dụng chung mạng Internet.
Đổi IP vẫn không giải quyết được.
Bởi vấn đề có thể không chỉ nằm ở IP reputation.
Website hoạt động trên Chrome mới nhưng lỗi trên một môi trường Chromium khác.
Người dùng không hiểu nguyên nhân vì cả hai đều nhìn giống “Chrome”.
Cloudflare chính thức ghi nhận repeated challenge có thể xảy ra khi hệ thống phát hiện các tín hiệu bot mạnh, ngoài các nguyên nhân như browser configuration, extension, JavaScript hoặc network.
JavaScript Detection tạo thêm một lớp browser fingerprint
TLS chưa phải điểm kết thúc.
Cloudflare còn có JavaScript Detections.
Khi được bật, Cloudflare có thể inject JavaScript vào HTML response để thu thập client-side signals và tạo kết quả pass/fail mà WAF rule có thể sử dụng.
Điều đó có nghĩa browser có thể được quan sát ở ít nhất hai thế giới:
Network side
TLS, HTTP và các đặc điểm request.
Client side
JavaScript/browser behavior.
Nếu hai thế giới cùng nói một câu chuyện nhất quán, browser trông tự nhiên hơn.
Nếu một bên nói Chrome A nhưng bên kia lại biểu hiện như một môi trường khác, đó trở thành tín hiệu có giá trị đối với bot detection.
Một lần nữa, đây là cách giải thích dựa trên tài liệu công khai kết hợp với kết quả test của Like4Share; Cloudflare không công bố trọng số chính xác của từng tín hiệu.
Đây cũng là vấn đề đối với các trình duyệt Anti-detect
Anti-detect browser thường cho phép người dùng thay đổi:
- User-Agent.
- Operating System.
- Screen.
- WebGL.
- Canvas.
- timezone.
- locale.
- hardware characteristics.
- nhiều browser properties khác.
Nhưng có một vấn đề:
thay đổi nhiều thông số không đồng nghĩa chúng tự động trở thành một browser identity hợp lý.
Ví dụ giả định:
UA nói Chrome thế hệ mới.
Nhưng Chromium Core vẫn cũ.
TLS lại mang fingerprint khác.
Một số JavaScript APIs tiếp tục phản ánh khả năng của browser engine thực tế.
Kết quả cuối cùng có thể là một browser được “fake” rất nhiều nhưng lại kém tự nhiên hơn browser nguyên bản.
Đây cũng là điều kết quả thử nghiệm của Like4Share cho thấy khá rõ:
Fingerprint consistency có thể quan trọng hơn việc đơn thuần thay đổi thật nhiều fingerprint.
Privacy browser cũng có nguy cơ trở thành false positive
Đây là mặt trái đáng bàn.
Không phải mọi browser khác chuẩn đều là bot.
Một số người chủ động:
- chống fingerprinting;
- chặn JavaScript;
- chặn tracker;
- thay User-Agent;
- sử dụng VPN;
- sử dụng browser privacy-focused;
- tắt một số API trình duyệt.
Mục tiêu của họ có thể chỉ là bảo vệ quyền riêng tư.
Nhưng từ góc nhìn của bot detection, việc làm browser trở nên khác biệt với population bình thường đôi khi cũng đồng thời làm hệ thống khó xác định browser đó hơn.
Đây là cuộc xung đột ngày càng rõ giữa:
Privacy
và
Anti-bot fingerprinting.
Browser cố gắng tiết lộ càng ít thông tin.
Anti-bot lại muốn có đủ tín hiệu để biết browser có thật hay không.
Chủ website Cloudflare cũng cần quan tâm đến vấn đề này
Đây không chỉ là chuyện của người dùng.
Nếu bạn sở hữu website và sử dụng Cloudflare, một WAF rule quá mạnh có thể vô tình chặn khách hàng thật.
Ví dụ:
Website thương mại điện tử có thể mất khách ngay tại checkout.
Website đăng ký dịch vụ có thể làm người dùng không thể tạo tài khoản.
Website tin tức có thể khiến visitor rời đi vì challenge liên tục.
Website SaaS có thể khiến khách hàng nghĩ hệ thống đang gặp sự cố.
Cloudflare cung cấp Security Events để quản trị viên kiểm tra request nào đã kích hoạt security feature và nguyên nhân xử lý request.
Đây là dữ liệu mà administrator nên kiểm tra trước khi đơn giản kết luận:
“Người dùng bị block chắc chắn là bot.”
Đừng áp dụng một Bot Score quá thấp thành block toàn site
Bot detection là hệ thống xác suất.
Một cách triển khai hợp lý hơn là đánh giá theo độ nhạy cảm của endpoint.
Ví dụ:
Trang blog công khai có thể khoan dung hơn.
Login cần kiểm tra mạnh hơn.
Register có thể dùng Managed Challenge.
Checkout cần thêm nhiều lớp kiểm tra.
API nhạy cảm cần rule riêng.
Endpoint dễ bị credential stuffing cần chính sách riêng.
Cloudflare cho phép sử dụng Bot Score trong custom rules để áp dụng challenge hoặc action khác tùy theo điều kiện request.
Điều đó tốt hơn rất nhiều so với việc coi tất cả visitor có tín hiệu hơi bất thường là attacker.
Điều đáng sợ nhất của fingerprinting: người dùng không biết tại sao mình bị chặn
Nếu IP bị block, người dùng còn có thể hiểu:
“IP này có vấn đề.”
Nếu password sai:
“Đăng nhập sai.”
Nhưng fingerprinting phức tạp hơn.
Website chỉ hiện:
Verify you are human.
Người dùng xác minh.
Cloudflare vẫn nghi ngờ.
Người dùng xác minh tiếp.
Cuối cùng họ bỏ website.
Không có thông báo:
“TLS fingerprint của bạn không phù hợp với browser identity.”
Cũng không có:
“Phiên bản Chromium Core và User-Agent của bạn có dấu hiệu không đồng nhất.”
Đối với người dùng cuối, hệ thống đơn giản chỉ có vẻ như bị lỗi.
Phát hiện của Like4Share cho thấy Cloudflare Bot Detect đang nhìn browser như một hệ thống hoàn chỉnh
Sau các thử nghiệm, mô hình Like4Share quan sát được có thể tóm tắt như sau:
IP không phải tất cả.
IP tốt không có nghĩa browser chắc chắn được tin tưởng.
User-Agent không phải tất cả.
Khai Chrome mới không biến client thành Chrome mới.
TLS không phải tất cả.
TLS fingerprint chỉ là một phần trong tổng thể.
Chrome Core không phải tất cả.
Một Chrome chính hãng vẫn có thể gặp challenge do các yếu tố khác.
Điều đáng chú ý là sự tương quan giữa các tín hiệu.
Browser càng có nhiều thành phần “kể cùng một câu chuyện”, kết quả càng ổn định trong thử nghiệm của Like4Share.
Browser càng tạo ra nhiều tín hiệu mâu thuẫn, khả năng gặp anti-bot verification càng cao.
Đây là lỗ hổng hay là giới hạn tự nhiên của anti-bot?
Câu trả lời có lẽ nằm ở giữa.
Nếu nhìn dưới góc độ Cloudflare:
việc sử dụng nhiều fingerprint để chống browser giả mạo là một tính năng bảo mật.
Nếu nhìn dưới góc độ người dùng:
việc một người thật bị nhận diện là bot chỉ vì browser không nằm trong profile phổ biến là false positive.
Nếu nhìn dưới góc độ security research:
khả năng thay đổi kết quả nhận diện khi mức độ consistency giữa các fingerprint thay đổi là một đặc tính rất đáng nghiên cứu.
Nó đồng thời cho thấy một hạn chế cơ bản của browser fingerprinting:
Hệ thống không thực sự biết ai đang ngồi trước màn hình. Nó chỉ đánh giá những dấu vết mà client tạo ra.
Một bot có fingerprint rất tự nhiên có thể trông đáng tin.
Ngược lại, một con người sử dụng browser có fingerprint bất thường có thể trông giống bot.
Kết luận: Cloudflare Bot Detect mạnh, nhưng browser fingerprint vẫn có vùng xám
Sau quá trình thử nghiệm, Like4Share có thể tái hiện cả bốn hiện tượng:
1. Chrome Core cũ có thể gặp khó khăn hơn với Cloudflare verification trong một số môi trường.
2. Chrome Core và User-Agent lệch nhau có thể làm thay đổi kết quả nhận diện.
3. TLS fingerprint không phù hợp với browser identity có ảnh hưởng Like4Share quá trình đánh giá.
4. Khi browser fingerprint trở nên đồng nhất hơn, kết quả xác minh có thể thay đổi đáng kể.
Like4Share không khẳng định đây là toàn bộ thuật toán Cloudflare.
Cloudflare không công khai trọng số, rule hay mô hình chính xác dùng để tính Bot Score.
Nhưng Cloudflare có công khai việc sử dụng Bot Score, heuristic detection, JavaScript Detection, JA3/JA4 fingerprint và nhiều tín hiệu khác trong hệ thống Bot Management.
Kết quả test của Like4Share cho thấy điều quan trọng không còn đơn giản là:
“Bạn đang sử dụng Chrome phiên bản nào?”
Mà có thể gần hơn với:
“Toàn bộ browser fingerprint của bạn có hợp lý với Chrome phiên bản mà bạn đang khai báo hay không?”
Và đây chính là vùng xám đáng chú ý nhất của các hệ thống chống bot hiện đại.
Chúng ta đang bước vào thời kỳ mà người dùng thật chưa chắc đã được nhận diện là người thật, trong khi việc phân biệt human và automation ngày càng phụ thuộc vào những fingerprint mà phần lớn người dùng thậm chí không biết rằng trình duyệt của mình đang tạo ra.
