블록, 노드, 뷰 인수 등에서 PHP 필터 코드를 사용하는 단점은 무엇입니까?

나는 사람들이 블록, 노드, 뷰-인수, 규칙 등에서 Drupal UI의 사용자 정의 PHP / PHP 필터를 사용하지 말라고 여러 번 보았습니다. 약간 검색했지만 많이 찾지 못했습니다. 이것은 모두 "알고있는"Drupal 모범 사례입니다.

Drupal 또는 PHP를 처음 접하는 최종 사용자 나 사람들에게 보안 위험이 발생할 수 있음을 이해하지만 개발자 / 사이트 빌더로서 Drupal UI의 사용자 정의 PHP를 사용하지 않는 실제 이유는 무엇입니까?

몇 가지 이유 :

• 데이터베이스의 코드는 버전 제어가 불가능하며 나중에 일반적으로 찾기가 더 어렵습니다.
• Eval ()의 코드는 파일에 하드 코딩 된 것보다 훨씬 느립니다.
• 해당 코드 어딘가에 오류가 있으면 매우 도움이되지 않는 오류 메시지 (3 번째 줄의 eval () 코드에서 오류)가 표시되며 데이터베이스를 수동으로 조사하여 오류를 찾아 수정했을 수도 있습니다. 예를 들어 모든 페이지에 표시되는 블록 안에 있으면 치명적인 오류가 발생합니다.
• Drupal 6에서 7로 업그레이드하고 사용한 API가 변경되었을 때도 위의 사항이 적용됩니다. 따라서 마이그레이션하는 동안 코드를 이식해야합니다. 코드가 모듈에 있으면 미리 포트하여 테스트하고 새 사이트에만 배포 할 수 있습니다. 노드 또는 블록 안에서는 Drupal 6 또는 7에서만 작동합니다.
• 브라우저 내부의 텍스트 필드에서 작업하기 때문에 해당 코드를 작성하고 유지 관리하는 것이 더 어렵습니다. 모듈에 포함 시키면 구문 강조, 자동 완성 등 편집기 / IDE를 사용할 수 있습니다.
• PHP 실행이 활성화 된 상태에서 텍스트 형식 / 차단 / 무엇이든 액세스 할 수있는 구성이 잘못되었을 가능성이 항상 있습니다. php.module (D7에서 D6이 블록 액세스 규칙과 같이 엄격하지 않음)을 활성화하지 않으면 위험이 이미 훨씬 낮습니다.
• CMS에서 PHP 실행을 허용하는 경우 XSS 또는 권한 에스컬레이션의 보안 취약점을 발견 한 공격자는 이제 서버를 사용하여 DDOS의 일부로 스팸을 보내고, 악성 코드를 호스팅하고, 방화벽 뒤에있을 수있는 네트워크의 다른 서버에 해킹). 작은 취약점을 더욱 고통스럽게 만드는 것 외에도, PHP를 실행하는 데 사용될 수 있다고 알려진 사이트는 공격의 대상이 될 가능성이 높습니다.

더 많은 이유가있을 수 있지만 충분해야합니다. :)

이 코드는 디버깅 및 유지 관리가 어렵습니다. 그런 종류의 PHP 코드에 버전 제어를 사용하는 방법을 모르겠습니다.

Drupal 또는 PHP를 처음 사용하는 사람들에게는 실제로 잠재적 인 보안 위험이 있습니다.

노드에서 사용되는 PHP 필터의 경우를 고려하지 않는 이유는 모든 사용자가 PHP 필터를 사용하지 못하게하려면 해당 노드를 편집 할 수있는 사용자를 제한하기 때문입니다.
PHP 필터를 사용하는 대신 노드 컨텐츠의 특정 텍스트를 (코드를 사용하지 않고 eval()) 실행 한 코드의 결과로 바꾸거나 자체 텍스트를 노드의 본문 컨텐츠에 추가 하는 사용자 정의 모듈을 사용하는 것이 좋습니다 . 이 경우 임의의 사용자가 PHP 필터에 의해 실행되는 임의의 PHP 코드를 추가 할 수있는 권한없이 노드를 편집 할 수 있습니다.

일반적으로 eval()코드의 가독성, 런타임 전에 코드 경로를 예측할 수있는 기능 (및 가능한 보안 영향) 및 코드 디버깅 기능이 저하되므로 피하는 것이 좋습니다 .

개발 사이트 나 테스트 사이트 외에도 PHP 필터를 사용하지 않거나에 전달 된 PHP 코드를 사용하지 않습니다 eval().

PHP 필터는 Drupal 8에서 제거되었습니다. 이제 보안 권고 정책 에서 다루지 않는 타사 모듈 입니다. 이것은 아마도 프로덕션 서버에서 사용하지 않는 이유 일 것입니다 (이미 주어진 이유가 당신을 납득시키지 못하면).

코드 유지 관리, 버전 관리, 오류 찾기의 어려움과 같은 위에서 언급 한 다양한 문제에 대한 해결 방법으로 다음과 같은 "klugey"가능성이 있습니다.

항상 포함되는 일부 파일에서 함수를 작성하십시오 (기능에 따라 신중하게 이름을 지정하십시오)-사이트에 작성중인 사용자 정의 모듈이있는 경우 이러한 함수를 배치하기에 좋은 곳입니다. 입력 한 PHP는 간단합니다 return my_specialfunc($somevar);.- $somevar잠재적으로 노드 객체가 작동하거나 여기에 관련된 다른 변수가 있습니다.

나는 여전히 어떤 장소에서 내 코드를 호출하는 유연성을 여전히 원한다는 것을 알았습니다. 이 기술을 사용하면 파일의 기능을 수정하기 만하면되기 때문에 코드를 유지 관리하는 것이 쉽습니다. 함수가 역 추적에 표시되므로 오류를 쉽게 파악할 수 있습니다.

그러나 이로 인해 잠재적 인 보안 문제가 해결되지는 않습니다. 이들은 Drupal 코어의 보안에 크게 의존합니다. 일반적으로 데이터베이스에 포함 된 코드는 종종 보안의 약점입니다. 데이터베이스에 포함 된 코드를 사용하는 기능은 악용에 훨씬 취약한 경향이 있으며, 그 주변의 보안은 매우 엄격해야합니다. 그러나 Drupal은 일반적으로 이러한 문제에 대한 보안을 유지하는 데 상당히 능숙했습니다. 이러한 문제는 새로운 릴리스로 발생하여 빠르게 패치 / 해결되었습니다.

관리자가 아닌 사용자가 db를 직접 수정하지 못하게하려면 사용자에게이 권한을 부여하지 않는 보안 취약점 이유가 있습니다.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Drupal DB 자격 증명 해킹

와 같은 작업을 수행하는 대신 return functionname($object)가능한 한 토큰 / 필터 시스템을 사용하는 것이 좋습니다. Insert View 및 Embed Node와 같은 모듈이있어서 사람들이 PHP를 노드 또는 블록 바디에 포함시키려는 일반적인 환경을 도울 수 있습니다.

데이터의 이식성에주의해야합니다. drupal 7에서 drupal 8로 노드를 마이그레이션하고 일부 노드 본문에 포함 <?php whatever_function_that_does_not_exist_anymore(); ?>된 경우 어떻게됩니까?

5 개월 이내에 5 년 이내에 프로젝트를 생각하지 마십시오. 업데이트, 모범 사례 및 이식성은 제 생각에 좋은 IT 프로젝트의 중요한 측면입니다.

기여도가 적은 모듈을 사용하는 것도 이것의 한 측면입니다.