2009-03-12 13 views
10

Có lẽ tôi đang hoang tưởng một chút, nhưng khi tôi viết lại một mô-đun liên lạc, câu hỏi sau đây được lưu ý:Chức năng gốc của php an toàn khi sử dụng với đầu vào chưa được lọc là gì?

Tôi có thể sử dụng đầu vào chưa được lọc trong các chức năng gốc của php không?

Nó rất dễ dàng để khử trùng công cụ để đưa vào một cơ sở dữ liệu, xuất ra màn hình, vv nhưng tôi đã tự hỏi nếu ví dụ như các tuyên bố sau có thể là nguy hiểm:

if (file_exists($_POST['brochure'])) { 
     // do some stuff 
    } 

Nếu ai đó bằng cách nào đó quản lý để gửi đến trang đó, mã trên có thể được khai thác không?

Đoạn mã trên chỉ là một ví dụ, tôi có thể nghĩ đến các chức năng khác mà tôi sử dụng khi xử lý biểu mẫu.

Chỉnh sửa: Cảm ơn tất cả mọi người, file_exists trong ví dụ này thực sự là một phần của chức năng vệ sinh nhưng khi dọn dẹp, chức năng php đang được sử dụng để nhanh chóng trở thành câu chuyện về gà và trứng: Để sử dụng chức năng, tôi có để làm sạch, nhưng để làm sạch tôi phải sử dụng chức năng.

Dù sao, tôi đã có một số ý tưởng mới ngay bây giờ.

Trả lời

12

Đúng. Tất cả những gì tôi phải làm là đăng "/ etc/passwd" hoặc "include/dbconnection.php" (hoặc bất kỳ thứ gì) vào trang của bạn và tùy thuộc vào những gì //do some stuff thực sự là, tôi có thể xóa, sửa đổi hoặc đọc thông tin nhạy cảm . Chức năng file_exists sẽ không làm bất cứ điều gì bạn không mong đợi, nhưng bạn có thể mong đợi những người dùng độc hại khai thác logic của bạn.

Luôn luôn khử trùng đầu vào của người dùng. Luôn. Nếu bạn đang mong đợi chỉ lấy các tệp từ một thư mục cụ thể, không cho phép .. hoặc/trong đầu vào

4

có thể 'brochure' = '../../../../.htaccess'

đó là một câu hỏi thú vị.

Apache trên máy tính của tôi được đặt để từ chối liệt kê hoặc xem các tệp .ht * và .ini và .php.inc, nhưng giờ đây bạn đã lo lắng cho tôi.

+0

php có quyền truy cập vào nhiều tệp hơn apache. Dừng apache hiển thị các tập tin .ht * và .ini sẽ không ngăn php đọc chúng. – Marius

+0

@Marius điều này rất đúng. – UnkwnTech

+0

điểm tuyệt vời. Tôi đang học những điều gây sốc ở đây :) – m42

6

Nội trang của PHP sẽ không làm những điều "bất ngờ" trên đầu vào kém (ví dụ: file_exists("foo; rm -r /") sẽ nói "không, tệp 'foo; rm -r /' không tồn tại") ... Và nếu có, đó là lỗi bạn có thể gửi cho Zend.

Tất nhiên, này không dừng người từ khai thác mã của bạn (ví dụ, file_exists("../hidden/shell.php")), vì vậy bạn nên vẫn (trên thực tế, bạn nên luôn) cẩn thận khi đi qua đầu vào người dùng cung cấp xung quanh.

8

Tự nó có vẻ an toàn, nhưng có thể được sử dụng để tiết lộ thông tin. Nó có thể cho phép một cuộc tấn công kiểm tra sự hiện diện (hoặc vắng mặt) của các tệp cụ thể (ví dụ: /etc/passwd, /proc/*, v.v.).

Vì vậy, trong ví dụ này, bạn phải đảm bảo rằng $_POST['brochure'] được vệ sinh trước để chỉ chấp nhận các yếu tố đầu vào khớp với tên tệp hợp lệ tiềm năng. Thả bất kỳ đầu vào nào có chứa .. hoặc bắt đầu bằng số /.

chức năng khác có thể có tác dụng phụ có khả năng tồi tệ hơn nhiều ...

+0

Phương pháp giữ danh sách tên tệp hợp lệ của bạn luôn là hiện tại? băm/mảng được cập nhật theo cách thủ công của tất cả các khả năng mà bạn kiểm tra? nếu không phải $ brochure nằm trong $ directoryHash? – m42

+0

không cần danh sách, thường chỉ là một regexp lọc ra những cách rõ ràng mà kẻ tấn công có thể truy cập vào một số tệp nằm ngoài thư mục chứa tệp được lưu trữ. – Alnitak

2

Bạn thực sự phải ở trong thói quen lọc tất cả các đầu vào, nhưng bạn có thể muốn kiểm tra http://www.hardened-php.net/ mà phân phối một bản vá cứng và 'Suhosin', trong nhiều bản phân phối nhị phân theo mặc định (OpenSUSE, Mandriva và Debian/Ubuntu)

+0

Cảm ơn, tôi đã cài đặt bản vá đó. – jeroen

2

Thực tế là bạn phải hỏi là câu trả lời của bạn. Nó không an toàn.

file_exists() không tệ như những người khác, nhưng nếu bạn không thấy mã nguồn cho hàm bạn đang chuyển dữ liệu đến và biết cách xử lý dữ liệu nhập của người dùng thì bạn sẽ có cơ hội.

Không nên chuyển dữ liệu người dùng chưa được lọc vào bất kỳ lệnh hệ thống tệp php nào. Chìa khóa với bảo mật là bạn không bao giờ cho phép đầu vào chuyển đổi ngữ cảnh. Trong trường hợp này, vệ sinh tối thiểu của bạn nên loại bỏ các ký tự đường dẫn.

Luôn giả sử một người dùng thù địch và điều tồi tệ nhất họ có thể làm nếu họ thấy mã nguồn của bạn.

0

Trong nhiều năm, các lỗ hổng bảo mật đã được tìm thấy trong nguồn của PHP, như vậy các hàm đó có thể chịu được các cuộc tấn công kiểu bộ đệm (bufferoverflow) Suhosin là/dự án vá PHP để loại bỏ một số rủi ro.

-1

Điều gì xảy ra với chuỗi cơ sở dữ liệu là nó có thể được truy xuất và sử dụng ở đâu đó có lỗ hổng bảo mật. Đối với câu trả lời cho câu hỏi của bạn, hãy suy nghĩ về việc xóa bước mà bạn lưu trữ chuỗi và sau đó truy xuất nó. Bạn sử dụng nó ngay lập tức, và bạn có những rủi ro tương tự.

+0

Cảm ơn, nhưng tôi e rằng tôi không có một đầu mối về những gì bạn đang nói đến. Ý anh là gì? – jeroen

+0

Ý của tôi là sử dụng đầu vào người dùng chưa được lọc luôn được coi là nguy hiểm trong php. Nó chỉ là quá dễ dàng cho một ai đó để chèn cái gì đó là một khai thác. Bạn dường như đã quen thuộc với điều này liên quan đến cơ sở dữ liệu; Tôi đã chỉ ra rằng vấn đề không phải là trong đó, nhưng với chính người dùng nhập vào. – gbarry

0

Tôi hoàn toàn không tin vào các chức năng đó.

Điều này hoàn toàn có thể nổi bật, tuy nhiên khi tôi theo dõi sát người và chất lượng mã C của họ trong các cam kết, chuyển đổi, v.v ... trong tám năm qua, tôi chỉ lo sợ liên tục.

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