PerimeterX là gì?

Scrapeless Scraping Browser chạy các phiên trình duyệt quản lý cho các quy trình công việc dữ liệu công khai phụ thuộc vào việc thực thi trình duyệt và trạng thái điều hướng.

PerimeterX là một công ty an ninh web nổi tiếng với bảo vệ chống bot và lạm dụng tài khoản đã sáp nhập với HUMAN Security vào năm 2022. Trong các cuộc thảo luận quản lý bot hiện tại, sản phẩm liên quan là HUMAN Bot Defender. Tên PerimeterX vẫn xuất hiện trong các bài viết cũ và các định danh tích hợp, vì vậy hiểu lịch sử đặt tên sẽ giúp bạn tìm tài liệu phù hợp.

Đối với một nhà phát triển scraping, câu hỏi hữu ích không chỉ đơn giản là liệu một trang web có “sử dụng PerimeterX” hay không. Xác định điều gì mà khách hàng của bạn nhận được, liệu quy trình công việc được yêu cầu có được phép hay không, và hành vi của trình duyệt hoặc ứng dụng nào mà trang công khai yêu cầu. Chỉ một tên sản phẩm không tiết lộ chính sách đã được cấu hình của một trang.

Chuyện gì đã xảy ra với PerimeterX?

PerimeterX và HUMAN Security đã hợp nhất trong một thông báo sáp nhập vào năm 2022. Đó thông báo sáp nhập giữa HUMAN và PerimeterX thiết lập mối quan hệ giữa tên cũ và tổ chức hiện tại.

Khi điều tra một tích hợp, hãy tìm kiếm tài liệu HUMAN hiện tại cũng như định danh PerimeterX lịch sử. Tên gói, nhãn cấu hình, và ghi chú hoạt động có thể giữ lại thuật ngữ cũ sau khi một công ty thay đổi việc trình bày sản phẩm của mình. Đó sự liên tục đặt tên không phải là bằng chứng rằng một tích hợp đã lỗi thời hoặc rằng mọi tính năng hiện tại đều tồn tại trong sản phẩm cũ.

Hãy cụ thể trong một báo cáo sự cố. “Một trang đã trả lại một thách thức mang thương hiệu HUMAN” là một quan sát. “Toàn bộ chuỗi phát hiện PerimeterX đã từ chối dấu vân tay TLS của chúng tôi” là một tuyên bố mạnh mẽ hơn nhiều, yêu cầu bằng chứng rằng một trang lỗi hiển thị thường không cung cấp.

HUMAN Bot Defender đánh giá các yêu cầu như thế nào

HUMAN Bot Defender kết hợp các quan sát phía khách hàng với các thành phần phát hiện và thực thi. Nó Mô hình phát hiện Bot Defender mô tả một Cảm biến, một Bộ phát hiện, và một Người thực thi, với một đánh giá rủi ro theo yêu cầu được sử dụng trong việc xử lý lưu lượng.

Cảm biến thu thập các quan sát của khách hàng, Bộ phát hiện đánh giá hoạt động, và Người thực thi áp dụng kết quả trong tích hợp đã triển khai. Sự tách biệt đó là quan trọng vì triệu chứng trình duyệt hiển thị có thể phát sinh ở một giai đoạn khác với quyết định chính sách cuối cùng. Một vấn đề tải kịch bản và một từ chối có chủ ý không nên được báo cáo là cùng một sự cố.

Đối với chủ sở hữu, hãy sử dụng sản phẩm đã cấu hình và bằng chứng sự kiện để xác định giai đoạn đang thất bại. Đối với người truy cập, hãy mô tả những gì có thể quan sát được: liệu trang có tải không, liệu một màn hình tương tác có xuất hiện không, và liệu nội dung mong đợi có được cung cấp không. Đừng tưởng tượng một điểm số nội bộ hoặc tuyên bố giải mã một giá trị bảo mật mờ.

Tại sao quy trình làm việc dựa trên cảm biến khác với một fetch đơn giản

Một trình duyệt có thể thực thi các kịch bản và duy trì trạng thái cần thiết cho một trang tương tác, trong khi một fetch HTTP cơ bản không tái hiện toàn bộ vòng đời của trình duyệt. Sự khác biệt đó có thể ảnh hưởng đến cả hành vi ứng dụng và xác thực lưu lượng.

Đối với tự động hóa được ủy quyền, trước tiên hãy quyết định liệu đích thực sự cần một trình duyệt hay không. Một số tài nguyên công khai trả lại dữ liệu của họ trực tiếp; những tài nguyên khác tập hợp nội dung sau khi tải tài liệu. Chọn thời gian chạy dựa trên hợp đồng trang quan sát được thay vì trên một giả định chung rằng mọi trang được bảo vệ đều cần một cách xử lý giống nhau.

Khi một trình duyệt là cần thiết, hãy bảo tồn thứ tự điều hướng được phép. Một lựa chọn vị trí hoặc tương tác đồng ý có thể thay đổi trang trở nên có sẵn. Giữ ngữ cảnh đã chọn gắn với dữ liệu được trích xuất để một nhà phân tích sau này hiểu được những gì đã được quan sát.

Trạng thái không ngụ ý quyền truy cập không giới hạn. Cơ chế cookie HTTP chuyển thông tin giữa các yêu cầu, nhưng ý nghĩa và quyền hạn liên quan đến trạng thái đó là cụ thể cho ứng dụng. Đừng tái sử dụng cookie của người khác hoặc coi cookie bảo mật là một thông tin xác thực API đã được tài liệu hóa.

Điều tra một khối PerimeterX bị nghi ngờ

Một khối PerimeterX hoặc HUMAN bị nghi ngờ nên được điều tra từ đại diện được trả về và quy trình làm việc được phép. Bắt đầu với bằng chứng phân biệt phản ứng bảo mật với trạng thái ứng dụng thông thường.

1. Ghi lại URL công khai được yêu cầu, URL cuối cùng, trạng thái phản hồi và tiêu đề trang.
2. Xác định bất kỳ văn bản thách thức hoặc từ chối rõ ràng nào và giữ lại mã nhận diện tham chiếu hiện thấy.
3. Xác nhận rằng trình duyệt so sánh có quyền truy cập giống như người thu thập.
4. Kiểm tra xem có cần các bước điều hướng trang công khai và kịch bản cho nội dung hay không.
5. Đo lường khối lượng công việc tổng hợp thay vì xem xét một công nhân riêng lẻ.
6. Dừng lại tại một sự từ chối chính sách và hỏi chủ sở hữu trang web về lộ trình thu thập được phê duyệt.

Hãy tưởng tượng một trang thông tin vé công khai hiển thị chi tiết sự kiện nhưng đặt việc mua lại sau một quy trình riêng biệt. Một công việc thu thập chỉ đọc nên dừng lại ở ranh giới thông tin công khai. Thực tế là cả hai trang chia sẻ một miền không làm cho các hoạt động đặt chỗ hoặc mua hàng trở thành một nhiệm vụ được phép.

Đối với ví dụ về danh mục, hãy kiểm tra rằng kết quả trống thực sự là một danh mục trống. Nếu tài liệu chứa một thách thức thay vào đó, hãy ghi lại một sự cố thu thập. Điều này ngăn phản ứng bảo mật trở thành một tuyên bố sai lệch về tính khả dụng của sản phẩm.

Những gì Chủ Sở Hữu Trang Web Nên Kiểm Tra Trong Khi Thay Đổi Tích Hợp

Các chủ sở hữu trang web nên kiểm tra các quy trình ứng dụng hợp pháp bất cứ khi nào họ thay đổi tích hợp trình duyệt, định tuyến yêu cầu, hoặc chính sách thực thi. Một tích hợp bảo mật phải đồng thời tồn tại với hành vi tải và điều hướng thực tế của trang web.

Xây dựng một bộ hành trình được phê duyệt đại diện nhỏ: một chuyến thăm đầu tiên đến một trang công khai, điều hướng đến một trang chi tiết, thay đổi vị trí nếu cần, và một yêu cầu giám sát được phê duyệt. Ghi lại nội dung dự kiến và kết quả bảo mật cho từng cái. Mục đích là xác minh hành vi dự kiến, không phải tạo ra một dấu vân tay phổ quát mà tất cả các khách hàng nên bắt chước.

Khi một tích hợp hợp pháp bị ảnh hưởng, hãy xem xét danh tính và phạm vi của nó. Một ngoại lệ rộng cho tất cả lưu lượng chia sẻ một địa chỉ có thể bao gồm những người dùng không liên quan. Thích một thỏa thuận tích hợp được tài liệu rõ ràng và một ngoại lệ có thể được kiểm tra và đảo ngược.

Bao gồm cả sự tiếp cận và sự khác biệt trình duyệt thông thường trong việc xem xét. Đừng giả định rằng mọi du khách đều thực hiện cùng một chuyển động chỉ dẫn hoặc chuỗi tương tác. Một sự cố tương thích nên được đánh giá dựa trên việc sử dụng được hỗ trợ của ứng dụng, chứ không phải một bức tranh hẹp về những gì một lần truy cập của con người phải trông như thế nào.

Bảo Vệ Bot Đang Cố Gắng Ngăn Chặn Điều Gì

Bảo vệ bot giải quyết các hoạt động tự động có thể gây hại cho tính khả dụng của ứng dụng, tài khoản, hoặc quy trình kinh doanh. Các thể loại đe dọa tự động của OWASP phân biệt các mục tiêu như lạm dụng tài khoản và lạm dụng chức năng ứng dụng.

Đó là lý do tại sao “tự động” và “ác ý” không nên được dùng thay thế cho nhau. Một chủ sở hữu có thể chào đón một bộ thu thập tìm kiếm đã được xác minh và chấp thuận một giám sát đối tác trong khi từ chối một người thu thập không liên quan. Mục đích, quyền lợi, và mẫu yêu cầu đều quan trọng đối với thỏa thuận truy cập.

Trước khi thu thập, hãy tài liệu nguồn, các trường, mục đích kinh doanh, và yêu cầu lưu giữ. Giữ dữ liệu cá nhân ra khỏi các bản ghi chẩn đoán khi không cần thiết. Nếu điều kiện truy cập thay đổi, hãy tạm dừng việc thu thập bị ảnh hưởng và xem xét phạm vi thay vì coi thỏa thuận ban đầu là vĩnh viễn.

Nơi Trình Duyệt Thu Scrapeless Hữu Ích

Trình Duyệt Thu Scrapeless hữu ích cho các trang công khai được ủy quyền cần một môi trường runtime trình duyệt được quản lý. Nó cung cấp thực thi trình duyệt trong khi ứng dụng của bạn vẫn chịu trách nhiệm cho phạm vi thu thập và xác thực dữ liệu được trả về.

Bắt đầu với tài liệu Trình Duyệt Thu Scrapeless và chỉ chọn các tính năng mà quy trình làm việc của bạn cần. Giữ các bước điều hướng liên quan trong một bối cảnh nhất quán, xem xét trang kết quả, và từ chối các màn hình từ chối khỏi đường dẫn dữ liệu bình thường. Dịch vụ trình duyệt không thay đổi chính sách HUMAN Bot Defender trên một trang web bên thứ ba.

Cuộc thảo luận liên quan về thu thập trang công khai của HUMAN và PerimeterX cung cấp bối cảnh về lý do tại sao danh tính khách hàng có nhiều chiều quan sát. Nó không nên được đọc như bằng chứng rằng mỗi chiều xác định mọi quyết định bảo mật của HUMAN.

So sánh giá cả Scrapeless với khối lượng công việc mà điểm đến cho phép. Đối với một tập dữ liệu công khai nhỏ, sự rõ ràng trong hoạt động có thể quan trọng hơn sự song song tối đa. Giữ điều kiện dừng của người thu thập và hồ sơ chứng cứ có thể hiểu được đối với nhóm chịu trách nhiệm về quyền truy cập.

Kết luận

PerimeterX là một phần của lịch sử phía sau các sản phẩm bảo vệ bot hiện tại của HUMAN. Sử dụng tài liệu sản phẩm hiện tại, phân biệt phản hồi quan sát được khỏi logic phát hiện suy diễn, và giữ tự động hóa trong phạm vi được phê duyệt. Một người thu thập được thiết kế tốt xác thực trang mà nó nhận được và ghi lại các sự cố truy cập mà không biến chúng thành sự thật kinh doanh sai lệch.