Làm thế nào xấu là $ _REQUEST và một số biện pháp đối phó Band-Aid chấp nhận được là gì?

Question

Tôi đã xem qua một số câu trả lời phổ biến liên quan đến PHP gần đây đã đề xuất sử dụng superglobal $_REQUEST, mà tôi nghĩ là mùi mã, vì nó nhắc tôi về số register_globals.

Bạn có thể cung cấp giải thích/bằng chứng tốt về lý do tại sao $_REQUEST là thực tiễn không tốt? Tôi sẽ ném ra một vài ví dụ tôi đã đào lên, và sẽ yêu thích nhiều thông tin/quan điểm về cả các vector tấn công lý thuyết và khai thác thế giới thực, cũng như các đề xuất về các bước hợp lý mà sysadmin có thể thực hiện để giảm rủi ro (thiếu viết lại ứng dụng ... hoặc, chúng tôi cần để đi đến quản lý và yêu cầu viết lại không?).

Ví dụ lỗ hổng: Mặc định GPC mảng hợp nhất theo đơn đặt hàng có nghĩa là giá trị COOKIE ghi đè GET và POST, vì vậy $_REQUEST có thể được sử dụng cho công XSS và HTTP tấn công. PHP cho phép các vars cookie ghi đè lên các mảng superglobal. 10 trang trình bày đầu tiên của this talk đưa ra các ví dụ (toàn bộ bài nói chuyện tuyệt vời). phpMyAdmin exploit ví dụ về tấn công CSRF.

Ví dụ biện pháp đối phó: reconfigure $_REQUEST mảng merge-trật tự GPC-CGP để GET/POST ghi đè COOKIE, không phải là cách khác xung quanh. Sử dụng Suhosin để chặn ghi đè superglobals.

(Ngoài ra, sẽ không được hỏi nếu tôi nghĩ câu hỏi của tôi là một người bị mắc mưu, nhưng vui vẻ áp đảo SO câu trả lời cho "When and why should $_REQUEST be used instead of $_GET/$_POST/$_COOKIE?" là "Không bao giờ.")

Answer 1

nó dễ bị tổn thương đến bất cứ điều gì thông qua vào URL. Vì vậy, nếu một biểu mẫu có chứa một trường ẩn với "userid" đã được gửi với biểu mẫu, mặc dù trong lý thuyết người dùng không thể chỉnh sửa nó, không có gì ngăn cản họ thay đổi giá trị nếu đủ quan tâm.

Nếu bạn chỉ muốn giảm giá trị, bạn cần phải biết rằng nó có thể bị giả mạo, vì vậy bạn cần phải hành động phù hợp và chắc chắn không sử dụng nó cho giá trị/tham số an toàn dữ liệu.

Answer 2

Chỉ coi nó như: phương pháp lấy dữ liệu từ người dùng. Nó phải được khử trùng và xác nhận, vậy tại sao bạn nên quan tâm nếu nó đến dưới dạng POST, GET hoặc cookie? Tất cả họ đều đến từ người dùng, vì vậy hãy nói 'họ có thể bị giả mạo!' là thừa.

Answer 3

$ _REQUEST là một điều xấu như $ _GET, $ _POST và $ _COOKIE. Trong khi tôi nghĩ rằng có các kịch bản hợp lệ để sử dụng $ _REQUEST nhưng có một lý do chính đáng không sử dụng $ _REQUEST và gắn nhãn nó là "thực hành không tốt".

Lý do chính sử dụng $ _REQUEST là thông số đó có thể được chuyển trong $ _POST hoặc $ _GET. Bằng cách truy cập $ _REQUEST, bạn không phải kiểm tra cả $ _GET và $ _POST mà giá trị được đặt. Vấn đề là thiết lập ini gpc_order có thể thay đổi hành vi cách $ _REQUEST được xây dựng. Cài đặt này có thể khác nhau từ máy chủ đến máy chủ và tập lệnh của bạn có thể thay đổi hành vi.

Answer 4

$_REQUEST có vấn đề vì bỏ qua sự khác biệt giữa URL ($_GET) và yêu cầu nội dung ($_POST). Yêu cầu HTTP-GET sẽ không có tác dụng phụ, trong khi HTTP-POST có thể có các tác dụng phụ và do đó không thể lưu trữ được. Ném các nguồn dữ liệu hoàn toàn khác nhau này vào một nhóm, gọi các ứng dụng là un- REST -ful, nghĩa là các ứng dụng xấu.