Thiết lập PHP phổ biến không an toàn?

Tôi làm việc với quản trị hệ thống tại một trường đại học và tình cờ phát hiện ra điều gì đó có lẽ phổ biến, nhưng lại gây sốc cho tôi.

Tất cả các thư mục và khu vực web chung_html được lưu trữ trên afs, với quyền đọc cho các máy chủ web. Vì người dùng được phép có các tập lệnh php trong public_html, điều này có nghĩa là họ có thể truy cập các tệp của nhau từ bên trong php (và các tệp web chính!).

Điều này không chỉ khiến cho bất kỳ bảo vệ mật khẩu .htaccess nào hoàn toàn vô dụng, nó còn cho phép người dùng đọc các tệp nguồn php chứa mật khẩu cơ sở dữ liệu mysql và thông tin nhạy cảm tương tự. Hoặc nếu họ thấy rằng những người khác có thư mục mà máy chủ web có quyền truy cập ghi (ví dụ: đối với nhật ký cá nhân hoặc để lưu dữ liệu biểu mẫu đã gửi), họ có thể lưu trữ tệp trong các tài khoản đó.

Một ví dụ đơn giản:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

đây là một vấn đề phổ biến phải không? Và làm thế nào để bạn thường giải quyết nó?

CẬP NHẬT:

Cảm ơn các đầu vào. Thật không may, dường như không có câu trả lời đơn giản. Trong một môi trường chia sẻ lớn như thế này, người dùng có lẽ không nên có nhiều sự lựa chọn này. Cách tiếp cận tốt nhất tôi có thể nghĩ đến là đặt "open_basingir" trong cấu hình chính cho tất cả các thư mục "public_html", chạy suphp và chỉ cho phép dọn dẹp php (không có tập lệnh cgi, chạy các lệnh bên ngoài với backticks, v.v.).

Thay đổi chính sách như thế này sẽ phá vỡ rất nhiều thứ, và hoàn toàn có thể khiến người dùng chộp lấy cây chĩa của họ và đuổi theo chúng tôi ... Tôi sẽ thảo luận với các đồng nghiệp của mình và cập nhật ở đây nếu chúng tôi đưa ra quyết định về cách thay đổi thiết lập.

Người ta có thể sử dụng suphp chạy tập lệnh php với uid của chủ sở hữu.

http://www.suphp.org

Đề xuất của tôi sẽ là giới hạn quyền truy cập của PHP vào các tệp (thông qua open_basedir& các chỉ thị tương tự, trên cơ sở mỗi vhost): Bạn muốn người dùng có thể mở / đọc / ghi tệp dưới webroot của họ và có thể cao hơn một cấp không gian), nhưng không phải là một thư mục nơi họ sẽ lưu trữ, ví dụ như htpasswdcác tệp.

Một cấu trúc thư mục như:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Sẽ đáp ứng yêu cầu này: open_basedircó thể được chỉ vào /Client/sitemột cách an toàn và htpasswdcác tệp được lưu trữ trong /Client/auth(với .htaccesscác tệp hoặc httpd.confđược sửa đổi để trỏ đến vị trí thích hợp thay thế).
Điều này ngăn khách hàng của bạn mở tệp của bất kỳ ai khác, VÀ vì lợi ích người dùng độc hại không thể đọc nội dung trong /Client/auth(hoặc bất kỳ thứ gì khác trên hệ thống của bạn, như /etc/passwd:-)

Xem http://php.net/manual/en/ini.core.php để biết thêm chi tiết về triển khai open_basingir & per-vhost.

Không, đó không phải là vấn đề phổ biến vì hầu hết các máy chủ được chia sẻ sẽ xác định cấu hình open_basingir trong tệp htaccess trong thư mục chung_html của mỗi người dùng (hoặc trong vhost nếu mỗi người dùng có vhost riêng).

ví dụ: tệp .htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Nhưng hãy đảm bảo rằng bạn đã đặt quyền phù hợp trên tệp .htaccess để ngăn người dùng thay đổi open_basingir (nếu họ cố gắng ghi đè nó trong subir / .htaccess, nó không nên hoạt động - nhưng có lẽ bạn nên kiểm tra điều này để đảm bảo) .

HTH

C.

AFS bỏ qua các quyền người dùng unix đơn giản. suPHP thực thi một setuid trước khi chạy chương trình php, nhưng điều đó không cung cấp cho quá trình các mã thông báo kerberos cần thiết để truy cập AFS và bị hạn chế quyền của nó. suPHP sẽ phải được sửa đổi theo một cách nào đó để có được các mã thông báo đó trước khi nó có thể tự hiển thị cho hệ thống AFS với tư cách là người dùng đó. Theo tôi biết, điều đó đã không được thực hiện. (Trên thực tế, tôi đã tìm thấy câu hỏi này khi tìm kiếm xem có ai khác đã làm như vậy không.)