2011-02-06 30 views
8

Hmm Tôi thực sự không thể phân biệt bất kỳ sự bất an nào nhưng đã tự hỏi liệu bạn có thể, nếu vậy làm thế nào để có thể vá/sửa đổi?Chuyển hướng PHP này có an toàn không?

Heres mã:

header("Location: http://example.com/search/{$_POST['term']}/{$_POST['type']}"); 

Các trang web mà tôi đang chuyển hướng quá không xác nhận & sanitization về phía họ, nhưng những gì tôi quan tâm là - không an toàn chuyển hướng này dưới mọi hình thức (trên mặt của tôi - nhìn thấy khi tôi đang sử dụng trực tiếp $_POST 's).

Đánh giá cao tất cả trợ giúp.

PS: Chỉ trở nên tò mò vì tôi luôn nghĩ rằng việc sử dụng dữ liệu nhập của người dùng không được đánh giá là nguy hiểm (hoặc ít nhất là áp dụng cho XSS và SQLi).

+0

Được xem trong sự cô lập không có vấn đề bảo mật nào tôi có thể thấy với điều này. Giả sử bạn sở hữu tên miền A và đang chuyển hướng người dùng đến miền B mà bạn không kiểm soát, chính điều này sẽ không gây ra vấn đề gì. –

+0

An toàn hơn là xin lỗi: 'urlencode()' không phải là nhiều để gõ. – mario

Trả lời

7

Nhìn chung, đối với hầu hết các trang web đang chạy phiên bản PHP hiện đại, là an toàn.

Có hai vấn đề ở bàn tay:

  • Một người sử dụng độc hại có thể đánh lừa nạn nhân vào vô tình ghé thăm bất kỳ trang của mẫu đơn /search/*/* trên trang web bằng cách liên kết chúng vào một trang độc hại mà POSTS đến trang với chuyển hướng của bạn. (Lưu ý rằng chúng không chỉ giới hạn ở hai dấu gạch chéo sau /search vì biến POST của chúng có thể chứa dấu gạch chéo.) Điều này tương tự như việc trao cho ai đó một URL bit ngắn được rút ngắn để chuyển hướng chúng, vì vậy nó không quá tệ.
  • HTTP response splitting. Nếu người dùng độc hại bao gồm dòng mới (cụ thể là CRLF/\r\n) trong dữ liệu POST của họ, họ có thể thực hiện cuộc gọi header() để xuất nhiều tiêu đề, bao gồm tiêu đề để đặt cookie, v.v. Tuy nhiên, kể từ PHP 5.1.2 this has been fixed.
+0

Cảm ơn !, đã học được điều này. – newbtophp

0

Có, nó khá không an toàn. Người ta KHÔNG BAO GIỜ BAO GIỜ nên đặt đầu vào người dùng không được kiểm soát vào một tập lệnh. Tôi khuyên bạn nên tối thiểu tối thiểu, sử dụng filter_input_array để khử trùng mảng $ _POST của bạn trước khi thực hiện bất kỳ điều gì với nó.

+0

Bạn có thể làm rõ? Vấn đề bảo mật nào có thể phát sinh? –

+0

Đó là một lỗ hổng XSS brute-force trên URL đích. Tôi biết có vẻ như không có vấn đề gì ở đây, nhưng tôi đã theo dõi các lập trình viên của whitehat có quyền truy cập root vào máy chủ của khách hàng của tôi thông qua các URL được xây dựng cho phép đầu vào người dùng không được kiểm tra trong quá trình xây dựng của họ. –

+0

@Brian bạn có thể lập phương sai không? và filter_input_array có nhiều bộ lọc - vì vậy, tôi hơi bối rối về các bộ lọc thích hợp (do sự hiểu biết của tôi về những lỗ hổng chính xác là gì). – newbtophp

0

Hy vọng rằng tầng web nhận URL được chuyển hướng từ ứng dụng khách sẽ thực hiện xác thực trên toàn bộ URL, vì vậy bạn có thể an toàn. Nhưng nó sẽ không làm tổn thương để chạy hai lĩnh vực thông qua xác nhận đơn giản trước khi gửi chuyển hướng.

2

Đây không phải là vấn đề bảo mật, nhưng có lẽ bạn nên mã hóa URL các đối số này bằng urlencode($_POST['term']).

+0

Đây là một sửa chữa tốt. Tôi có thể sử dụng ['rawurlencode'] (http://www.php.net/manual/en/function.rawurlencode.php) mà rõ ràng là" để bảo vệ các ký tự chữ được hiểu là các dấu phân tách URL đặc biệt. " – ide

+0

Cảm ơn thông tin !. – newbtophp

-1

Tôi nghĩ bạn sẽ tìm thấy điều này là read đáng giá.

+0

Đây là câu trả lời chỉ dành cho liên kết và liên kết đã chết ngay bây giờ. Kiểm tra các phiên bản lưu trữ cho thấy rằng nó đã không thực sự nói về vấn đề này cụ thể anyway, theo như tôi có thể nhìn thấy. –

Các vấn đề liên quan