Cào dữ liệu API GraphQL được bảo vệ: vượt qua giới hạn, APQ và dấu vân tay TLS

Bạn có muốn dùng thử Octo Browser với giá ưu đãi không?
Sử dụng mã khuyến mại OCTOSCRAPER để được giảm giá 30% cho bất kỳ gói đăng ký nào. Ưu đãi này chỉ dành cho người dùng mới.

Vấn đề của điểm cuối duy nhất (single endpoint)

Trong kiến trúc REST truyền thống, định tuyến giúp phân phối tải và áp dụng các giới hạn tốc độ khác nhau. Ví dụ: điểm cuối /api/users có thể có một nhóm hạn chế, trong khi /api/feed có một nhóm hạn chế khác.

Với GraphQL, chỉ có một điểm cuối duy nhất. Tất cả dữ liệu hữu ích được gửi trong phần thân của yêu cầu POST dưới dạng JSON chứa truy vấn, các biến và tên hoạt động. Ở cấp độ HTTP, nó trông giống như thế này:

{
  "operationName": null,
  "variables": {},
  "query": "query { users { id name posts(last: 5) { id text timestamp } } }"
}

{
  "operationName": null,
  "variables": {},
  "query": "query { users { id name posts(last: 5) { id text timestamp } } }"
}

Tuy nhiên, để dễ đọc, chúng ta thường quen nhìn thấy cùng một yêu cầu đó dưới dạng biểu đồ mở rộng:

query {
 users {
   id
   name
   posts(last: 5) {
     id
     text
     timestamp
   }
 }
}

query {
 users {
   id
   name
   posts(last: 5) {
     id
     text
     timestamp
   }
 }
}

Điều này có nghĩa là, từ góc độ của các bộ cân bằng tải và hệ thống bảo mật cơ bản, mọi yêu cầu đều xuất hiện dưới dạng một lệnh gọi giống hệt nhau đến cùng một URL.

Để xác định xem máy khách thực sự đang làm gì, các hệ thống chống bot sẽ cố gắng kiểm tra tải trọng JSON trong thời gian thực, trong khi máy chủ ứng dụng phân tích cú pháp AST (Cây cú pháp trừu tượng) nặng nề kết quả.

Các chiến lược thu thập dữ liệu (scraping) và bảo vệ hiện đại được xây dựng chính xác xung quanh đặc tính kiến trúc này.

Cần làm gì khi tính năng Tự kiểm tra (Introspection) bị tắt

Trước khi phát triển một công cụ thu thập dữ liệu, hãy xác định chính xác cách thức hoạt động của hệ thống chống bot trên trang web mục tiêu. Phân tích GraphQL thường bắt đầu bằng cách thử một truy vấn Introspection. Tính năng tích hợp sẵn này hướng dẫn máy chủ trả về tài liệu API đầy đủ, bao gồm tất cả các kiểu, trường, mối quan hệ và đối số.

Tất nhiên, các nền tảng nghiêm túc sẽ hạn chế quyền truy cập vào thông tin này. Mặc dù vậy, vẫn có những cách để có được nó.

• Phân tích các thông báo lỗi. Nhiều máy chủ GraphQL cố gắng hỗ trợ người dùng theo mặc định. Ví dụ: nếu bạn yêu cầu một trường không tồn tại có tên là nam, máy chủ có thể trả về một lỗi như là "Cannot query field "nam". Did you mean "name"?". Quá trình này có thể được tự động hóa để tái cấu trúc dần dần một phần đáng kể của giản đồ ẩn.

• Tìm kiếm rò rỉ phần mềm trung gian (middleware). Introspection thường bị tắt trên máy chủ ứng dụng chính nhưng vô tình bị để mở trên các dịch vụ siêu nhỏ hoặc API gateways có thể truy cập trực tiếp.

Thu thập dữ liệu luôn đòi hỏi sự ứng biến. Hãy tìm kiếm các con đường thay thế, vì chúng thường không được bảo vệ.

Truy vấn tồn tại tự động (Automatic Persisted Queries - APQ)

Giả sử bạn đã tái cấu trúc thành công giản đồ, hiểu cấu trúc dữ liệu và xây dựng truy vấn GraphQL của mình. Tuy nhiên, thay vì gửi dữ liệu, máy chủ lại trả về lỗi xác thực. Đó chính là do APQ đang hoạt động.

Để tránh việc gửi liên tục các truy vấn biểu đồ lớn qua mạng, các nhà phát triển đã giới thiệu Truy vấn tồn tại tự động (APQ). Tối ưu hóa GraphQL này cho phép máy khách gửi một mã băm (hash - một mã định danh truy vấn duy nhất) thay vì toàn bộ văn bản truy vấn. Điều này giúp giảm đáng kể kích thước yêu cầu, tăng tốc độ truyền và cho phép lưu các truy vấn vào bộ nhớ đệm trên CDN.

Đây là cách nó hoạt động đối với một máy khách điển hình: thay vì gửi truy vấn đầy đủ, giao diện người dùng (frontend) sẽ tính toán mã băm SHA-256 của nó và chỉ gửi mã băm cùng với các biến truy vấn. Máy chủ kiểm tra bộ nhớ đệm của nó và nếu mã băm được nhận diện, nó sẽ thực thi truy vấn liên quan.

Ví dụ: frontend của Reddit hoàn toàn không gửi phần thân truy vấn. Thay vào đó, nó chỉ gửi tên hoạt động đã được đăng ký trước (operation: "ExposeVariant") cùng với các biến được yêu cầu

Tại sao điều này làm phức tạp hóa việc thu thập dữ liệu: bạn không thể chỉ đơn giản là viết truy vấn tùy chỉnh của riêng mình trong một tập lệnh và gửi nó đến máy chủ. Máy chủ yêu cầu một mã băm 64 ký tự. Nếu bạn gửi truy vấn của mình dưới dạng văn bản thuần túy, bạn sẽ nhận được lỗi xác thực.

Các cách để vượt qua điều này:

1. Phân tích cú pháp tài sản tĩnh. Tất cả các mã băm hợp lệ đều được nhúng trong các gói JavaScript frontend đã biên dịch. Một tập lệnh thu thập dữ liệu tự động trước tiên nên tải xuống các tệp JS này, giải nén các ánh xạ từ mã băm sang truy vấn, và chỉ sau đó mới xây dựng cơ sở dữ liệu trước khi đưa ra các yêu cầu thực tế.

2. Các yêu cầu dự phòng. APQ được thiết kế để nếu máy chủ không nhận diện được mã băm, máy khách sẽ gửi lại cả mã băm và truy vấn đầy đủ. Nhiều máy chủ vẫn để tính năng này hoạt động, cho phép công cụ thu thập dữ liệu đăng ký động các truy vấn tùy ý—ngay cả những truy vấn chưa bao giờ được dự định bởi frontend.

Xóa mờ lớp vận chuyển (TLS fingerprinting)

Để tránh làm cạn kiệt proxy pool của bạn, hãy chú ý đến lớp vận chuyển. Bắt đầu giả mạo bằng cách đảm bảo rằng bắt tay TLS của bạn được định hình chính xác.

TLS (Bảo mật lớp truyền tải) là một giao thức thiết lập các kết nối an toàn. Trong quá trình bắt tay, máy khách gửi một thông điệp ClientHello chứa một tập hợp các tham số mã hóa. Các tham số này tiết lộ rất nhiều điều về bạn cho máy chủ.

Các hệ thống bảo vệ như Cloudflare, Akamai và DataDome phân tích các dấu vết mạng này. Các thư viện tiêu chuẩn như requests của Python hoặc axios của Node.js có các chữ ký rất dễ nhận biết, khác với các chữ ký của Google Chrome hoặc Safari thực tế, vì chúng gửi một thứ tự khác của các bộ mật mã, phiên bản giao thức và phần mở rộng trong gói ClientHello.

Có hai cách tiếp cận chính để thu thập dữ liệu quy mô lớn:

1. Các thư viện chuyên dụng. Thay thế các máy khách HTTP tiêu chuẩn bằng các thư viện có khả năng mô phỏng dấu vân tay TLS, chẳng hạn như curl-cffi cho Python hoặc tls-client cho Go. Các công cụ này bắt chước hành vi của trình duyệt ở cấp độ yêu cầu trong khi vẫn duy trì hiệu suất cao.

2. Trình duyệt chống phát hiện. Nếu nền tảng mục tiêu có hệ thống bảo vệ đặc biệt hung hãn, bạn có thể sử dụng một trình duyệt chống phát hiện tiên tiến như Octo Browser. Trong trường hợp này, việc giả mạo dấu vân tay TLS diễn ra ở cấp độ nhân trình duyệt. Mặc dù phương pháp này chậm hơn một chút nhưng nó cũng là phương pháp đáng tin cậy nhất. Máy chủ nhìn thấy hành vi không thể phân biệt được với hành vi của một trình duyệt thực, giảm thiểu nguy cơ bị phát hiện và chặn.

Vượt qua giới hạn tốc độ

Khi công cụ thu thập dữ liệu của bạn đã hoạt động ổn định, bạn có thể gặp phải một lớp bảo vệ khác: giới hạn tốc độ (rate limiting).

Với các API REST, hệ thống bảo vệ thường đếm số lượng yêu cầu HTTP mỗi giây từ một địa chỉ IP duy nhất. Tuy nhiên, GraphQL cho phép một yêu cầu HTTP duy nhất truy xuất một lượng lớn dữ liệu liên quan. Các công cụ thu thập dữ liệu thường tận dụng hai tính năng tích hợp sẵn của GraphQL để vượt qua các bộ đếm yêu cầu truyền thống:

• Yêu cầu hàng loạt (Batch requests). Ban đầu, tính năng gom nhóm (batching) được giới thiệu để frontend có thể kết hợp nhiều yêu cầu API độc lập thành một mảng JSON duy nhất và gửi chúng cùng nhau. Đối với một công cụ thu thập dữ liệu, điều này có nghĩa là thay vì thực hiện 100 yêu cầu riêng biệt để truy xuất 100 hồ sơ người dùng, bạn có thể gửi một yêu cầu duy nhất chứa một mảng gồm 100 đối tượng hoạt động. Nếu bộ giới hạn tốc độ chỉ phân tích lưu lượng truy cập ở cấp độ HTTP, nó sẽ chỉ tính đây là một yêu cầu duy nhất.

• Bí danh (Aliases). Nếu máy chủ chặn tính năng gom nhóm JSON, bạn có thể sử dụng một tính năng khác của GraphQL: bí danh. Bí danh cho phép bạn yêu cầu cùng một trường nhiều lần với các đối số khác nhau trong một hoạt động duy nhất. Điều này làm tăng tải cho cơ sở dữ liệu của máy chủ, nhưng đối với tường lửa mạng, nó vẫn xuất hiện như là một yêu cầu hợp lệ duy nhất.

query GetMultipleUsers {
  user_1: user(id: "1001") { name, email }
  user_2: user(id: "1002") { name, email }
  # … and so on
}

query GetMultipleUsers {
  user_1: user(id: "1001") { name, email }
  user_2: user(id: "1002") { name, email }
  # … and so on
}

Tuy nhiên, điều quan trọng là phải hiểu rằng ngày nay cả gom nhóm và bí danh đều không đảm bảo giải quyết được vấn đề.

Thay vì chỉ đơn giản đếm số lượng yêu cầu, nhiều nền tảng hiện nay thực hiện Phân tích chi phí truy vấn (Query Cost Analysis). Mỗi trường và mối quan hệ trong giản đồ được gán một trọng số. Một trường vô hướng đơn giản như name có thể tốn một điểm, trong khi yêu cầu một danh sách lồng nhau như posts(last: 100) có thể tốn mười điểm.

Trước khi thực thi truy vấn của bạn, máy chủ sẽ phân tích cú pháp, tính toán tổng chi phí của nó và từ chối nó kèm theo một lỗi như là "Max query complexity exceeded" nếu tổng chi phí vượt quá giới hạn đã định cấu hình trước—ví dụ: nếu 500 bí danh đẩy truy vấn vượt quá ngưỡng 1.000 điểm.

Các hệ thống bảo vệ cũng thực thi nghiêm ngặt các giới hạn về độ sâu lồng nhau của truy vấn. Nếu một công cụ thu thập dữ liệu cố gắng truy xuất một biểu đồ quan hệ đệ quy trong một yêu cầu—chẳng hạn như user → their friends → friends' posts → post comments—thì gần như chắc chắn nó sẽ chạm giới hạn độ sâu lồng nhau đã được cấu hình trước.

Cách xử lý vấn đề này: thay vì cố gắng tìm kích thước hoàn hảo cho một truy vấn sâu—ví dụ: chia nó thành các nhóm gồm 20–30 bí danh thay vì 500—thường tốt hơn là thiết kế lại công cụ thu thập dữ liệu theo chiến lược truy xuất phẳng.

1. Truy vấn phẳng. Bắt đầu với một truy vấn cấp cao gọn nhẹ chỉ truy xuất một danh sách phẳng các ID của các đối tượng được yêu cầu mà không có các mối quan hệ của chúng.

2. Phân đoạn và luồng xử lý (Chunking and workers). Chia các ID đã truy xuất thành các nhóm (phân đoạn) nhỏ, an toàn. Sau đó, sử dụng một nhóm công cụ (workers) để tìm nạp thông tin chi tiết cho các ID đó một cách song song.

3. Tái cấu trúc biểu đồ cục bộ. Hoàn thiện lại cấu trúc quan hệ ở phía công cụ thu thập dữ liệu. Lưu trữ dữ liệu cục bộ (hoặc trong cơ sở dữ liệu trung gian) và hợp nhất chúng bằng lập trình.

Cách tiếp cận này đòi hỏi thêm logic điều phối và lưu trữ cục bộ. Đổi lại, nó cung cấp khả năng thu thập dữ liệu đa luồng ổn định mà không kích hoạt các quy tắc WAF, lệnh cấm ngầm (shadow bans) hoặc thời gian chờ (timeout) của cơ sở dữ liệu trên nền tảng mục tiêu.

Kết luận

Thu thập dữ liệu từ các API GraphQL hiện đại đòi hỏi sự tương tác toàn diện với các hệ thống phân tán phức tạp, bao gồm các cân nhắc về lớp vận chuyển như giả lập TLS, cũng như sự hiểu biết về xử lý AST và các cơ chế lưu trữ bộ nhớ đệm phía máy chủ.

Các hệ thống bảo vệ tiếp tục phát triển, nhưng tính linh hoạt về mặt kiến trúc tạo nên sức hấp dẫn của GraphQL đối với các nhà phát triển cũng để lại nhiều cơ hội cho các hệ thống thu thập dữ liệu được thiết kế tốt.