Node-Unblocker cho Web Scraping: Cài đặt, Rủi ro bảo mật & Các lựa chọn tốt hơn

Tóm tắt:

• Node-Unblocker là một thư viện tương thích với Express cho phép proxy và viết lại các trang web từ xa. Nó có thể chứng minh việc viết lại URL trên các trang đơn giản, nhưng không phải là một giải pháp chống bot hiện đại hay một trình duyệt JavaScript tổng quát.
• Sử dụng Node.js 24 LTS cho một chuẩn triển khai hiện tại. Các ví dụ Node.js 16 cũ hơn vẫn có thể tìm thấy trên mạng nhưng đã hết hạn sử dụng.
• Ràng buộc một máy chủ trình diễn vào 127.0.0.1, yêu cầu một danh sách cho phép, và không bao giờ công khai một proxy mở chưa xác thực. Một điểm đến do người dùng kiểm soát có thể tạo ra lỗ hổng giả mạo yêu cầu phía máy chủ, rủi ro mạng nội bộ, rủi ro thông tin xác thực, lạm dụng và ghi log.
• OAuth, postMessage, mã nhạy cảm với nguồn gốc, các trang web phức tạp, và hành vi ứng dụng hiện đại có thể gặp sự cố vì việc viết lại phản hồi không giống như chạy mục tiêu trong nguồn gốc trình duyệt ban đầu của nó.
• Đối với việc thu thập dữ liệu có chứng thực, hãy chọn Node-Unblocker chỉ khi mô hình viết lại của nó thật sự phù hợp. Một API thu thập dữ liệu được quản lý thường là một ranh giới tốt hơn khi kết quả mong muốn là dữ liệu trang thay vì dịch vụ proxy công cộng.

Node-Unblocker rất dễ trình diễn: cài đặt Express, gắn một đối tượng middleware, và thêm tiền tố cho một URL từ xa với một đường dẫn cục bộ. Sự đơn giản đó có thể che giấu câu hỏi kỹ thuật thực sự.

Dự án là một proxy web và thư viện viết lại phản hồi. Nó không được thiết kế để tái tạo một mô hình bảo mật trình duyệt hiện đại đầy đủ hoặc giải quyết các hệ thống chống bot đương đại. Một khi dịch vụ chấp nhận các URL đích tùy ý, nó cũng trở thành một ranh giới mạng có rủi ro cao.

Hướng dẫn này cho thấy cách thiết lập chỉ localhost, giải thích nơi Node-Unblocker gặp thất bại, và cung cấp một mô hình quyết định về bảo mật và xây dựng so với quản lý cho việc thu thập dữ liệu web.

Node-Unblocker là gì?

Node-Unblocker, được xuất bản trên npm dưới tên unblocker, là một thư viện Node.js để proxy và viết lại các trang web từ xa. Nó có thể sửa đổi liên kết và URL tài nguyên để trình duyệt tiếp tục điều hướng qua đường dẫn proxy.

Kho lưu trữ chính thức của dự án mô tả nó là một thư viện proxy và viết lại trang tổng quát. Các hạn chế đã được tài liệu hóa bao gồm các luồng OAuth, postMessage, và một số trang web phức tạp. Gói này được phát hành dưới AGPL-3.0, vì vậy một nhóm sản xuất nên xem xét nghĩa vụ giấy phép với tư vấn.

Bản ghi gói npm hiện tại liệt kê phiên bản 2.3.1. Hoạt động và chu kỳ bảo trì của đăng ký nên là một phần của xem xét việc áp dụng; một cài đặt thành công không phải là bằng chứng cho thấy một proxy đã sẵn sàng cho sản xuất.

Node-Unblocker có thể:

• chuyển tiếp một yêu cầu HTTP đến một trang từ xa;
• chuyển tiếp và viết lại các phần của phản hồi;
• thêm tiền tố cho các liên kết để điều hướng sau đó vẫn nằm dưới đường dẫn proxy;
• tích hợp với middleware của Express;
• xử lý một số lần nâng cấp WebSocket.

Nó không tự động:

• thực thi JavaScript phía client trên máy chủ;
• duy trì mọi nguồn gốc trình duyệt và giả định bảo mật;
• giải quyết CAPTCHAs hoặc xác thực lưu lượng nâng cao;
• hạn chế các đích đến;
• thêm xác thực người thuê;
• bảo vệ các mạng nội bộ khỏi các URL do người dùng kiểm soát;
• cung cấp một nhóm proxy dân cư hoặc nhắm mục tiêu khu vực;
• xác thực rằng trang trở về chứa dữ liệu mong muốn.

Sử dụng một tiêu chuẩn Node.js hiện tại

Sử dụng một phiên bản LTS đã được hỗ trợ thay vì sao chép một tệp triển khai cũ. Bảng phát hành Node.js chính thức liệt kê Node.js 24 là LTS và Node.js 16 là hết hạn vào thời điểm viết bài.

Hướng dẫn này sử dụng:

• Node.js 24 LTS;
• Express 5.2.1;
• unblocker 2.3.1;
• ràng buộc localhost;
• một danh sách cho phép điểm đến cố định.

Tạo dự án:

mkdir node-unblocker-local-demo
cd node-unblocker-local-demo
npm init -y
npm install express@5.2.1 unblocker@2.3.1
npm pkg set private=true
npm pkg set engines.node=">=24 <25"

Việc xác định phiên bản giúp bản trình diễn có thể tái tạo. Chạy npm audit, xem xét biểu đồ phụ thuộc, và lặp lại việc xem xét trước mỗi hình ảnh triển khai được nâng cao.

Xây dựng một bản demo Node-Unblocker chỉ localhost

Mã dưới đây cố ý bị giới hạn. Nó liên kết với vòng lặp, chỉ cho phép hai miền tài liệu, từ chối các giao thức không phải HTTP, giới hạn độ dài URL, và vô hiệu hóa các tiêu đề nhận diện của Express.

Đây là một bản trình diễn trực tiếp địa phương, không phải là một biện pháp phòng ngừa SSRF hoàn chỉnh cho sản xuất. Một proxy sản xuất cũng cần xác thực, quy tắc tường lửa xuất cảnh, điều khiển DNS, giới hạn tài nguyên, giám sát, và phản ứng với lạm dụng.

"use strict";

const express = require("express");
const Unblocker = require("unblocker");

const app = express();
const port = Number(process.env.PORT || 8080);
const prefix = "/proxy/";
const allowedHosts = new Set(["example.com", "www.iana.org"]);
const unblocker = new Unblocker({ prefix });

app.disable("x-powered-by");

app.get("/healthz", (_req, res) => {
  res.json({ status: "ok" });
});

app.use((req, res, next) => {
  if (!req.originalUrl.startsWith(prefix)) {
    return next();
  }

const rawTarget = req.originalUrl.slice(prefix.length);
if (rawTarget.length > 2048) {
  return res.status(414).send("URL mục tiêu quá dài");
}

let target;
try {
  target = new URL(rawTarget);
} catch {
  return res.status(400).send("URL mục tiêu không hợp lệ");
}

if (!["http:", "https:"].includes(target.protocol)) {
  return res.status(400).send("Giao thức không được phép");
}
if (!allowedHosts.has(target.hostname)) {
  return res.status(403).send("Máy chủ mục tiêu không được phép");
}

return next();
});

app.use(unblocker);

app.use((_req, res) => {
  res.status(404).send("Không tìm thấy");
});

const server = app.listen(port, "127.0.0.1", () => {
  console.log(`Proxy cục bộ: http://127.0.0.1:${port}${prefix}`);
});
server.on("upgrade", unblocker.onUpgrade);

Lưu tệp dưới dạng server.js, sau đó chạy:

node --check server.js
node server.js

Ràng buộc loopback không chỉ mang tính hình thức. app.listen(port) có thể lắng nghe trên mọi giao diện có sẵn tùy thuộc vào môi trường, điều này có thể làm lộ proxy ra mạng cục bộ hoặc điểm vào của container.

Kiểm tra proxy cục bộ

Mở một terminal thứ hai:

curl --fail http://127.0.0.1:8080/healthz
curl --fail "http://127.0.0.1:8080/proxy/https://example.com/"
curl -i "http://127.0.0.1:8080/proxy/https://invalid.example/"

Kiểm tra sức khỏe nên trả về JSON. Trang ví dụ đã được cho phép sẽ được chuyển tiếp. Tên miền không được chấp nhận nên nhận được phản hồi HTTP 403.

Sử dụng công cụ phát triển của trình duyệt để kiểm tra:

• các liên kết nào đã được viết lại;
• liệu các bảng kiểu và hình ảnh vẫn tải được hay không;
• liệu các chuyển hướng có vẫn nằm trong phạm vi hay không;
• liệu có cookies hoặc headers xác thực hay không;
• liệu trang phụ thuộc vào các cuộc gọi API phía client hay không;
• liệu nội dung cuối cùng có khớp với trang mong đợi hay không.

Không thử nghiệm với thông tin tài khoản. Một proxy có thể quan sát headers, bodies, cookies, các tham số truy vấn và URL đích.

Cách Node-Unblocker viết lại hoạt động

Ở cấp độ cao:

1. Express nhận một yêu cầu dưới định danh đã cấu hình.
2. Node-Unblocker trích xuất mục tiêu từ xa.
3. Máy chủ gửi một yêu cầu tới mục tiêu đó.
4. Thư viện chuyển tiếp các headers và nội dung phản hồi.
5. Đối với nội dung được hỗ trợ, nó viết lại các URL để các yêu cầu trình duyệt sau này đi qua cùng một định danh.

Mô hình này hoạt động tốt nhất cho các trang thông thường với các liên kết và mẫu đơn thông thường. Nó trở nên mong manh khi một trang phụ thuộc vào:

• Chính sách bảo mật nội dung nghiêm ngặt;
• Kiểm tra nguồn gốc;
• URLs tài nguyên đã ký hoặc hết hạn;
• Các worker dịch vụ;
• Nhắn tin cửa sổ chéo;
• Các điểm cuối được xây dựng động;
• Hành vi WebSocket phức tạp;
• Bộ nhớ trình duyệt gắn liền với nguồn gốc ban đầu;
• Chuyển hướng OAuth;
• Hệ thống chống bot đánh giá mạng, TLS, JavaScript và hành vi cùng nhau.

Việc viết lại văn bản trong một phản hồi không thể tái tạo tất cả các mối quan hệ đó.

Giới hạn của Node-Unblocker cho việc thu thập dữ liệu web

Nó không phải là một trình dựng trình duyệt

Node-Unblocker chuyển tiếp và viết lại nội dung. JavaScript phía client có thể chạy trong trình duyệt của người dùng, nhưng máy chủ proxy không cung cấp một môi trường trình duyệt riêng biệt tạo ra DOM đã được xây dựng cho một pipeline dữ liệu.

Nếu một công cụ thu thập dữ liệu cần một lưới sản phẩm được tạo ra sau khi thực thi JavaScript, một phản hồi proxy đơn giản có thể chỉ chứa một shell ứng dụng.

OAuth và postMessage có thể bị hỏng

OAuth phụ thuộc vào các URL chuyển hướng đã đăng ký, kiểm tra nguồn gốc, cookies và quy tắc giữa các trang. postMessage phụ thuộc vào các nguồn cửa sổ. Việc viết lại một trang dưới một nguồn proxy thay đổi những giả định đó, vì vậy việc xác thực và các ứng dụng nhúng có thể thất bại.

Các trang phức tạp có thể thiếu sót

Các ứng dụng hiện đại phân phối công việc trên HTML, gói JavaScript, cuộc gọi API, worker, lưu trữ và WebSockets. Một số URL có thể được viết lại trong khi các yêu cầu được tạo ra tại runtime khác có thể thoát khỏi đường dẫn proxy hoặc vi phạm các chính sách của mục tiêu.

Nó không cung cấp sự đa dạng về IP

Một phiên bản Node-Unblocker tự lưu trữ sử dụng danh tính mạng của máy chủ của nó trừ khi một lớp định tuyến khác được thêm vào. Nó không bao gồm các pool IP dành cho hộ gia đình, di động, nhà cung cấp dịch vụ Internet hoặc nhắm mục tiêu theo khu vực.

Bảo trì thuộc về người vận hành

Người vận hành sở hữu các bản cập nhật bảo mật Node.js, các phụ thuộc npm, khả năng proxy, chính sách đích, cấu hình TLS, xác thực, nhật ký, phản hồi sự cố, điều khoản của nhà cung cấp đám mây và báo cáo lạm dụng. Đó là một dịch vụ đáng kể ngay cả khi middleware nhỏ.

Rủi ro proxy mở và SSRF

Một dịch vụ có thể lấy một URL do người dùng cung cấp có thể được sử dụng để tiếp cận các địa điểm mà người dùng không thể truy cập trực tiếp. Đó là rủi ro lừa đảo yêu cầu phía máy chủ cốt lõi.

Bảng cheat ngăn chặn SSRF của OWASP khuyến nghị danh sách cho phép khi các điểm đến đã biết và phòng thủ sâu ở cả hai lớp ứng dụng và mạng. Nó cũng nhấn mạnh loopback, các dải địa chỉ riêng, địa chỉ local-link và các dịch vụ metadata đám mây.

Một proxy bị lộ có thể bị lạm dụng để:

• quét các dịch vụ riêng tư;

- truy cập siêu dữ liệu của instance đám mây;
- đánh cắp thông tin xác thực hoặc token truy cập;
- ẩn lưu lượng truy cập xấu sau địa chỉ IP của nhà điều hành;
- tiêu thụ băng thông và tài nguyên tính toán;
- chuyển tiếp nội dung bị cấm;
- ghi lại dữ liệu yêu cầu và phản hồi nhạy cảm;
- tạo rủi ro pháp lý và tài khoản đám mây cho nhà điều hành.

Danh sách từ chối tên miền không đủ. DNS có thể thay đổi giữa việc xác thực và kết nối, chuyển hướng có thể chuyển sang một máy chủ khác, định dạng IP không thường gặp có thể tránh được các kiểm tra chuỗi đơn giản, và IPv6 mở rộng các dạng địa chỉ phải được xử lý.

## Danh sách kiểm tra triển khai an toàn

Nếu một trường hợp sử dụng sản xuất vẫn biện minh cho Node-Unblocker, hãy coi nó như một dịch vụ mạng nhạy cảm với bảo mật:

- **Giữ cho nó riêng tư theo mặc định.** Liên kết với loopback hoặc một giao diện riêng tư.
- **Yêu cầu xác thực mạnh.** Sử dụng thông tin xác thực dịch vụ có thời gian sống ngắn và quyền hạn của khách hàng.
- **Ưu tiên danh sách cho phép đích.** Định nghĩa chính xác các máy chủ và cổng mà quy trình công việc cần.
- **Thi hành chính sách ra ngoài.** Chặn loopback, mạng riêng, các khoảng liên kết cục bộ và dịch vụ siêu dữ liệu ở lớp mạng.
- **Xác thực sau khi giải quyết DNS.** Xác nhận mọi địa chỉ đã được giải quyết có thể định tuyến toàn cầu và được phê duyệt.
- **Kiểm soát chuyển hướng.** Đánh giá lại địa chỉ đích trong mỗi lần chuyển hướng.
- **Giới hạn các phương thức và giao thức.** Từ chối bất kỳ thứ gì mà quy trình công việc không yêu cầu.
- **Đặt giới hạn cho body, header, URL, thời gian và độ song song.**
- **Bảo vệ thông tin xác thực.** Xóa tiêu đề xác thực đầu vào trừ khi được yêu cầu rõ ràng.
- **Giảm thiểu nhật ký.** Không lưu trữ token, cookie, chuỗi truy vấn hoàn chỉnh hoặc nội dung phản hồi theo mặc định.
- **Tách biệt các khách hàng.** Phiên hoặc cookie của một khách hàng không bao giờ được truyền đến một khách hàng khác.
- **Cập nhật phiên bản runtime và các phụ thuộc.**
- **Rà soát chính sách sử dụng chấp nhận của nhà cung cấp đám mây.**
- **Thêm phát hiện lạm dụng và cách ngừng hoạt động.**

Danh sách cho phép trong JavaScript chỉ là một lớp. Chính sách mạng phải vẫn hiệu quả ngay cả khi xác thực ứng dụng thất bại.

> Nếu mục tiêu là dữ liệu trang đã được ủy quyền thay vì vận hành một dịch vụ proxy, hãy so sánh [API Scraping Toàn Cầu](https://www.scrapeless.com/vi/product/universal-scraping-api?utm_source=website&utm_medium=blog&utm_campaign=universalscrapingapi&utm_term=node-unblocker) với toàn bộ chi phí bảo mật và duy trì Node-Unblocker.

## Node-Unblocker so với API scraping được quản lý

| Khu vực quyết định | Node-Unblocker | API scraping được quản lý |
|---|---|---|
| Mô hình chính | Proxy tự lưu trữ và sửa đổi phản hồi | Nhận trang thông qua API |
| Kết xuất JavaScript | Không được cung cấp bởi máy chủ | Có sẵn khi khả năng API đã chọn hỗ trợ |
| Hồ bơi IP | Địa chỉ IP máy chủ trừ khi cấu hình riêng | Tùy chọn định tuyến do nhà cung cấp quản lý |
| An ninh đích | Trách nhiệm của nhà điều hành | Nhà cung cấp bảo vệ dịch vụ của mình; khách hàng vẫn kiểm soát phạm vi mục tiêu |
| Tương thích trình duyệt | Bị giới hạn bởi mô hình sửa đổi | Thích hợp hơn cho việc nhận trang đã được kết xuất |
| Quyền sở hữu cơ sở hạ tầng | Dịch vụ Node, mạng, mở rộng, nhật ký, sự cố | Tích hợp API, xác thực, kiểm soát sử dụng |
| Sự phù hợp tốt nhất | Trường hợp sử dụng sửa đổi riêng tư, hẹp, trong danh sách cho phép | Thu thập dữ liệu có ủy quyền nơi đầu ra quan trọng hơn vận hành proxy |

Chọn Node-Unblocker khi:

- bộ đích nhỏ và cố định;
- hành vi sửa đổi đã được kiểm tra trên mọi trang hỗ trợ;
- dịch vụ vẫn riêng tư;
- nhóm có thể sở hữu an ninh mạng và phản ứng với sự cố;
- một trang proxy thông thường là yêu cầu sản phẩm thực tế.

Chọn một lớp thu thập được quản lý khi:

- sản phẩm mong muốn là HTML, Markdown, hoặc dữ liệu trang có cấu trúc;
- mục tiêu yêu cầu kết xuất hoặc xử lý lưu lượng chuyên biệt;
- sự lựa chọn khu vực và mạng quan trọng;
- duy trì một proxy an toàn nằm ngoài giá trị cốt lõi của sản phẩm;
- nhóm muốn một hợp đồng API với xác thực rõ ràng.

## Sử dụng Scrapeless Web Unlocker thông qua API scraping Toàn Cầu

Scrapeless cung cấp diễn viên Web Unlocker thông qua [tài liệu API scraping Toàn Cầu](https://docs.scrapeless.com/en/universal-scraping-api/quickstart/introduction?utm_source=website&utm_medium=blog&utm_campaign=universalscrapingapi&utm_term=node-unblocker). Ứng dụng gửi một URL mục tiêu đã được ủy quyền và xác thực payload được trả về.

Yêu cầu này cần một `SCRAPELESS_API_KEY` và `TARGET_URL` sở hữu bởi người đọc:

```bash
curl --request POST "https://api.scrapeless.com/api/v1/scraper/request" \
  --header "Content-Type: application/json" \
  --header "x-api-token: ${SCRAPELESS_API_KEY}" \
  --data "{
    \"actor\": \"unlocker.webunlocker\",
    \"input\": {
      \"url\": \"${TARGET_URL}\"
    }
  }"

Khách hàng vẫn cần:

• hạn chế các URL mà người dùng có thể gửi;
• giữ thông tin xác thực API ra ngoài mã trình duyệt;
• thiết lập ngân sách yêu cầu và chi tiêu;
• xác thực danh tính trang và các trường yêu cầu;
• cách ly đầu ra bất ngờ;
• tuân thủ luật pháp, điều khoản trang web, chỉ thị robot, và yêu cầu về quyền riêng tư.
  Để có cái nhìn tổng quan về kiến trúc tiếp nhận theo hướng phòng thủ, hãy đọc cách xây dựng một trình thu thập dữ liệu web phân tán. Để tìm hiểu các nguyên tắc về định tuyến, hãy xem proxy được sử dụng để làm gì.

Khung quyết định triển khai

Sử dụng năm câu hỏi:

1. Đầu ra là gì? Một trang viết lại có thể duyệt, HTML thô, nội dung đã được xử lý, hay bản ghi có cấu trúc?
2. Ai có thể chọn điểm đến? Một công việc nội bộ cố định hay một người dùng bên ngoài không đáng tin cậy?
3. Các hành vi của trình duyệt nào là cần thiết? Liên kết tĩnh, xử lý JavaScript, OAuth, WebSockets, hay thực thi từ nguồn gốc ban đầu?
4. Ai sở hữu các hoạt động bảo mật? Kỹ sư ứng dụng, một đội nền tảng, hay một nhà cung cấp được quản lý?
5. Làm thế nào để đo lường thành công? Thời gian hoạt động của proxy hay bản ghi được chấp nhận, xác thực?

Đối với hầu hết các đội thu thập dữ liệu, câu hỏi thứ năm là quyết định. Nếu chỉ số doanh nghiệp là các bản ghi đầy đủ, việc vận hành một dịch vụ proxy không giới hạn sẽ tạo ra công việc mà không cải thiện hợp đồng dữ liệu.

Chọn ranh giới phù hợp với công việc

Node-Unblocker hữu ích cho việc hiểu cách viết lại proxy và cho các quy trình làm việc hạn hẹp, riêng tư. Nó không nên được trình bày như một công cụ mở khóa toàn cầu, một trình duyệt không có giao diện hoặc một proxy công cộng an toàn.

Giữ bản trình diễn trên localhost. Nếu một ứng dụng thực sự yêu cầu, hãy thêm xác thực, điểm đến nghiêm ngặt, chính sách thoát mạng, tài nguyên có giới hạn, nhật ký an toàn và kế hoạch sự cố trước bất kỳ triển khai nào.

Nếu kết quả mong muốn là dữ liệu web được ủy quyền, hãy so sánh mức giá của Scrapeless, sau đó tạo một tài khoản Scrapeless và thử nghiệm một mục tiêu đại diện thông qua Universal Scraping API. Đo lường sự chấp nhận nội dung và quyền sở hữu kỹ thuật, không chỉ là liệu một yêu cầu trả lại HTTP 200.

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

Node-Unblocker được sử dụng để làm gì?

Node-Unblocker được sử dụng để xây dựng một proxy web Node.js mà chuyển tiếp các yêu cầu và viết lại các trang từ xa để các liên kết tiếp tục đi qua đường dẫn proxy. Nó phù hợp nhất cho các trường hợp sử dụng riêng tư, có kiểm soát với các điểm đến đã biết.

Node-Unblocker có phải là một trình duyệt không có giao diện không?

Không. Đây là middleware proxy và viết lại. Nó không cung cấp một trình duyệt phía máy chủ thực thi một trang và trả lại DOM đã được xử lý.

Node-Unblocker có thể xử lý các hệ thống chống bot hiện đại không?

Không đáng tin cậy. Các biện pháp bảo vệ hiện đại có thể đánh giá danh tiếng IP, chi tiết TLS, trạng thái trình duyệt, tín hiệu JavaScript, cookie và hành vi. Node-Unblocker không quản lý toàn bộ hệ thống đó.

Có an toàn khi công khai Node-Unblocker không?

Không có proxy mở không xác thực nào nên được công khai. Những điểm đến do người dùng kiểm soát tạo ra rủi ro SSRF, mạng riêng tư, siêu dữ liệu đám mây, lạm dụng, thông tin xác thực và ghi nhật ký. Giữ cho nó là riêng tư và áp dụng xác thực, danh sách cho phép và kiểm soát thoát mạng.

Tại sao các trang OAuth và postMessage lại thất bại qua Node-Unblocker?

Các hệ thống đó phụ thuộc vào nguồn gốc, chuyển hướng đã đăng ký, cookie và độ tin cậy giữa các cửa sổ. Phục vụ một trang dưới nguồn gốc proxy thay đổi bối cảnh bảo mật và có thể làm gián đoạn quy trình.

Có phương án thay thế nào tốt hơn cho việc thu thập dữ liệu web không?

Khi mục tiêu là nội dung trang hoặc dữ liệu có cấu trúc, hãy sử dụng API nguồn được ủy quyền nơi có sẵn hoặc một API thu thập dữ liệu được quản lý hỗ trợ việc xử lý và định tuyến cần thiết. Giữ chính sách mục tiêu, xác thực, lưu trữ và tuân thủ trong ứng dụng khách.