HTTP 401 so với 403

401 Yêu cầu một Thử thách Xác thực

HTTP 401 cho biết một yêu cầu thiếu thông tin xác thực hợp lệ cho tài nguyên mục tiêu. Ngữ nghĩa xác thực và trạng thái HTTP yêu cầu máy chủ tạo ra phản hồi 401 phải bao gồm header WWW-Authenticate chứa một thử thách phù hợp. Cụm từ lịch sử Unauthorized không làm thay đổi ý nghĩa xác thực đó.

Việc thiếu thông tin xác thực, thông tin xác thực hết hạn, hoặc lược đồ xác thực không hợp lệ có thể dẫn đến 401, tùy theo dịch vụ. Hãy chẩn đoán lược đồ đã được tài liệu hóa trước khi thay đổi giá trị. Một khóa API hợp lệ gửi tới sai header có thể không dùng được dù bản thân khóa là đúng.

Đối với một dịch vụ bạn vận hành, hãy kiểm tra rằng phản hồi thực sự chứa thử thách và mô tả lỗi hữu ích, an toàn. Một mã trạng thái trơ trọi không có header như mong đợi có thể cho thấy phản hồi ứng dụng không tuân chuẩn hoặc một trung gian đã thay đổi thông điệp. Giữ cho phân biệt này rõ ràng trong ghi chú sự cố của bạn.

403 Thể hiện Sự Từ chối mà Không Chứng minh Đăng nhập

HTTP 403 có nghĩa là máy chủ đã hiểu yêu cầu và từ chối thực hiện nó. Lỗi quyền hạn là trường hợp phổ biến, nhưng mã trạng thái không xác nhận rằng xác thực đã thành công. Một yêu cầu ẩn danh có thể bị cấm bởi chính sách trước khi danh tính người dùng được thiết lập.

Ví dụ bao gồm một bên gọi thiếu quyền truy cập vào một dự án cụ thể, một yêu cầu bị từ chối bởi quy tắc ứng dụng hoặc một gateway từ chối yêu cầu. Mã trạng thái một mình không thể phân biệt chúng. Hãy xác định body phản hồi, các header liên quan và hệ thống đã tạo ra việc từ chối trước khi chọn hướng khắc phục.

Đừng mặc định gắn kèm một thông tin xác thực khác. Một số từ chối không liên quan đến thông tin xác thực, và việc chuyển tiếp thông tin xác thực không cần thiết có thể làm lộ bí mật tới sai điểm đích. Nếu bạn sở hữu dịch vụ, hãy dùng log nội bộ để xác định quy tắc đã được đánh giá trong khi vẫn giới hạn thông tin phản hồi lỗi công khai ở mức người gọi được phép nhận.

Lỗi Bearer-Token Bổ sung Ý nghĩa Cụ thể Hơn

Một API dùng bearer-token có thể cung cấp lỗi cụ thể hơn so với chỉ mã trạng thái. Các định nghĩa lỗi bearer-token phân biệt invalid_token với insufficient_scope và gắn chúng với hành vi phản hồi khác nhau. Các trường này giúp tách một token không dùng được khỏi một token thiếu scope yêu cầu.

Từ vựng đó áp dụng khi API dùng lược đồ bearer-token. Nó không nên được giả định cho một dịch vụ mong đợi khóa API thô trong một header khác. Hãy khớp diễn giải lỗi với bề mặt xác thực được tài liệu hóa, bao gồm việc phản hồi là một thử thách HTTP hay một khung ứng dụng JSON.

Trong một ví dụ giả định về xuất dự án, một token có thể nhận diện đúng ứng dụng nhưng thiếu quyền truy cập vào phần xuất. Hướng điều tra thích hợp là scope được cấp và chính sách tài nguyên. Thay token bằng một token khác có cùng quyền hạn sẽ dẫn tới cùng quyết định truy cập. Hãy ghi lại hành động và scope mong đợi cùng với chẩn đoán.

Lần theo Phản hồi Qua Mỗi Ranh Giới API

Một quy trình dữ liệu phân lớp có thể bao gồm một yêu cầu từ client đến nhà cung cấp và một yêu cầu từ nhà cung cấp đến mục tiêu. Phản hồi HTTP của nhà cung cấp và trạng thái được ghi nhận của mục tiêu có thể là những mảnh thông tin khác nhau. Một bên có thể mô tả việc nhà cung cấp có chấp nhận tác vụ hay không; bên kia có thể mô tả những gì đã xảy ra tại điểm đích.

Hãy đọc phong bì phản hồi được nhà cung cấp ghi rõ trước khi diễn giải một con số trong phần nội dung là trạng thái truyền tải. Ghi lại trạng thái bên ngoài, mã lỗi, thông báo và chi tiết mục tiêu khi các trường đó có sẵn. Ẩn thông tin xác thực và thông tin cá nhân trước khi chia sẻ bản ghi.

Ngoài ra, hãy xác định các gateway và reverse proxy trong những hệ thống bạn kiểm soát. Một gateway có thể từ chối yêu cầu trước khi ứng dụng nhận được nó. Khi đó, log của ứng dụng có thể không chứa yêu cầu tương ứng nào, đây là bằng chứng về ranh giới chứ không phải bằng chứng rằng client chưa từng gửi gì. Sử dụng một mã định danh tương quan xuyên suốt các thành phần được hỗ trợ để thu hẹp nguồn gốc.

Đối Với Chủ Sở Hữu Dịch Vụ, Hãy Kiểm tra Quyết định Truy cập Tài nguyên

Chủ sở hữu dịch vụ nên kiểm tra xem các bước kiểm tra quyền truy cập có được áp dụng cho tài nguyên và hành động được yêu cầu hay không. Các khuyến nghị ủy quyền của OWASP nhấn mạnh nguyên tắc đặc quyền tối thiểu và việc xác thực trên mọi yêu cầu. Một danh tính hợp lệ không loại bỏ nhu cầu đánh giá quyền truy cập ở cấp độ đối tượng.

Hãy kiểm tra một người dùng có quyền truy cập vào một dự án đối với mã định danh của một dự án khác. Kiểm tra quyền đọc và chỉnh sửa tách biệt. Kiểm tra cả các tuyến xuất nền cũng như các endpoint tương tác. Một yêu cầu thành công qua một tuyến không được vô tình có thêm quyền rộng hơn thông qua một tuyến khác cùng phơi bày dữ liệu đó.

Lựa chọn chi tiết phản hồi một cách có chủ đích. Một số hệ thống dùng phản hồi không tìm thấy để tránh tiết lộ sự tồn tại của tài nguyên cho người gọi không có quyền truy cập. Ghi rõ hành vi đó cho client và giữ lại lý do nội bộ cho những người vận hành được ủy quyền. Đừng làm chẩn đoán thuận tiện hơn bằng cách để lộ tên tài nguyên hoặc chi tiết chính sách cho người gọi không được phép.

Chẩn đoán Phản hồi của Scrapeless và Mục tiêu Một Cách Tách Biệt

Một yêu cầu đến Scrapeless Web Unlocker có ranh giới xác thực riêng trước khi bất kỳ kết quả mục tiêu nào được diễn giải. Hiện tại, hướng dẫn khóa API Scrapeless quy định phương thức thông tin xác thực cho bề mặt API tương ứng. Hãy xác nhận ranh giới đó trước bằng cách sử dụng hành vi được ghi rõ và dữ liệu chẩn đoán đã được ẩn.

Nếu nền tảng chấp nhận yêu cầu, hãy kiểm tra thông tin mục tiêu thu được một cách tách biệt. Việc thu thập được quản lý không đồng nghĩa với việc được ủy quyền truy cập vào tài nguyên điểm đến riêng tư. Một từ chối truy cập nên được xem là tín hiệu để kiểm tra phạm vi và yêu cầu, chứ không phải là quyền được truy cập dữ liệu ngoài ranh giới tập dữ liệu dự kiến.

Quy trình chẩn đoán phản hồi 403 cung cấp bối cảnh liên quan để xác định vị trí chỗ từ chối. Sử dụng bảng giá Scrapeless hiện hành cho việc lập kế hoạch sản phẩm, đồng thời giữ cho việc tính phí, khả dụng sản phẩm, kiểm tra hợp lệ yêu cầu và ủy quyền mục tiêu tách biệt trong phân loại lỗi của bạn.

Xây Dựng Bản Ghi Chẩn Đoán Dẫn Đến Một Hành Động Cụ Thể

Một bản ghi chẩn đoán hữu ích bao gồm điểm đến của yêu cầu, phương thức, sơ đồ thông tin xác thực đã được ẩn, trạng thái bên ngoài, header thách thức nếu có, và các trường lỗi liên quan. Thêm tài nguyên và hành động đang được điều tra bằng các mã định danh có thể được chia sẻ an toàn. Giữ lại ID tương quan nếu dịch vụ cung cấp.

Đối với 401, hãy kiểm tra sơ đồ dự kiến, cách tải bí mật, tính hợp lệ và đối tượng hoặc điểm đến khi phù hợp. Đối với 403, hãy xác định thành phần sinh ra phản hồi và kiểm tra chính sách tài nguyên hoặc giới hạn được ghi rõ. Nếu dịch vụ không tuân theo các quy ước chuẩn, hãy ghi lại hành vi quan sát được và tài liệu riêng của nó thay vì cố gò phản hồi vào một lời giải thích mang tính giáo trình.

Dừng lại khi bằng chứng cho thấy đó là một sự từ chối có chủ ý. Kết quả đúng có thể là một yêu cầu cấp quyền theo phạm vi, một chỉnh sửa cấu hình, hoặc loại bỏ một tác vụ ngoài phạm vi. Một chẩn đoán thành công là một quyết định truy cập được giải thích rõ, chứ không nhất thiết là một yêu cầu thành công. Giữ rõ ràng sự khác biệt đó trong báo cáo vận hành.

Kết luận

HTTP 401 và 403 trở nên hữu ích khi bạn lần theo phản hồi đến đúng thành phần tạo ra nó. Hãy dùng thách thức 401 để điều tra xác thực, và dùng 403 như bằng chứng về sự từ chối mà nguyên nhân vẫn cần được làm rõ theo bối cảnh. Giữ tách biệt kết quả của nhà cung cấp và mục tiêu, ẩn thông tin xác thực, và làm cho hành động tiếp theo phù hợp với quyết định truy cập cụ thể.

Tài liệu tham khảo

• Mô hình truy xuất Web Unlocker
• Scrapeless Web Unlocker
• Chẩn đoán phản hồi bị cấm