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

wp-config.php에서 설정 조정을 제안한 이 게시물 을 발견했습니다. 제안 된 설정을 추가했지만 가장 중요한 설정은 다음과 같습니다.

define("FS_METHOD", "direct");

알고 싶은 사항 FS_METHOD를 direct로 설정하는 것과 관련하여 실제로 우려해야 할 사항은 무엇입니까? 플러그인 설치에 대한 다른 대안이 있습니까?

공식 문서는 다음과 같이 말합니다.

FS_METHOD는 파일 시스템 메서드를 강제합니다. “direct”, “ssh2″, ” ftpext “또는”ftpsockets “입니다. 일반적으로 업데이트 문제가 발생한 경우에만이 값을 변경해야합니다. 변경해도 도움이되지 않으면 다시 변경하십시오. 이동. 대부분의 경우 “ftpsockets”로 설정하면 자동으로 선택된 방법이 작동하지 않는 경우 작동합니다.

(Primary Preference) “direct”는 PHP 내에서 직접 파일 I / O 요청을 사용하도록 강제합니다. 잘못 구성된 호스트에서 보안 문제가 발생하는 문제로 인해 적절한 경우 자동으로 선택됩니다.

답변

WordPress File API 의 아이디어를 이해 한 방법입니다. 틀렸다면 반대 투표 해주세요 🙂

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

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

구성된 공유 호스트가 “불량”하다고 가정 해 보겠습니다. 많은 사람들이이 시스템에서 PHP 웹 사이트를 운영합니다. 한 명의 리눅스 사용자 만이이 모든 사람들을 위해 PHP를 실행하고 있다고 가정 해 보겠습니다. 이 공유 호스트의 웹 마스터 중 한 명이 나쁜 의도를 가지고 있습니다. 그는 귀하의 페이지를보고 귀하의 WordPress 설치 경로를 파악합니다. 예를 들어 WP_DEBUG가 true로 설정되고 

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

“Ha!”와 같은 오류 메시지가 있습니다. 나쁜 소년이 말한다. 이 사람이 FS_METHOD를 direct로 설정하고

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

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

또는 Codex에 명시된대로 :

많은 호스팅 시스템에는 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"에서 WordPress에이를 우회하도록 요청합니다. -위험을 감지하고 항상 "direct" 방법을 사용하여 파일을 만듭니다.

그런 다음 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에서 “직접”을 설정하고 PHP 실행 사용자에게 쓰기 권한이없는 경우 “업데이트”를 받게됩니다. 실패한 메시지 및 FTP 자격 증명을 요청하는 팝업이 없습니다.

답글 남기기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다