Non è tanto che il PHP stesso ha problemi di sicurezza (presupponendo gli aggiornamenti di sicurezza necessari), poiché esiste un gran numero di popolari software basati su PHP con problemi di sicurezza dilaganti. Si potrebbe criticare PHP per essere un linguaggio che ti dà abbastanza corda per soffocare te stesso, ma il vero problema è proprio quanto sia diffuso il codice PHP vulnerabile. Basta un'occhiata al tag PHP Overflow dello stack per trovare nuovi principianti PHP che scrivono codice orribilmente vulnerabile basato su alcune atrocità di un vecchio tutorial.

Inoltre, un numero significativo di popolari software PHP noti per i loro vizi di sicurezza sfrenati si basa su pratiche di codifica e codice molto vecchie . Molte di queste vecchie pratiche sono considerate cattive pratiche a causa di problemi di sicurezza inerenti.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident.

Praticamente sì. Un consiglio migliore potrebbe essere sulla falsariga di "non guidare una vecchia auto senza airbag".

My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system.

Non necessariamente. Se un utente utilizza la stessa password per il sito WordPress e cPanel, compromettere la password di WordPress compromette anche cPanel. Questo sarebbe colpa dell'utente. Gli hacker raramente hanno bisogno di arrivare così lontano, e usano solo una shell PHP.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?)

Non necessariamente vero. È possibile utilizzare un servizio di terze parti per gestire l'invio di posta. Quindi il servizio gestisce lo scripting del server dinamico e prende in carico le implicazioni sulla sicurezza. Esistono numerosi servizi di questo tipo disponibili con diverse serie di funzioni e sono popolari per l'attivazione di moduli di contatto su siti generati staticamente.

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Alcuni, ma non molto. PHP implica un codice attivo, sia in PHP che nel software server che lo esegue. Se ci fosse mai stata una vulnerabilità di sicurezza in quel processo che non dipendeva da un codice PHP specifico, potrebbe essere sfruttato. Mentre quel rischio è piccolo, è un rischio che un server senza tale supporto non ha.

"Giusto" potrebbe non essere la parola giusta, ma "saggio", "prudente" e "coscienzioso" vengono in mente. PHP, sin dal suo inizio, ha aderito a una filosofia che svaluta la correttezza nel software. C'è un numero enorme di situazioni che un programma può incontrare dove altri linguaggi (ad esempio Python) si arrendono e lanciano un errore per dirti che il tuo programma è sbagliato, ma PHP invece sceglie di fare qualcosa di insensato e continuare come se le cose fossero solo multa.

Ricorda che correttezza è molto importante per la sicurezza. Un linguaggio che tende a ignorare silenziosamente gli errori di sinistra e di destra avrà più della sua giusta parte di programmi con problemi di sicurezza. Ad esempio, potresti avere un pezzo di codice che i tuoi programmatori pensano protegga da un determinato attacco, ma in realtà viene saltato perché l'interprete ignora un errore.

Inoltre:

• PHP è progettato per attrarre il minimo denominatore di programmatori con la minima motivazione a diventare bravo nel loro mestiere. E quindi la più probabilità di scrivere software non sicuro.
• Il team di PHP ha una storia di tentativi profondamente errati di correggere problemi di sicurezza comuni. Guarda ad esempio la protezione dell'iniezione SQL, che tradisce i ripetuti tentativi errati di correggere il problema: real_escape_string (perché il% originale% co_de era rotto, ma non lo rimuovevano più tardi) vs. escape_string rispetto a addslashes / mysql_escape_string e così via. Mentre praticamente tutte le altre lingue sono state fornite con istruzioni e parametri di query preparati e hanno ottenuto un design estendibile a tutti i database al primo tentativo.

Quindi per tutti i discorsi in altre risposte su come puoi scrivere software sicuro in PHP, se lo provi stai nuotando molto contro il corrente.

I problemi di sicurezza di PHP possono essere generalmente ridotti a due categorie

Sistemi senza patch

Al momento, Statistiche di Wordpress mostra che oltre la metà di tutti gli utenti eseguono PHP su versioni di PHP che sono passate < a href="http://php.net/eol.php"> Fine vita (PHP 5.2 - 5.4). In due settimane, PHP 5.5 passa a EOL e poi salta a circa l'80% di tutte le installazioni. Ora, per essere onesti, alcune installazioni Linux Enterprise / LTS sosterranno le correzioni di sicurezza, ma la stragrande maggioranza di loro non usa le correzioni backported (o alcune non aggiustano i loro sistemi). Peggio ancora, molte persone si rifiutano di aggiornare PHP in sé. O non possono / non aggiornano il loro codice, o pensano che il software più vecchio sia più stabile.

Wordpress (# 1 applicazione PHP utilizzata in tutto il mondo) ha fatto uno sforzo concertato per assicurarsi che gli utenti siano sempre aggiornati sul software stesso (e hanno fatto passi da gigante), ma nonostante ciò, solo il 40% sta eseguendo l'ultima versione di Wordpress. Ciò significa che circa il 60% potrebbe avere una vulnerabilità di sicurezza senza patch. E questo è solo il programma base. Wordpress ha un enorme ecosistema di plugin, e molti di loro hanno vulnerabilità di sicurezza proprie .

Poi ci sono altri problemi, come molti vecchi codici che usano il defunto libreria mcrypt . E questo è solo un plugin PHP che puoi compilare.

Ora estrapolandolo ai server non in esecuzione e riportando le statistiche a WP. Non dipinge una bella immagine. La scorsa estate ho trovato un sito Web che pubblicava una pagina di e-commerce che era ancora su Apache 1.3.3 e PHP 4.1.2. Era così vecchio che aveva abilitato SSLv2 ...

Cattive pratiche

Se ti attendi a domande SO PHP abbastanza a lungo, vedrai un sacco di persone che praticano codice errato. Alcuni dei problemi che ho visto negli anni

• SQL Injection
• Pensare a MD5 è un buon modo per proteggere le password
• Uso di API obsolete con il loro codice (cioè ext/mysql , il vecchio connettore MySQL)
• Affidabilità dell'input dell'utente per l'esecuzione del codice (ad esempio utilizzando eval con i dati forniti dall'utente)
• Non disattivare i rischi per la sicurezza nel codice PHP (ad esempio la funzione exec )

Per gli inesperti, questo sembra un problema di PHP, quando sono i programmatori e i loro ecosistemi a produrre i problemi. Forse avevano fretta. Forse hanno assunto un tizio che fa questo nel suo tempo libero e "lo ha appena fatto funzionare".

Può essere sicuro?

YES! Ma quella sicurezza richiede qualche sforzo. Mantieni aggiornata la tua installazione di PHP. Diamine, mantieni aggiornato tutto il tuo server. L'host non farà sicurezza e patch? Trova un altro host. (Sono stupito dalle persone che si oppongono a questo). Costruisci il tuo server (le macchine virtuali sono economiche). Ma soprattutto, prestare attenzione. Impara tutto ciò che puoi sulla sicurezza. Non limitarti a lasciare il tuo sito web e il tuo server in mare aperto.

Qualcuno che ti dice che PHP è insicuro è semplicemente pigro.

PHP non è meno, o più sicuro, o insicuro di qualsiasi altra lingua (Java, Rails, ecc.). È tutto sulla codifica. Sono in atto controlli e saldi per deviare, difendere, prevenire e mitigare un attacco. Citando:

WhiteHat Security performed vulnerability assessments of more than 30,000 websites using .NET, Java, ASP, PHP, Cold Fusion and Perl. The most widely used languages were .NET (28.1 percent of Web applications), Java (24.9 percent) and ASP (15.9 percent).

...

The programming language .Net had an average of 11.36 vulnerabilities per slot, Java 11.32 and ASP 10.98. The most secure language, ColdFusion, had six vulnerabilities per slot. Perl had seven vulnerabilities per slot and PHP had 10.

...

Java accounted for 28 percent of vulnerabilities found and ASP 15 percent. “Again, the number of applications written in the language along with the complexities of the websites has to be considered as a contributing factor,” said the report. PHP also accounted for 15 percent of vulnerabilities discovered. ColdFusion only accounted for 4 percent of vulnerabilities and Perl 2 percent. (source)

Questo non dice nulla su come i siti sono stati sviluppati in termini di buone pratiche di codifica. Ad esempio, se si assumessero programmatori non qualificati (per mancanza di termini migliori) in ciascuna lingua, questi numeri potrebbero essere invertiti e Perl potrebbe avere il maggior numero di vulnerabilità, con .Net che ha il minimo. Tutto si riduce a ciò che il codice stesso dovrebbe fare. Il codice è stato programmato per svolgere la sua unica funzione con test di manomissione / abuso prima di essere messo in sviluppo?

Ci sono un sacco di sicurezza cheat sheet , guide alle best practice e altri write-up che coprono problemi di sicurezza ma questa diventa una situazione in cui il cliente è stanco sulla base del consiglio del proprio fornitore. Questo può essere un ostacolo dal momento che diventa un "ha detto" ha detto una sorta di lotta per convincere il tuo cliente a consentire di creare il sito utilizzando PHP. Un metodo che potrei usare se volessi usare PHP sarebbe creare un sito demo, quindi utilizzare uno scanner di valutazione delle vulnerabilità (Acunetix, AppScan, Burpsuite) per controllare eventuali difetti. Se non vengono trovati, vorrei presentare il rapporto che descrive in dettaglio la posizione di sicurezza di ciò che è stato creato per entrambi i client e creare in questo modo (PDF, ecc.) Che è presentabile al fornitore.

Uno dei problemi fondamentali con PHP è in realtà un problema fondamentale con il modello CGI delle cose (su cui si basa PHP, nonostante le trappole di mod_php ) - vale a dire che i dati rivolti all'utente sono mescolati con gli script, e diventa molto facile per es upload dell'utente per diventare uno script eseguibile. Questo non è necessariamente un problema con PHP stesso, ma avere PHP disponibile su un sistema lo rende una superficie di attacco molto grande; Ad esempio, alcuni aspetti dei problemi di sicurezza di WordPress derivano da questo aspetto.

Le implementazioni tradizionali basate su CGI hanno mitigato storicamente questo problema consentendo solo agli script CGI di essere eseguiti da una directory attendibile (come /cgi-bin/ ) ma molti provider di hosting condiviso hanno allentato questa restrizione per "convenienza" e la stessa convenienza è pervasivo in tutto PHP.

Molte moderne applicazioni basate su PHP spesso usano .htaccess come meccanismo di instradamento delle richieste rapido e sporco che aiuta a mitigare questi problemi, ma questo è tutt'altro che universale e non è ancora una cura facile.

Secondo me, il problema più grande con PHP è che è così facile che un codice PHP arbitrario sia reso disponibile per l'esecuzione su qualsiasi server in cui è configurato, e quindi mentre il codice scritto in PHP non è necessariamente più o meno sicuro di codice scritto in altre lingue (sebbene la sua libreria standard non sia esattamente fare qualche favore quando si tratta di scrivere codice sicuro), il meccanismo con cui gli script PHP vengono eseguiti fornisce una massiccia sfida di sicurezza in base al merito di PHP anche se è disponibile su un server.

Sono d'accordo con la tua valutazione che l'uso di PHP non richiede un rischio per la sicurezza. Ci sono alcuni fornitori che rifuggono da PHP per lo stesso motivo per cui WordPress è visto come un rischio per la sicurezza. È popolare Più qualcosa è prevalente, più energia viene investita nello sviluppo di exploit.

Detto questo, non vorrei evitare PHP se è implementato correttamente, riceve patch tempestive e ha un certo livello di monitoraggio per rilevare attività dannose. In conclusione: i rischi per la sicurezza sono i rischi per la sicurezza indipendenti dalla piattaforma. La modifica dei linguaggi di scripting non attenua i rischi per la sicurezza associati a un codice scritto / sviluppato / implementato in modo scadente.

Se tutto ciò che si desidera è includere un'intestazione / piè di pagina standard, PHP potrebbe essere eccessivo: i semplici inclusi sul lato server potrebbero farlo.

PHP non è intrinsecamente pericoloso, come hanno sostenuto le precedenti risposte. Ma se non hai bisogno di un linguaggio di scripting completo sul server, la migliore pratica di sicurezza non è installarne una. Se, come dici tu, PHP verrà installato sul server in ogni caso, allora il rischio aggiuntivo creato usando lo stesso è circa zero finché non fai nulla di stupido. E includere un modello non è stupido a meno che tu non abbia in qualche modo analizzato il nome del file da un parametro URL.

Il modulo di contatto avrà bisogno di una sorta di API e database dietro di esso per gestire la richiesta POST quando qualcuno lo invia ed è quanto bene è stata scritta questa parte che sta per creare o distruggere qualcosa, qualunque sia la lingua che usi, se è un SQL il database quindi l'iniezione SQL merita attenzione; se l'input dell'utente viene in qualche modo riecheggiato a loro o al client in una pagina Web, allora l'iniezione di script (java) deve essere presa in considerazione e tutto correttamente HTML-escape. Rispetto al modulo di contatto, l'utilizzo di una inclusione è sicuro come al solito.

Se si desidera solo una serie di pagine Web, non un'applicazione Web interattiva, la massima sicurezza consiste nell'utilizzare un generatore di siti statico: il server deve solo offrire file che offrono una superficie di attacco molto più piccola.

Quanta verità c'è dietro l'affermazione che l'utilizzo di uno script PHP, non importa quanto semplice, è un problema di sicurezza inerente?

Formulato in questo modo, quasi nessuno. Uno script include-header non è certamente una vulnerabilità. Avere installato PHP in primo luogo quando non ne hai bisogno non è la migliore pratica di sicurezza, averlo installato e non aggiornarlo regolarmente ogni volta che escono delle patch di sicurezza è un potenziale problema, in quanto non si ha una politica di chi è responsabile di questi aggiornamenti - dopo aver terminato la progettazione del sito, il cliente sarà responsabile di questo? O il fornitore di hosting? Se il cliente è preoccupato, non dovrebbe avere PHP sul server in primo luogo. In caso contrario, non vi è alcun motivo relativo alla sicurezza per non utilizzarlo in luoghi in cui sai cosa stai facendo.

Lingue e strumenti non sono intrinsecamente insicuri, codice errato e pratiche di sicurezza sono.

Dato che php ha una bassa barriera all'ingresso, le persone che non comprendono la sicurezza della rete e la codifica sicura possono creare problemi di sicurezza con decisioni non informate.

Non è lo strumento, è la scimmia che lo usa; -)

Il codice scritto in qualsiasi lingua può non essere sicuro.

"Sono riluttanti perché sono stati avvisati dalla loro società di hosting che usare PHP è un problema di sicurezza che potrebbe consentire a qualcuno di entrare in cPanel e ottenere il controllo del sito"

Se la società di hosting pensa di aver bisogno di cPanel per eseguire PHP, allora è il momento di spostare l'host