Khi website quét mạng nội bộ của bạn (và cách nó bị chặn)

Một tab bình thường, mở một website công khai bình thường, có thể yêu cầu trình duyệt của bạn gửi request tới 127.0.0.1 và tới địa chỉ LAN của router — chẳng hạn 192.168.1.1 — rồi đo xem mỗi request mất bao lâu để có phản hồi. Nó không cần đọc nội dung phản hồi; các quy tắc cross-origin đã chặn điều đó từ trước. Nó chỉ cần biết có thứ gì đó trả lời nhanh, trả lời chậm, hay không trả lời gì cả. Chỉ vậy là đủ để dựng lên một bản đồ những gì đang chạy trên mạng phía sau địa chỉ IP công khai duy nhất của bạn, và cho tới gần đây, không có gì trong trình duyệt ngăn một trang web làm điều đó.

Tóm tắt nhanh

• Một trang web công khai có thể gửi request tới localhost và tới các địa chỉ LAN riêng tư như 192.168.x.x bằng JavaScript thông thường — fetch(), thẻ <img>, hay một kết nối WebSocket đều hoạt động được, và mặc định không cái nào cần quyền đặc biệt.
• Trang web không cần đọc phản hồi. Thời gian phản hồi (có trả lời không, và nhanh cỡ nào) cùng kết quả kết nối (mở, bị từ chối, hay hết thời gian chờ) đã đủ để biết có thứ gì đang lắng nghe trên một địa chỉ và cổng cục bộ cụ thể hay không.
• Thứ bị lộ ra là thông tin về máy tính và mạng của bạn, không phải trình duyệt: một dev server ở cổng 3000, một media server, một agent desktop của nhà cung cấp nào đó, hay một model router cụ thể — những sự thật ổn định, khó thay đổi, và nhận diện được theo một cách khác hẳn so với vân tay canvas hay font.
• Cùng một dạng request này cũng là một vector CSRF nhắm vào router và các bảng quản trị cục bộ vốn chưa từng được thiết kế để nhận request từ một trang công khai ngẫu nhiên.
• Bản sửa lỗi của Chrome, Local Network Access (Truy cập mạng cục bộ), là một lời nhắc xin quyền hướng tới người dùng, ra mắt trong Chrome 142 — nó thay thế một nỗ lực trước đó, âm thầm hơn, gọi là Private Network Access, vốn xin sự đồng ý từ thiết bị cục bộ thay vì từ người dùng.

Một trang web thực sự có thể làm gì

Chuyện này không cần bất kỳ API trình duyệt kỳ lạ nào. Một trang muốn dò mạng của bạn chỉ cần bắn ra một loạt request thông thường — một lệnh gọi fetch() tới http://127.0.0.1:3000/, một phần tử ảnh trỏ tới http://192.168.1.1/, hoặc mở một kết nối WebSocket tới ws://127.0.0.1:8080 — rồi quan sát chuyện gì xảy ra tiếp theo. Chính sách same-origin ngăn trang web đọc nội dung phản hồi, nhưng nó không thể giấu việc một promise fetch() được resolve hay reject, mất bao lâu để một phần tử ảnh kích hoạt sự kiện load hay error, hay một WebSocket có đạt tới onopen hay onerror. Đo thời gian một loạt request như vậy trên một dải cổng phổ biến tại 127.0.0.1 và các dải địa chỉ riêng tư (192.168.0.0/16, 10.0.0.0/8), và bản thân mô hình thành công, bị từ chối, và hết thời gian chờ đã là kết quả quét — không cần một byte nội dung phản hồi nào rời khỏi mạng cục bộ.

Điều nó làm lộ: một sự thật về máy tính của bạn, không phải trình duyệt

Phần lớn những gì BrowserInsight đề cập dưới chủ đề fingerprinting — kết xuất canvas, font đã cài, chuỗi renderer WebGL — mô tả trình duyệt và stack render của nó. Một cuộc quét mạng cục bộ mô tả một thứ khác: phần mềm nào thực sự đang chạy trên chiếc máy vật lý và trên phân đoạn mạng mà nó thuộc về. Một phản hồi ở cổng 3000 hay 8080 thường có nghĩa là một dev server cục bộ của lập trình viên. Một thiết bị trả lời tại địa chỉ router của bạn theo cách khớp với dấu hiệu của một bảng quản trị đã biết sẽ nhận diện được model router đó, đôi khi tới cả dòng firmware. Một phản hồi ở đúng cổng mà agent đồng bộ desktop hay media server của một nhà cung cấp cụ thể lắng nghe sẽ xác nhận sự hiện diện của phần mềm đó trên LAN của bạn, bất kể nó có đang chạy trong tab bạn đang xem hay không. Không điều nào trong số đó đến từ một header hay một JavaScript API nói thẳng cho trang web biết "người dùng đã cài X" — tất cả đều được suy ra thuần túy từ việc cánh cửa cục bộ nào đã trả lời khi bị gõ cửa. Điều đó khiến đây là một tín hiệu thực sự khác biệt so với entropy fingerprinting mà hướng dẫn về fingerprinting của site này thường bàn tới, và có hình dạng tập ẩn danh khác: nó không phân biệt bạn với những người khác cùng truy cập một trang, mà thay vào đó lập bản đồ chính mạng nhà hay mạng văn phòng cụ thể của bạn.

Nửa còn lại của vấn đề: CSRF nhắm vào router

Fingerprinting không phải lý do duy nhất khiến lỗ hổng này được vá. Cùng một dạng request — một trang công khai chạm tới một địa chỉ riêng tư mà nó chưa từng được mời — cũng chính là cách các cuộc tấn công cross-site request forgery nhắm vào router và bảng quản trị cục bộ hoạt động. Giao diện web của router, hay một bảng quản trị cục bộ cho NAS hoặc thiết bị IoT, thường được xây dựng với giả định ngầm rằng chỉ ai đó đã ở trong LAN mới có thể chạm tới nó. Nó không có lý do gì để lường trước một request bị giả mạo bởi JavaScript từ một trang công khai hoàn toàn không liên quan. Khi giải thích quyền mới này dùng để làm gì, Chrome gọi tên cả hai nửa của bài viết này chỉ trong một câu: nó nhằm "bảo vệ người dùng khỏi các cuộc tấn công cross-site request forgery (CSRF) nhắm vào router và những thiết bị khác trên mạng riêng tư, và giảm khả năng các trang web dùng chính những request đó để lấy dấu vân tay mạng cục bộ của người dùng". Cùng một request, hai việc khác nhau mà kẻ tấn công có thể làm với nó.

Lịch sử khắc phục: preflight trước, rồi mới đến lời nhắc xin quyền

Nỗ lực đầu tiên của Chrome nhằm bịt lỗ hổng này là Private Network Access, và đáng để hiểu vì sao nó không hoàn toàn hiệu quả trước khi xem xét thứ thay thế nó. Ý tưởng chủ đạo của PNA là chặn các request từ trang công khai tới các mục tiêu trên mạng riêng tư sau một CORS preflight: trước khi request thật được gửi đi, trình duyệt gửi một request OPTIONS yêu cầu thiết bị mục tiêu chủ động đồng ý, bằng cách trả lời với header Access-Control-Allow-Private-Network: true. Về nguyên tắc, điều này đặt quyền quyết định vào tay bất kỳ ai kiểm soát thiết bị cục bộ — một thiết kế hợp lý. Trong thực tế, nó chưa bao giờ ra khỏi giai đoạn thử nghiệm. Bài giải thích của Chrome về preflight ghi nhận một lần rollback sau khi các vấn đề lộ ra ở Chrome 98, rồi sự trở lại ở Chrome 104 dưới một hình thức cố ý "không có răng": preflight thất bại chỉ in ra một cảnh báo trong DevTools còn request thật vẫn cứ đi, và bản thân timeout của preflight bị giới hạn ở 200 mili-giây để nó không làm chậm việc tải trang. Việc thực thi thật sự được đặt lịch "sớm nhất là Chrome 113", và gắn rõ điều kiện là dữ liệu tương thích phải cho thấy thay đổi đủ an toàn. Nó đã không bao giờ được triển khai — chính thông báo Local Network Access của Chrome ghi nhận rằng hướng tiếp cận preflight đã bị tạm gác lại.

Nửa còn lại của PNA cũng chẳng khá hơn. Bài cập nhật của Chrome về PNA theo dõi hướng thứ hai của nỗ lực này — chặn request tới mạng riêng tư từ những trang công khai không an toàn — bị dời từ Chrome 92 sang 93, rồi sang 94 sau khi có thêm phản hồi của nhà phát triển; còn giai đoạn deprecation trial cho phép các trang bị ảnh hưởng tiếp tục hoạt động thì được gia hạn hết lần này tới lần khác (tới 113, rồi 116) trước khi hết hạn hẳn ở Chrome 117.

Đó chính là bài học cốt lõi mà PNA để lại: xin sự đồng ý từ thiết bị mục tiêu không hiệu quả khi phần lớn thiết bị trên mạng của người dùng thật — router, máy in, hub smart-home, ổ lưu trữ mạng — sẽ chẳng bao giờ nhận được bản firmware dạy chúng cách đưa ra sự đồng ý đó. Dời hạn chót bao nhiêu lần cũng không thay đổi điều đó, vì phần cứng không nằm ở đầu bên kia của cái hạn chót ấy.

Vì sao một lời nhắc xin quyền tốt hơn preflight ở đây

Local Network Access — viết tắt LNA — là câu trả lời của Chrome, và nó chuyển quyền quyết định từ thiết bị không thể liên lạc được sang chính người đang ngồi trước bàn phím. Thay vì hỏi router hay dev server có đồng ý hay không qua một header mà chúng sẽ chẳng bao giờ gửi, giờ đây trình duyệt hiện một lời nhắc cho người dùng — nội dung của Chrome viết là "Tìm và kết nối tới bất kỳ thiết bị nào trên mạng cục bộ của bạn" — ngay lần đầu tiên một trang công khai cố chạm tới một địa chỉ riêng tư. Người dùng có thể cho phép, một lần, nếu họ tin tưởng trang web đó (một dashboard smart-home thực sự cần điều này) hoặc đơn giản là từ chối đối với đại đa số trang web không có lý do chính đáng nào để dò mạng gia đình cả. Điều đó đảo ngược điểm nghẽn: thay vì chờ hàng triệu thiết bị không còn được bảo trì triển khai một header mới, Chrome chỉ cần trình duyệt thực thi việc kiểm tra, và người sở hữu mạng sẽ là người quyết định mỗi lần.

Tính năng này ra mắt trong Chrome 142; trước đó, từ Chrome 138 bạn đã có thể tự bật nó qua cờ chrome://flags#local-network-access-check. Định nghĩa phạm vi của Chrome hẹp hơn "bất kỳ request nào tới một địa chỉ cục bộ": một request mạng cục bộ là request đi từ mạng công khai tới một đích thuộc mạng cục bộ hoặc loopback. Phạm vi đó gồm các dải riêng tư theo RFC 1918 (như 192.168.0.0/16), địa chỉ link-local (169.254.0.0/16 và fe80::/10), địa chỉ unique local IPv6 (fc00::/7), loopback (127.0.0.0/8 và ::1), cùng hostname .local — chính xác dải địa chỉ mà một script quét sẽ quét qua. Thứ nó chưa bao phủ là một trang vốn đã được phục vụ từ địa chỉ riêng tư rồi với sâu thêm vào loopback; Chrome cho biết sẽ mở rộng lớp bảo vệ này sang mọi request cross-origin hướng tới mạng cục bộ trong tương lai.

Điều người đọc thấy hôm nay

Nếu bạn đang dùng một phiên bản Chrome gần đây và một trang web cố chạm tới một địa chỉ trên LAN của bạn, bạn sẽ thấy lời nhắc xin quyền thay vì một request âm thầm. Phần lớn các trang bạn ghé thăm sẽ không bao giờ kích hoạt nó, vì chúng chẳng có lý do gì để nói chuyện với router hay dev server cục bộ của bạn — nếu có một trang làm vậy mà bạn không hiểu vì sao, từ chối là lựa chọn an toàn mặc định. Đây là một đợt triển khai do Chrome dẫn dắt, chưa phải phổ quát: đừng cho rằng cùng một lời nhắc hay cùng một mức bảo vệ tồn tại ở mọi trình duyệt chỉ vì bạn đã thấy nó ở một trình duyệt. Nếu bạn muốn biết trình duyệt và cấu hình mạng hiện tại của mình để lộ những gì ngoài cơ chế cụ thể này, kiểm tra dấu vân tay của BrowserInsight bao phủ tập tín hiệu rộng hơn ở cấp máy và trình duyệt mà một trang web có thể đọc mà không cần bất kỳ lời nhắc xin quyền nào.

Vị trí của chủ đề này bên cạnh các chủ đề riêng tư khác trên site

Rất dễ gộp chủ đề này chung với các kỹ thuật theo dõi không liên quan nhưng tình cờ nằm ở những trang gần đây trên site, nên hãy nói rõ ranh giới: Vân tay CSS là một stylesheet suy ra đặc điểm thiết bị như dark mode hay loại con trỏ — không hề có request mạng nào. Session replay là một script ghi lại những gì bạn làm bên trong một trang bạn đang mở sẵn. Quyền riêng tư của tiện ích mở rộng nói về các add-on đã cài đọc dữ liệu trang, không phải chính trình duyệt biến thành một công cụ quét mạng. Visitor ID bền vững nói về việc tái nhận diện bạn qua nhiều lượt truy cập, không phải lập bản đồ LAN của bạn. Bài viết này nói cụ thể về việc trình duyệt bị biến thành một đầu dò nhắm vào chính mạng riêng tư mà chiếc máy đang nằm trong đó — một cơ chế khác biệt với cả bốn chủ đề trên, dù chúng cùng chia sẻ chủ đề chung: một trang web biết về bạn nhiều hơn những gì bạn tự nguyện cung cấp.

Câu hỏi thường gặp

Điều này có ảnh hưởng tới mọi trình duyệt, hay chỉ Chrome?

Local Network Access là một tính năng của Chromium, ra mắt trong Chrome 142. Mức độ hỗ trợ ở các engine khác thay đổi theo thời gian, nên hãy kiểm tra release note của trình duyệt cụ thể bạn đang dùng thay vì giả định lớp bảo vệ này là phổ quát — các kỹ thuật request nền tảng (fetch, <img>, WebSocket) hoạt động giống hệt nhau trên mọi trình duyệt cho tới khi trình duyệt đó chủ động hạn chế chúng.

Một trang web có thể quét mạng của tôi mà tôi không hề hay biết không?

Trước khi có Local Network Access thì có — một script dò hàng chục địa chỉ và cổng cục bộ không tạo ra bất kỳ giao diện hiển thị nào; dấu vết duy nhất nằm trong panel network của DevTools trình duyệt, thứ mà hầu như chẳng ai kiểm tra. Chính sự im lặng đó, hơn cả bản thân cơ chế kỹ thuật, là lý do khiến việc này đáng được vá bằng một lời nhắc xin quyền thay vì trông chờ vào thiện chí của từng trang web.

Đây có phải cùng một chuyện với việc WebRTC làm lộ địa chỉ IP cục bộ của tôi không?

Không, dù cả hai đều liên quan tới mạng cục bộ của bạn. Quá trình thu thập ICE candidate của WebRTC có thể làm lộ địa chỉ IP cục bộ của bạn như một tác dụng phụ của việc thiết lập kết nối peer. Đây là chuyện khác: một trang web chủ động gửi request tới các địa chỉ trên mạng của bạn và đọc kết quả thời gian/trạng thái, thay vì tình cờ biết được một địa chỉ về chính máy của bạn.

Tôi có cần làm gì để được bảo vệ không?

Nếu bạn đang dùng một phiên bản Chrome hiện hành, lời nhắc xin quyền đã được bật mặc định — không có cài đặt nào cần bật thêm. Chỉ cần từ chối lời nhắc trên các trang web không có lý do rõ ràng nào để nói chuyện với mạng cục bộ của bạn, giống như cách bạn xử lý bất kỳ yêu cầu quyền nào không khớp với những gì trang web đó tuyên bố mình làm.

Vì sao Private Network Access lại mất nhiều thời gian để trở thành Local Network Access?

Vì thiết kế ban đầu của nó giả định rằng các thiết bị cục bộ có thể được cập nhật để trả lời một dạng request mới, trong khi phần lớn router, máy in và thiết bị IoT tiêu dùng thực tế gần như không bao giờ được cập nhật sau khi xuất xưởng. Sau nhiều năm liên tục dời ngày thực thi, Chrome cuối cùng kết luận rằng bản sửa lỗi phải nằm hoàn toàn trong trình duyệt và trong quyết định của người dùng, chứ không thể phụ thuộc vào sự hợp tác từ phần cứng vốn sẽ chẳng bao giờ tới.

Kết luận

Một trang web công khai chạm tới 127.0.0.1 và địa chỉ LAN của router nhà bạn không phải là chuyện giả định — đó là một request mà trình duyệt của bạn sẵn sàng gửi đi, được đo thời gian đủ cẩn thận để lập bản đồ những gì đang lắng nghe, mà không cần đọc một byte nội dung phản hồi nào. Private Network Access từng cố bịt lỗ hổng đó bằng cách xin phép các thiết bị cục bộ không thể liên lạc được, và mất nhiều năm để nhận ra cách đó không thể mở rộng quy mô. Local Network Access thay vào đó hỏi chính bạn, bằng một lời nhắc xin quyền ra mắt trong Chrome 142. Cơ chế này đáng để biết ngay cả khi bạn chưa bao giờ tự mình thấy lời nhắc: đó là thêm một ví dụ về một tính năng trình duyệt trông có vẻ chẳng liên quan gì tới danh tính của bạn — một request mạng thuần túy — hóa ra lại mô tả máy tính và mạng của bạn chính xác chẳng kém gì bất kỳ script fingerprinting nào.

---

Đọc thêm:

• Dấu vân tay trình duyệt: Cách bảo vệ quyền riêng tư
• Vân tay CSS: Theo dõi không cần JavaScript
• Session Replay: Cách website ghi lại từng cử động của bạn
• Visitor ID bền vững: Sống sót qua ẩn danh, VPN, xóa cache
• Rủi ro quyền riêng tư từ tiện ích mở rộng trình duyệt
• Entropy dấu vân tay trình duyệt và tập ẩn danh là gì