Perché così tante funzioni PHP non sono consentite nello standard di codifica ECG Magento?

Lo standard di codifica ECG Magento sembra essere (almeno un tipo di) ufficiale come standard per le estensioni Magento 1:

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

Ma non capisco il ragionamento alla base di tutte le regole e le regole dello sniffer di codice con i loro messaggi da sole non aiutano molto. Esiste una documentazione dettagliata sullo standard? Conosco le migliori pratiche comuni e la guida per gli sviluppatori, ma non riesco a trovare nulla di specifico su questi standard di codifica.

Ciò che mi preoccupa di più è la severità nel non usare le funzioni PHP.

Ad esempio: perché è vietata ogni singola funzione PHP relativa al file system ?

Immagino che dovresti usare Varien_Io_File, Varien_File_Objectecc. Ma anche gli sviluppatori principali non sono a conoscenza di tutte le classi Varien e spesso trovi cose come in Mage_ImportExport_Model_Import_Adapter_Csv:

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

Quindi, il nucleo non è il miglior esempio, come spesso.

Altre funzioni proibite discutibili di IMHO:

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • sì, è usato in backdoor ma il divieto evaldovrebbe essere sufficiente e ci sono casi d'uso legittimi, come la codifica dei dati binari. E a parte json_decode(che non è vietato) non esiste un aiuto di base disponibile per questo.

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

In sostanza, la mia domanda si riduce a: dove è documentato questo standard? E / o c'è un elenco di "cose ​​da usare al posto di queste funzioni native di PHP"?

Ho ricevuto una risposta non ufficiale da parte del team ECG su questo:

Prima di tutto, le funzioni contrassegnate non sono necessariamente vietate: dovrebbero innescare una revisione manuale sull'utilizzo per garantire un uso legittimo. È uno strumento di supporto alla revisione, non uno strumento di valutazione del codice buono / cattivo.

In secondo luogo, si presume che sia meglio usare i wrapper (funzioni / classi) Magento se esistono in quanto potrebbero offrire funzionalità o protezione aggiuntive.

In terzo luogo, per quanto riguarda le chiamate specifiche, base64_decode viene spesso utilizzato per codice iniettato dannoso e il resto come parse_str potrebbe essere vulnerabile, in particolare la gestione di input sconosciuti o forniti dall'utente - vedere ad esempio http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str ininterrotti-memory-corruzione vulnerabilità /

Ancora una volta, questo lo sta segnalando per la revisione non rifiutando il codice come male.

Spero che sia d'aiuto.

Lo standard di codifica ha due obiettivi.

1. rendere molto più facile la ricerca di parti potenzialmente problematiche. Uno sviluppatore esperto sa già quali parti di un nuovo modulo deve rivedere, e questo standard le contrassegna e le elenca per lui. Non è così che può rimuovere queste parti, ma riesaminare se sono necessarie, problematiche o entrambe.

2. supportare sviluppatori inesperti su quali cose dovrebbe evitare. Mentre tutte le funzioni contrassegnate possono essere buone soluzioni per problemi specifici, sono molto facili da usare in modo problematico. Porta gli sviluppatori a pensare di più al problema e spesso a soluzioni migliori che non siano in conflitto con lo standard.

E a volte, anche gli sviluppatori più esperti seguono ciecamente lo standard e creano le soluzioni più crudeli, solo per non offendere uno standard forzato della comunità.

qualche informazione aggiuntiva

Le funzioni dei file spesso consentono l'utilizzo di wrapper di protocollo, significa che un percorso di file che inizia con http: // porta a una richiesta http, che viene spesso utilizzata per "chiamare casa", e di volta in volta uccide un negozio, perché il server non è raggiungibile (Timeout predefinito di 30 secondi) ed è incorporato in una posizione molto centrale.

tutto sommato sql, nessuno crede a quanti fori di iniezione sql esistono ancora là fuori. Un grande esempio è stato, poiché ne aveva uno nella Ricerca sul sito Web di Mysql.

c'è un helper di base per json_decode da qualche parte, ma ha un'implementazione molto vecchia, basta usare json_decode. Nessuna idea del perché dovrebbe essere vietato.

gettext è una parte interessante di php, ricordo che usa un'implementazione del sistema operativo nativo che potrebbe avere problemi, se lo usi in parallelo con lingue diverse (come succede di solito quando hai più di una lingua nel tuo negozio. Non hai mai studiato così tanto , ma non dovrebbe essere necessario nel contesto di Magento.

Andando oltre l'elenco, sembra che sia solo un elenco con quante più funzioni possibili. La storia è in realtà divertente, sembra che abbiano rimosso alcune delle funzioni dall'elenco, dopo averlo notato, ne fanno uso. : D