Tôi nên có những lo ngại về bảo mật nào khi cài đặt FS_METHOD thành trực tiếp trực tiếp trên Wp-config?

Gần đây tôi đã gặp sự cố khi không thể cài đặt plugin WP Smush Pro vì tôi không có sẵn tùy chọn Cài đặt thủ công hoặc Cài đặt một lần nhấp.

Tôi đã xem qua bài đăng này đề nghị điều chỉnh các cài đặt trong wp-config.php. Tôi đã thêm các cài đặt được đề xuất, tuy nhiên cài đặt có vẻ quan trọng nhất là:

define('FS_METHOD', 'direct');

Những gì tôi muốn biết là những mối quan tâm thực sự tôi nên có xung quanh FS_METHODđể thiết lập direct? Có sự thay thế nào khác để cài đặt plugin không?

Đây là những gì tài liệu chính thức nói:

FS_METHOD buộc phương thức hệ thống tập tin. Nó chỉ nên là "trực tiếp", "ssh2", "ftpext" hoặc "ftpsockets". Nói chung, bạn chỉ nên thay đổi điều này nếu bạn đang gặp vấn đề cập nhật. Nếu bạn thay đổi nó và nó không có ích, hãy thay đổi lại / xóa nó đi. Trong hầu hết các trường hợp, đặt nó thành 'ftpsockets' sẽ hoạt động nếu phương thức được chọn tự động không có.

(Ưu tiên chính) "trực tiếp" buộc nó sử dụng các yêu cầu I / O tệp trực tiếp từ bên trong PHP, điều này gây khó khăn cho việc mở các vấn đề bảo mật trên các máy chủ được cấu hình kém, Điều này được chọn tự động khi thích hợp.

Đây chỉ là cách tôi hiểu ý tưởng về API tệp WordPress . Nếu nó sai, xin vui lòng downvote :)

Đuợc. Nếu bạn tải lên một tệp, tệp này có chủ sở hữu. Nếu bạn tải lên tệp của mình bằng FTP, bạn đăng nhập và tệp sẽ thuộc quyền sở hữu của người dùng FTP. Vì bạn có thông tin đăng nhập, bạn có thể thay đổi các tệp này thông qua FTP. Chủ sở hữu thường có thể thực thi, xóa, thay đổi vv các tập tin. Tất nhiên, bạn có thể thay đổi điều này bằng cách thay đổi quyền truy cập tệp .

Nếu bạn tải lên một tệp bằng PHP, người dùng linux đang thực thi PHP đang sở hữu tệp đó. Người dùng này bây giờ có thể chỉnh sửa, xóa, thực hiện, vv các tập tin. Điều này là ổn miễn là chỉ có bạn là người dùng, người đang thực thi PHP trên hệ thống của bạn.

Giả sử, bạn đang ở trên một máy chủ chia sẻ được cấu hình "kém". Rất nhiều người chạy các trang web PHP của họ trên hệ thống này. Hãy nói rằng chỉ có một người dùng linux đang thực thi PHP cho tất cả những người này. Một trong những quản trị web trên máy chủ được chia sẻ này có ý định xấu. Anh ấy nhìn thấy trang của bạn và anh ấy tìm ra đường dẫn đến cài đặt WordPress của bạn. Ví dụ: WP_DEBUG được đặt thành đúng và có thông báo lỗi như

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1

"Hà!" Cậu bé xấu số nói. Cho phép xem, nếu anh chàng này đã đặt FS_METHODđể directvà ông viết một kịch bản như

<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>

Vì chỉ có một người dùng đang chạy PHP và người dùng này cũng bị kẻ xấu sử dụng, anh ta có thể thay đổi / xóa / thực thi các tệp trên hệ thống của bạn nếu bạn đã tải chúng qua PHP và do người dùng PHP này đính kèm với tư cách là chủ sở hữu.

Trang web của bạn bị hack.

Hoặc, như đã nói trong Codex:

Nhiều hệ thống lưu trữ có máy chủ web chạy như một người dùng khác với chủ sở hữu các tệp WordPress. Khi gặp trường hợp này, một quá trình viết tệp từ người dùng máy chủ web sẽ có các tệp kết quả thuộc sở hữu của tài khoản người dùng của máy chủ web thay vì tài khoản người dùng thực tế. Điều này có thể dẫn đến một vấn đề bảo mật trong các tình huống lưu trữ được chia sẻ, trong đó nhiều người dùng đang chia sẻ cùng một máy chủ web cho các trang web khác nhau.

Rủi ro là gì?

Trên một máy chủ được chia sẻ cấu hình kém, mọi PHP của khách hàng sẽ thực thi như cùng một người dùng (giả sử apacheđể thảo luận). Thiết lập này là đáng ngạc nhiên phổ biến.

Nếu bạn đang ở trên một máy chủ như vậy và sử dụng WordPress để cài đặt plugin bằng cách truy cập tệp trực tiếp, tất cả các tệp plugin của bạn sẽ thuộc về apache. Một người dùng hợp pháp trên cùng một máy chủ sẽ có thể tấn công bạn bằng cách viết một tập lệnh PHP tiêm mã độc vào các tệp plugin của bạn. Họ tải tập lệnh của họ lên trang web của riêng họ và yêu cầu URL của nó. Mã của bạn bị xâm phạm thành công vì tập lệnh của chúng chạy như apache, cùng mã sở hữu các tệp plugin của bạn.

Nó FS_METHOD 'direct'phải làm gì với nó?

Khi WordPress cần cài đặt các tệp (chẳng hạn như plugin), nó sử dụng hàm get_filesystem_method () để xác định cách truy cập hệ thống tệp. Nếu bạn không xác định FS_METHODnó sẽ chọn một mặc định cho bạn, nếu không nó sẽ sử dụng lựa chọn của bạn miễn là nó có ý nghĩa.

Hành vi mặc định sẽ cố gắng phát hiện xem bạn có ở trong môi trường có nguy cơ như môi trường tôi đã mô tả ở trên không và nếu nghĩ rằng bạn an toàn thì sẽ sử dụng 'direct'phương pháp đó. Trong trường hợp này, WordPress sẽ tạo các tệp trực tiếp thông qua PHP, khiến chúng thuộc về apachengười dùng (trong ví dụ này). Nếu không, nó sẽ quay trở lại một phương pháp an toàn hơn, chẳng hạn như nhắc bạn về thông tin xác thực SFTP và tạo các tệp như bạn.

FS_METHOD = 'direct'yêu cầu WordPress bỏ qua việc phát hiện nguy cơ đó và luôn tạo tệp bằng 'direct'phương thức này.

Vậy thì tại sao lại dùng FS_METHOD = 'direct'?

Thật không may, logic của WordPress để phát hiện một môi trường có nguy cơ bị thiếu sót và tạo ra cả âm tính giả và âm tính giả. Rất tiếc. Thử nghiệm liên quan đến việc tạo một tệp và đảm bảo rằng nó thuộc về cùng một chủ sở hữu với thư mục mà nó tồn tại. Giả định là nếu người dùng giống nhau, PHP sẽ chạy như một tài khoản của riêng bạn và an toàn để cài đặt các plugin như tài khoản đó. Nếu chúng khác nhau, WordPress giả định rằng PHP đang chạy như một tài khoản dùng chung và không an toàn khi cài đặt các plugin như tài khoản đó. Thật không may, cả hai giả định này đều là những phỏng đoán có giáo dục sẽ thường xuyên bị sai.

Bạn sẽ sử dụng define('FS_METHOD', 'direct' );trong một kịch bản tích cực sai, chẳng hạn như kịch bản này: bạn là thành viên của một nhóm đáng tin cậy có tất cả các thành viên tải lên các tệp thông qua tài khoản của riêng họ. PHP chạy như người dùng riêng của nó. WordPress sẽ cho rằng đây là một môi trường có nguy cơ và sẽ không mặc định ở 'direct'chế độ. Trong thực tế, nó chỉ được chia sẻ với người dùng mà bạn tin tưởng và vì 'direct'chế độ như vậy là an toàn. Trong trường hợp này, bạn nên sử dụng define('FS_METHOD', 'direct' );để buộc WordPress viết tệp trực tiếp.

Có một tình huống 'được cấu hình tốt' trong đó 'trực tiếp' sẽ dẫn đến các vấn đề.

Cũng có thể định cấu hình lưu trữ WP được chia sẻ với người dùng thực thi PHP không chia sẻ, khác với người dùng quyền sở hữu tệp / thư mục. Vì vậy, bạn kết thúc với các tệp thuộc sở hữu của user1 và mã PHP được thực thi dưới dạng php-user1.

Trong tình huống đó, các plugin hoặc mã lõi bị hack (a) không thể ghi vào (hoặc thậm chí đọc từ, tùy thuộc vào quyền) quyền giám đốc của người dùng khác; (b) không thể viết các tệp của người dùng này và vì vậy không thể thêm mã trojan vào mã lõi hoặc mã plugin.

Vì vậy, nếu lưu trữ được thiết lập như vậy, bạn PHẢI sử dụng FTP để cập nhật và 'direct' sẽ không hoạt động.

Nếu bạn đặt 'direct' trong wp-config.php và người dùng thực thi PHP không có quyền ghi, bạn sẽ nhận được các thông báo Cập nhật thất bại và không có cửa sổ bật lên yêu cầu thông tin đăng nhập FTP.