wp-config에서 FS_METHOD를 "direct"로 설정할 때 어떤 보안 문제가 있습니까?

최근에 수동 설치 또는 원 클릭 설치 옵션을 사용할 수 없기 때문에 WP Smush Pro 플러그인을 설치할 수없는 문제가있었습니다.

내가 건너 온 이 게시물 의 설정을 조정 제안했다 wp-config.php. 제안 된 설정을 추가했지만 가장 중요한 것으로 보이는 설정은 다음과 같습니다.

define('FS_METHOD', 'direct');

내가 알고 싶은 것은 무엇을 설정 FS_METHOD해야 direct할까? 플러그인 설치에 대한 다른 대안이 있습니까?

공식 문서는 다음과 같습니다.

FS_METHOD는 파일 시스템 메소드를 강제합니다. "direct", "ssh2", "ftpext"또는 "ftpsockets"만 있어야합니다. 일반적으로 업데이트 문제가 발생한 경우에만 변경해야합니다. 변경해도 도움이되지 않으면 다시 변경하거나 제거하십시오. 대부분의 상황에서 자동으로 선택된 방법이 그렇지 않은 경우 'ftpsockets'로 설정하면 작동합니다.

(기본 환경 설정) "직접"은 PHP 내에서 직접 파일 I / O 요청을 사용하도록 강제합니다. 이는 잘못 구성된 호스트에서 보안 문제가 발생하는 문제입니다. 적절한 경우 자동으로 선택됩니다.

이것은 단지 WordPress File API 의 아이디어를 어떻게 이해했는지 입니다. 그것이 틀렸다면, downvote하십시오 :)

괜찮아. 파일을 업로드하면이 파일에 소유자가 있습니다. FTP를 사용하여 파일을 업로드하면 로그인하고 FTP 사용자가 파일을 소유하게됩니다. 자격 증명이 있으므로 FTP를 통해 이러한 파일을 변경할 수 있습니다. 소유자는 일반적으로 파일을 실행, 삭제, 변경 등을 할 수 있습니다. 물론 파일 권한 을 변경하여이를 변경할 수 있습니다 .

PHP를 사용하여 파일을 업로드하면 PHP를 실행하는 Linux 사용자가 파일을 소유하고 있습니다. 이 사용자는 이제 파일을 편집, 삭제, 실행할 수 있습니다. 시스템에서 PHP를 실행하는 사용자 인 한 괜찮습니다.

"잘못 구성된"공유 호스트에 있다고 가정합니다. 많은 사람들이이 시스템에서 PHP 웹 사이트를 운영합니다. 한 명의 리눅스 사용자 만이이 모든 사람들을 위해 PHP를 실행한다고 가정 해 봅시다. 이 공유 호스트의 웹 마스터 중 하나가 잘못된 의도를 가지고 있습니다. 그는 귀하의 페이지를보고 워드 프레스 설치 경로를 알아냅니다. 예를 들어, WP_DEBUG가 true로 설정되고 다음과 같은 오류 메시지가 있습니다.

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

"하아!" 나쁜 소년이 말합니다. 이 사람이 설정 FS_METHOD하고 다음 direct과 같은 스크립트를 작성 하면 볼 수 있습니다.

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

한 명의 사용자 만 PHP를 실행하고 있으며이 사용자도 나쁜 소년에 의해 사용되므로 PHP를 통해 파일을 업로드 한 경우 PHP 사용자를 소유자로 첨부하여 시스템의 파일을 변경 / 삭제 / 실행할 수 있습니다.

귀하의 사이트가 해킹되었습니다.

또는 코덱스에 명시된 바와 같이 :

많은 호스팅 시스템에서 웹 서버가 WordPress 파일의 소유자와 다른 사용자로 실행되고 있습니다. 이 경우 웹 서버 사용자의 파일을 쓰는 프로세스는 실제 사용자 계정 대신 웹 서버의 사용자 계정이 소유 한 결과 파일을 갖게됩니다. 이로 인해 여러 사용자가 서로 다른 사이트에 대해 동일한 웹 서버를 공유하는 공유 호스팅 상황에서 보안 문제가 발생할 수 있습니다.

위험은 무엇입니까?

잘못 구성된 공유 호스트에서 모든 고객의 PHP는 동일한 사용자로 실행됩니다 ( apache토론을 해보자 ). 이 설정은 놀랍게 일반적입니다.

그러한 호스트에 있고 직접 파일 액세스를 사용하여 플러그인을 설치하기 위해 WordPress를 사용하는 경우 모든 플러그인 파일은에 속합니다 apache. 동일한 서버에있는 합법적 인 사용자는 플러그인 파일에 악의적 인 코드를 삽입하는 PHP 스크립트를 작성하여 공격 할 수 있습니다. 스크립트를 자신의 웹 사이트에 업로드하고 URL을 요청합니다. apache플러그인 파일을 소유 한 것과 동일한 스크립트가로 실행되어 코드가 성공적으로 손상되었습니다 .

FS_METHOD 'direct'그것과 무슨 관계가 있습니까?

WordPress는 파일 (예 : 플러그인)을 설치해야하는 경우 get_filesystem_method () 함수를 사용하여 파일 시스템에 액세스하는 방법을 결정합니다. 정의하지 않으면 FS_METHOD기본값을 선택하고, 그렇지 않으면 선택 사항이 의미가있는 한 선택을 사용합니다.

기본 동작은 위에서 설명한 것과 같은 위험 환경에 있는지 여부를 감지 하려고 시도 하며 안전하다고 생각되면이 'direct'방법 을 사용합니다 . 이 경우 WordPress는 PHP를 통해 파일을 직접 작성하여 apache사용자 (이 예에서는)에 속하게합니다 . 그렇지 않으면 SFTP 자격 증명을 요구하고 파일을 생성하는 등의 안전한 방법으로 돌아갑니다.

FS_METHOD = 'direct'위험 부담 감지를 무시하고 항상'direct' 방법을 사용하여 파일을 작성 하도록 WordPress에 요청 합니다 .

그렇다면 왜 사용 FS_METHOD = 'direct'합니까?

불행히도 위험 환경을 감지하기위한 WordPress의 논리는 결함이 있으며 위양성 및 위음성을 모두 생성합니다. 으악. 테스트는 파일을 생성하고 파일이 존재하는 디렉토리와 동일한 소유자에 속하는지 확인합니다. 사용자가 동일하면 PHP가 자신의 계정으로 실행 중이고 해당 계정으로 플러그인을 설치하는 것이 안전하다고 가정합니다. 서로 다른 경우 WordPress는 PHP가 공유 계정으로 실행 중이고 해당 계정으로 플러그인을 설치하는 것이 안전하지 않다고 가정합니다. 불행하게도이 두 가정은 종종 틀릴 수있는 교육 된 추측입니다.

다음 define('FS_METHOD', 'direct' );과 같은 오 탐지 시나리오에서 사용할 수 있습니다. 회원은 모두 자신의 계정을 통해 파일을 업로드하는 신뢰할 수있는 팀의 구성원입니다. PHP는 별도의 사용자로 실행됩니다. WordPress는 위험 환경 인 것으로 가정하고 기본 'direct'모드 는 아닙니다 . 실제로는 신뢰하는 사용자와 만 공유되며 이러한 'direct'모드는 안전합니다. 이 경우 define('FS_METHOD', 'direct' );WordPress에서 파일을 직접 쓰도록 강요 해야합니다 .

'직접적인'문제가 발생할 수있는 '잘 구성된'상황이 있습니다.

파일 / 디렉토리 소유권 사용자와 다른 비공유 PHP 실행 사용자와 공유 WP 호스팅을 구성 할 수도 있습니다. 따라서 user1이 소유 한 파일로 끝나고 PHP 코드는 php-user1로 실행됩니다.

이러한 상황에서 해킹 된 플러그인 또는 핵심 코드 (a)는 다른 사용자의 디렉토리에 쓰거나 권한에 따라 읽을 수 없습니다. (b) 이 사용자의 파일을 작성할 수 없으므로 코어 또는 플러그인 코드에 트로이 목마 코드를 추가 할 수 없습니다.

따라서 호스팅이 이와 같이 설정된 경우 업데이트에 FTP를 사용해야하며 '직접'이 작동하지 않습니다.

wp-config.php에서 'direct'를 설정하고 PHP 실행 사용자에게 쓰기 권한이없는 경우 업데이트 실패 메시지가 표시되고 FTP 신임 정보를 요청하는 팝업이 표시되지 않습니다.