Magento ECG 코딩 표준에서 너무 많은 PHP 기능이 허용되지 않는 이유는 무엇입니까?


30

Magento ECG 코딩 표준은 Magento 1 확장의 표준으로 (적어도 일종의) 공식적인 것으로 보입니다.

https://github.com/magento-ecg/coding-standard

그러나 나는 모든 규칙의 추론을 이해하지 못하며 메시지 스니퍼 규칙만으로는 큰 도움이되지 않습니다. 표준에 대한 자세한 문서가 있습니까? 나는 일반적인 모범 사례와 개발자 가이드를 알고 있지만 이러한 코딩 표준에 대한 구체적인 내용은 찾을 수 없습니다.

가장 문제가되는 것은 PHP 함수를 사용하지 않는 것에 대한 엄격 성입니다.

예를 들어 : 모든 단일 파일 시스템 관련 PHP 기능이 금지 된 이유는 무엇 입니까?

난 당신이 사용되어 있습니다, 생각 Varien_Io_File, Varien_File_Object등 만도 핵심 개발자가 모든 Varien 클래스 인식하지 못하며 자주에서 같은 일을 찾을 수 Mage_ImportExport_Model_Import_Adapter_Csv:

    $this->_fileHandler = fopen($this->_source, 'r');

따라서 핵심은 가장 좋은 예가 아닙니다.

기타 IMHO 의심스러운 금지 기능 :

  • mb_parse_str
  • parse_str
  • parse_url
  • base64_decode

    • 예, 백도어에서 사용되지만 금지 eval는 충분해야하며 이진 데이터 인코딩과 같은 합법적 인 사용 사례가 있습니다. 그리고 json_decode(금지되지는 않음) 이외에는 사용할 수있는 핵심 도우미가 없습니다.

출처 : https://github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

본질적으로 내 질문은 다음과 같이 요약됩니다.이 표준은 어디에 기록되어 있습니까? 그리고 / 또는 "이러한 기본 PHP 함수 대신 사용할 것들"목록이 있습니까?


1
Magento는 Zend Framework를 기반으로합니다. 왜 Zend 표준을 사용하지 않습니까?
zhartaunik

ECG는 루프에 모델이로드 된 경우와 같이 더 많은 마 젠토 특정 검사를 수행합니다. 이것은 들여 쓰기 및 괄호와 같은 기본 스타일 검사에 관한 것이 아닙니다.
Fabian Schmengler

1
"원시 SQL 쿼리"를 금지 된 것으로 나열하는 것도 순진한 것 같습니다. 물론 대부분의 상황에서 원시 SQL을 수행하지는 않지만 적절할뿐만 아니라 필요한 경우도 있습니다 (예 : 복잡한 수입 / 수출)
pspahn

1
@pspahn 요점을 알지만 Zend_Db쿼리 빌더가 SQL 쿼리를 생성 할 수 없어야합니까?
Fabian Schmengler

물론, 원시 SQL을 입력으로 사용하여 select명령문을 작성할 수도 Zend_Db없습니까? 백엔드에서 github.com/kalenjordan/custom-reports가하는 일이라고 가정했습니다 .
pspahn

답변:


28

ECG 팀으로부터 비공식 답변을 받았습니다.

우선 플래그가 지정된 기능이 반드시 허용되는 것은 아닙니다. 합법적 인 사용을 위해 사용에 대한 수동 검토를 시작해야합니다. 좋은 / 나쁜 코드 스코어링 도구가 아닌 검토 도우미 도구입니다.

둘째, 추가 기능이나 보호 기능을 제공 할 수 있으므로 Magento 래퍼 (함수 / 클래스)가있는 경우 사용하는 것이 좋습니다.

셋째, 특정 호출의 경우 base64_decode가 악성 삽입 코드에 자주 사용되며 parse_str과 같은 나머지는 특히 알 수 없거나 사용자가 제공 한 입력을 처리하는 데 취약 할 수 있습니다. 예를 들어 http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-interruption-memory-corruption- 취약성 /

다시 말하지만, 이는 코드를 나쁘게 거부하지 않는 검토 용 플래그입니다.

도움이 되길 바랍니다.


그렇다면 왜 "합법적 인 사용을 위해 코드를 검토해야"하는 대신 "기능이 금지되어 있습니다"라고 쓰고 있습니까?!
블랙

11

코딩 표준에는 두 가지 목표가 있습니다.

  1. 문제가있는 부품을 훨씬 쉽게 찾을 수 있습니다. 숙련 된 개발자는 이미 새로운 모듈의 어떤 부분을 검토해야하는지 알고 있으며이 표준은이를 표시합니다. 따라서이 부품을 제거 할 수는 없지만 필요한지, 문제가 있는지 또는 둘 다인지 검토해야합니다.

  2. 피해야 할 경험이없는 개발자를 지원합니다. 표시된 모든 기능이 특정 문제에 대한 훌륭한 솔루션 일 수 있지만 문제가있는 방식으로 사용하기가 매우 쉽습니다. 개발자는 문제에 대해 더 많이 생각하고 표준과 충돌하지 않는 더 나은 솔루션을 생각하게됩니다.

때로는 경험이 많은 개발자조차도 맹목적으로 표준을 따르고 커뮤니티가 강제하는 표준을 위반하지 않기 위해 가장 잔인한 해결 방법을 만듭니다.

약간의 추가 정보

파일 함수는 종종 프로토콜 래퍼의 사용을 허용합니다. http : //로 시작하는 파일 경로는 http 재 요청으로 이어지고 "홈 호출"에 종종 사용되며, 서버에 연결할 수 없기 때문에 때때로 상점을 죽입니다. (기본 시간 제한 30 초) 및 중앙 위치에 내장되어 있습니다.

SQL이 실현되었다는 사실을 알면서도 아직 얼마나 많은 SQL 주입 구멍이 존재하는지 믿지 않습니다. Mysql 웹 사이트 검색에 하나가 있었기 때문에 좋은 예입니다.

어딘가에 json_decode의 핵심 도우미가 있지만 아주 오래된 구현이 있으므로 json_decode를 사용하십시오. 왜 금지되어야하는지 전혀 모른다.

gettext는 흥미로운 PHP 부분입니다. 다른 언어로 병렬로 사용하면 문제가 발생할 수있는 네이티브 OS 구현을 사용한다는 것을 기억합니다 (일반적으로 상점에 하나 이상의 언어가있을 때 발생합니다). Magento Context에는 필요하지 않습니다.

더 많은 목록을 살펴보면 가능한 한 많은 기능을 갖춘 목록 인 것 같습니다. 역사는 실제로 재밌습니다. 목록에서 일부 기능을 제거한 것으로 나타났습니다. :디

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.