diff --git a/security/cgi-bin.xml b/security/cgi-bin.xml
new file mode 100644
index 000000000..2a636e442
--- /dev/null
+++ b/security/cgi-bin.xml
@@ -0,0 +1,247 @@
+
+
+
+
+ Installato come binario CGI
+
+
+ Possibili attacchi
+
+ L'utilizzo di PHP come binario CGI è un'opzione per
+ configurazioni che, per qualche motivo, non desiderano integrare PHP come
+ modulo nel software del server (come Apache), oppure utilizzare PHP con
+ diversi tipi di wrapper CGI per creare ambienti sicuri
+ chroot e setuid
+ per gli script. Questa configurazione prevede normalmente l'installazione del
+ binario eseguibile php nella directory cgi-bin del server web.
+ L'avviso CERT CA-96.11 raccomanda
+ di non collocare interpreti nella directory cgi-bin.
+ Sebbene il binario php possa essere utilizzato come interprete autonomo,
+ PHP è progettato per prevenire gli attacchi resi possibili da questa configurazione:
+
+
+
+
+ Accesso ai file di sistema: http://my.host/cgi-bin/php?/etc/passwd
+
+
+ Le informazioni della query in un URL dopo il punto interrogativo (?) vengono
+ passate come argomenti della riga di comando all'interprete tramite l'interfaccia
+ CGI. Solitamente gli interpreti aprono ed eseguono il file
+ specificato come primo argomento sulla riga di comando.
+
+
+ Quando viene eseguito come binario CGI, php si rifiuta di interpretare gli
+ argomenti della riga di comando.
+
+
+
+
+ Accesso a qualsiasi documento web presente sul server: http://my.host/cgi-bin/php/secret/doc.html
+
+
+ La parte relativa alle informazioni sul percorso dell'URL dopo il nome del binario PHP,
+ /secret/doc.html viene
+ convenzionalmente utilizzata per specificare il nome del file da
+ aprire e interpretare dal programma CGI.
+ Solitamente alcune direttive di configurazione del server web (Apache:
+ Action) vengono utilizzate per reindirizzare richieste verso documenti come
+ http://my.host/secret/script.php all'
+ interprete PHP. Con questa configurazione, il server web verifica prima
+ i permessi di accesso alla directory /secret e successivamente crea la
+ richiesta reindirizzata http://my.host/cgi-bin/php/secret/script.php.
+ Sfortunatamente, se la richiesta viene effettuata direttamente in questa forma,
+ il server web non esegue alcun controllo di accesso sul file /secret/script.php, ma soltanto sul file
+ /cgi-bin/php. In questo modo
+ qualsiasi utente in grado di accedere a /cgi-bin/php può accedere anche a qualsiasi
+ documento protetto presente sul server web.
+
+
+ In PHP, le direttive di configurazione a runtime cgi.force_redirect, doc_root e user_dir possono essere utilizzate per impedire
+ questo attacco, se l'albero dei documenti del server contiene directory
+ con restrizioni di accesso. Di seguito è riportata una spiegazione completa
+ delle diverse combinazioni.
+
+
+
+
+
+
+ Caso 1: vengono serviti solo file pubblici
+
+
+ Se il server non contiene alcun contenuto protetto mediante password
+ o controllo degli accessi basato su indirizzi IP, queste opzioni di
+ configurazione non sono necessarie. Se il server web non consente
+ i reindirizzamenti, oppure non dispone di un metodo per
+ comunicare al binario PHP che la richiesta è stata reindirizzata in
+ modo sicuro, è possibile abilitare la direttiva
+ cgi.force_redirect
+ ini. È comunque necessario assicurarsi che gli script PHP
+ non dipendano da uno specifico metodo di chiamata,
+ né direttamente tramite http://my.host/cgi-bin/php/dir/script.php
+ né mediante reindirizzamento http://my.host/dir/script.php.
+
+
+ In Apache il reindirizzamento può essere configurato utilizzando le direttive AddHandler e
+ Action (vedere sotto).
+
+
+
+
+ Caso 2: utilizzo di <literal>cgi.force_redirect</literal>
+
+ La direttiva di configurazione cgi.force_redirect
+ impedisce a chiunque di richiamare direttamente php
+ tramite un URL come http://my.host/cgi-bin/php/secretdir/script.php.
+ Piuttosto, PHP interpreterà gli script soltanto se la richiesta
+ è passata attraverso una regola di reindirizzamento del server web.
+
+
+ Normalmente il reindirizzamento nella configurazione di Apache viene effettuato con
+ le seguenti direttive:
+
+
+
+
+
+ Questa opzione è stata testata soltanto con il server web Apache e
+ si basa sul fatto che Apache imposti la variabile d'ambiente CGI non standard
+ REDIRECT_STATUS per le richieste reindirizzate. Se il
+ server web non supporta alcun metodo per distinguere se una richiesta
+ è diretta o reindirizzata, questa opzione non può essere utilizzata ed è
+ necessario adottare uno degli altri metodi di esecuzione della versione CGI
+ documentati qui.
+
+
+
+
+ Caso 3: impostazione di doc_root o user_dir
+
+ L'inclusione di contenuti attivi, come script ed eseguibili, nelle
+ directory dei documenti del server web è talvolta considerata una pratica non sicura.
+ Se, a causa di un errore di configurazione, gli script
+ non vengono eseguiti ma visualizzati come normali documenti HTML, ciò
+ può comportare la divulgazione di proprietà intellettuale o di informazioni
+ sensibili, come le password. Per questo motivo molti amministratori di sistema
+ preferiscono predisporre una struttura di directory separata per gli script
+ accessibili esclusivamente tramite PHP CGI e quindi sempre
+ interpretati anziché visualizzati come tali.
+
+
+ Inoltre, se il metodo per garantire che le richieste non vengano
+ reindirizzate, come descritto nella sezione precedente, non è
+ disponibile, è necessario configurare una
+ doc_root per gli script diversa
+ dalla directory radice dei documenti del server web.
+
+
+ È possibile impostare la directory radice dei documenti degli script PHP tramite la
+ direttiva di configurazione doc_root nel
+ file di configurazione, oppure
+ impostando la variabile d'ambiente
+ PHP_DOCUMENT_ROOT. Se impostata, la versione CGI
+ di PHP costruirà sempre il nome del file da aprire utilizzando questa
+ doc_root e le informazioni sul percorso contenute nella
+ richiesta, così da garantire che nessuno script venga eseguito al di fuori di
+ questa directory (ad eccezione di user_dir
+ descritto di seguito).
+
+
+ Un'altra opzione utilizzabile è user_dir. Quando user_dir non è
+ impostato, l'unico elemento che determina il nome del file aperto è
+ doc_root. L'apertura di un URL come http://my.host/~user/doc.php non
+ comporta l'apertura di un file nella directory home dell'utente, bensì di un file
+ denominato ~user/doc.php all'interno di
+ doc_root (sì, una directory il cui nome inizia con una tilde
+ [~]).
+
+
+ Se user_dir è impostato, ad esempio, su public_php, una richiesta come http://my.host/~user/doc.php aprirà un
+ file denominato doc.php nella directory
+ public_php presente nella directory
+ home dell'utente. Se la home dell'utente è /home/user, il file eseguito sarà
+ /home/user/public_php/doc.php.
+
+
+ L'espansione di user_dir avviene indipendentemente
+ dall'impostazione di doc_root, consentendo così di controllare
+ separatamente la directory radice dei documenti e l'accesso alle directory
+ degli utenti.
+
+
+
+
+ Caso 4: parser PHP al di fuori dell'albero web
+
+ Un'opzione molto sicura consiste nel collocare il binario del parser PHP
+ in una posizione esterna all'albero dei file del server web. Ad esempio in
+ /usr/local/bin. L'unico vero
+ svantaggio di questa soluzione è che sarà necessario inserire una riga
+ simile alla seguente:
+
+
+
+
+
+ come prima riga di qualsiasi file contenente tag PHP. Sarà inoltre
+ necessario rendere il file eseguibile. In altre parole, dovrà essere trattato
+ esattamente come qualsiasi altro script CGI scritto in Perl, sh o in un
+ altro comune linguaggio di scripting che utilizzi il
+ meccanismo shell-escape #! per
+ avviarsi.
+
+
+ Per consentire a PHP di gestire correttamente le informazioni
+ PATH_INFO e PATH_TRANSLATED con questa
+ configurazione, è necessario abilitare la direttiva ini
+ cgi.discard_path.
+
+
+
+
+
+
diff --git a/security/database.xml b/security/database.xml
new file mode 100644
index 000000000..1b69433a1
--- /dev/null
+++ b/security/database.xml
@@ -0,0 +1,490 @@
+
+
+
+
+ Sicurezza del Database
+
+
+ Al giorno d'oggi, i database sono componenti essenziali di qualsiasi
+ applicazione basata sul Web, consentendo ai siti Web di fornire molti contenuti
+ dinamici. Poiché anche le informazioni sensibili o segrete possono
+ essere archiviate in un database, dovresti prendere seriamente in considerazione di
+ proteggere i tuoi database.
+
+
+ Per recuperare o archiviare qualsiasi informazione di cui hai bisogno per connetterti al database,
+ eseguire una query, recuperare il risultato e quindi chiudere la connessione.
+ Oggigiorno, il linguaggio più utilizzato per questo tipo di interazione è
+ l'SQL (Structured Query Language). Di seguito viene mostrato come un'aggressore può manometterlo con una query SQL.
+
+
+ Da come si può immaginare, PHP non può proteggere da solo il database.
+ Le prossime sezioni puntano a introdurre le modalità di come
+ accedere e manipolare ai database all'interno di uno script PHP.
+
+
+ Bisogna tener presente questa semplice regola: (Defense in Depth) difesa in profondità. Più prendi provvedimenti
+ per aumentare la sicurezza del database, minore è probabilità che un utente malintenzionato
+ riesca ad accedere o abusare di eventuali dati archiviati. Una buona progettazione
+ dello schema del database e dell'applicazione previene le tue più grandi paure.
+
+
+
+ Progettazione del database
+
+ Il primo passo è quello di creare il database, a meno che non si voglia utilizzarne uno
+ di terze parti. Una volta creato il database, viene assegnato un proprietario,
+ a chi ha eseguito l'istruzione di creazione. Di solito, solo il proprietario
+ (o l'amministratore) può fare qualsiasi cosa con gli oggetti di quel database e,
+ per consentire ad altri utenti di utilizzarlo, gli devono essere concessi dei privilegi.
+
+
+ Le applicazioni non dovrebbero mai connettersi al database come proprietario o
+ amministratore, poiché questi utenti possono eseguire qualsiasi query a piacimento,
+ ad esempio, potrebbero modificare lo schema (ad esempio eliminando le tabelle) o potrebbero
+ eliminare l'intero contenuto.
+
+
+ E' possibile creare vari utenti del database uno per ogni ruolo della tua applicazione
+ con diritti molto limitati sugli elementi del database. Dovrebbero essere concessi
+ solo i privilegi necessari per evitare che lo stesso utente possa modificare
+ il database tramite le diverse funzionalità. Ciò significa che se gli intrusi ottengono
+ l'accesso al tuo database utilizzando le credenziali delle tue applicazioni,
+ potrebbero apportare tutte le modifiche quante ne sono previste dai privilegi.
+
+
+
+
+ Connessione al database
+
+ E' possibile per una maggiore sicurezza stabilire connessioni SSL per criptare le
+ comunicazioni client/server oppure è possibile utilizzare SSH
+ per criptare la connessione di rete tra i client e il server del database.
+ Se viene utilizzato uno di questi sistemi, sarà difficile monitorare il traffico e ottenere
+ le informazioni del tuo database da parte di un potenziale malintenzionato.
+
+
+ Se il server del database ha il supporto nativo SSL, si può considerare l'uso delle funzioni OpenSSL per comunicazioni tra
+ PHP e database tramite SSL.
+
+
+
+
+ Modello d'archiviazione crittografato
+
+ SSL/SSH protegge i dati che viaggiano dal client al server: SSL/SSH
+ non protegge i dati persistenti archiviati in un database. SSL è un
+ protocollo on-the-wire.
+
+
+ Una volta che un utente malintenzionato ottiene l'accesso diretto al tuo database (aggirando il server web),
+ i dati sensibili memorizzati potrebbero essere esposti o utilizzati in modo improprio, a meno che
+ le informazioni siano protette dal database stesso. La crittografia dei dati
+ è un buon modo per limitare questa minaccia, ma pochissimi database offrono
+ questo tipo di crittografia dei dati.
+
+
+ Il modo più semplice per aggirare il problema è innanzitutto creare il proprio pacchetto di crittografia,
+ e quindi utilizzarlo nei tuoi script PHP. PHP
+ può aiutarti con diverse estensioni, come OpenSSL o Sodium, che impiega un'ampia varietà di algoritmi di crittografia.
+ Lo script cripta i dati prima di inserirli nel database e li decripta
+ durante il recupero. Vedere i riferimenti per ulteriori esempi
+ su come funziona la crittografia.
+
+
+
+ Hashing
+
+ Nel caso di dati veramente segreti , se non è necessaria la loro rappresentazione originale
+ (p.es. non dev'essere visualizzato), è necessario prendere in considerazione l'hashing.
+ Un'esempio ben noto di hashing
+ è il salvataggio dell'hash della password nel database,
+ invece della password stessa.
+
+
+ Le funzioni per le password
+ possono fornire un modo semplice per eseguire l'hashing dei dati sensibili e lavorare con questi hash.
+
+
+ password_hash viene utilizzato per eseguire l'hashing di una determinata stringa utilizzando
+ l'algoritmo più potente attualmente disponibile e password_verify
+ controlla se la password fornita corrisponde all'hash memorizzato nel database.
+
+
+ Campo per l'Hash della password
+
+
+
+]]>
+
+
+
+
+
+ SQL Injection
+
+ L'SQL injection è una tecnica dove un'utente malintenzionato sfrutta i difetti del
+ codice responsabile della creazione di query SQL dinamiche.
+ L'aggressore può accedere a sezioni privilegiate dell'applicazione,
+ recuperare tutte le informazioni dal database, manomettere i dati esistenti,
+ o addirittura eseguire comandi pericolosi a livello di sistema Host dul database.
+ La vulnerabilità si verifica quando gli sviluppatori concatenano o
+ interpolano dati arbitrari nelle loro istruzioni SQL.
+
+
+
+
+ Dividere il set di risultati in pagine ... e creare amministratori <!-- amministratori -->
+ (PostgreSQL)
+
+
+ Nell'esempio seguente, l'input dell'utente viene interpolato direttamente nella
+ Query SQL che consente all'aggressore di ottenere un account amministratore nel database.
+
+
+
+]]>
+
+
+ Di solito gli utenti usano i collegamenti "next", "previous" dove l'$offset
+ viene passato nell'URL. Lo script si aspetta che l'$offset
+ sia un numero. Tuttavia, cosa succede se qualcuno prova a craccarlo
+ aggiungendo quanto segue all'URL?
+
+
+
+
+
+ Se ciò dovesse accadere, lo script fornirebbe un accesso d'amministratore all'aggressore.
+ Tieni presente che 0; fornisce un offset valido alla query originale
+ e la terminerebbe.
+
+
+
+ Una tecnica comune per forzare il parser SQL a ignorare il resto della richiesta
+ query scritta dal programmatore è usare -- che introduce
+ i commenti in SQL.
+
+
+
+ Un modo possibile per ottenere le password è analizzare le pagine dei risultati di ricerca.
+ L'unica cosa che l'attaccante deve fare è vedere se sono presenti variabili inviate
+ utilizzate nelle istruzioni SQL che non vengono gestite correttamente. Questi filtri di solito possono essere impostati
+ in un form usato precedentemente e personalizzarlo usando le clausole WHERE, ORDER BY,
+ LIMIT e OFFSET nell'istruzione SELECT.
+ Se il database supporta il costrutto UNION,
+ l'aggressore potrebbe tentare di aggiungere un'intera query a quella originale per far elencare
+ le password da una tabella arbitraria. Si consiglia vivamente di salvare sole le secure hash delle password
+ anziché le password stesse.
+
+ Elencare gli articoli... e alcune password (può essere usato su qualunque database server).
+
+
+]]>
+
+
+ La parte statica della query può essere combinata con un'altra SELECT
+ per rivelare tutte le password:
+
+
+
+
+
+
+
+ Anche le istruzioni UPDATE e INSERT sono
+ suscettibili a tali attacchi.
+
+ Dalla reimpostazione di una password... all'acquisizione di più privilegi (per qualsiasi database server)
+
+
+]]>
+
+
+ Se un utente malintenzionato invia la stringa
+ per cambiare la password dell'amministratore
+ ' or uid like '%admin% in $uid
+ oppure impostare la variabile $pwd semplicemente con
+ hehehe', trusted=100, admin='yes per ottenere
+ privilegi più elevati, la query verrà aggirata:
+
+
+
+]]>
+
+
+
+
+ Mentre è scontato che un malintenzionato debba possederne almeno alcune nozioni
+ dell'architettura del database per condurre un'attacco ben riuscito ,
+ è spesso molto semplice ottenere queste informazioni. Per esempio,
+ il codice può far parte di un software open source ed essere disponibile al pubblico.
+ Tali informazioni potranno anche essere divulgate
+ tramite codice closed-source, anche se è codificato, offuscato o compilato -
+ e anche tramite il proprio codice attraverso la visualizzazione di messaggi di errore
+ Altri metodi includono l'uso di nomi di tabelle e colonne tipici. Per
+ ad esempio, un modulo d'accesso che utilizza una tabella "utenti" con nomi di colonne
+ "id", "username" e "password".
+
+
+
+
+ Attaccare il sistema operativo host del database (MSSQL Server)
+
+ Un preoccupante esempio di come è possibile accedere ai comandi a livello di sistema operativo
+ da parte di alcuni database su host.
+
+
+
+
+]]>
+
+
+ Se l'attaccante invia la stringa
+ a%' exec master..xp_cmdshell 'net user test testpass /ADD' --
+ a $prod, quindi $query sarà:
+
+
+
+]]>
+
+
+ MSSQL Server esegue le istruzioni SQL nel batch incluso un comando
+ per aggiungere un nuovo utente al database degli account locali. Se questa applicazione
+ era in esecuzione come sa e il servizio MSSQLSERVER era
+ in esecuzione con privilegi sufficienti, l'utente malintenzionato ora avrebbe un'account
+ con cui accedere a questa macchina.
+
+
+
+ Alcuni esempi sopra riportati sono legati ad uno specifico database, ma
+ non significa che un attacco simile sia impossibile verso altri prodotti.
+ Il tuo database potrebbe essere altrettanto vulnerabile in un altri modi.
+
+
+
+
+ Un esempio divertente dei problemi riguardanti SQL injection
+
+
+
+
+
+ Image courtesy of xkcd
+
+
+
+
+
+
+ Tecniche di elusione
+
+ Un modo consigliato per evitare l'SQL injection è associare tutti i dati
+ usando prepared-statements. L'utilizzo di query parametrizzate non è
+ sufficiente per evitare completamente l'injection SQL, ma è il modo più
+ semplice e sicuro per fornire l'input alle istruzioni SQL. Tutti i letterali
+ di dati dinamici nelle clausole WHERE,
+ SET e VALUES devono essere sostituiti
+ con un segnaposto. I dati effettivi verranno trasposti durante l'esecuzione e
+ inviati separatamente dal comando SQL.
+
+
+
+ Il binding dei parametri può essere utilizzato solo per i dati. Altre
+ parti dinamiche della query SQL devono essere filtrate in base a un elenco
+ noto di valori consentiti.
+
+
+
+ Eludere un'SQL injection usando PDO prepared Statement
+
+prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}");
+// Il valore è reso disponibile usando LIKE
+$stmt->execute(["%{$productId}%"]);
+
+?>
+]]>
+
+
+
+
+
+ I Prepared statement sono forniti da
+ PDO,
+ MySQLi,
+ e da altre librerie per database.
+
+
+
+ Gli attacchi SQL injection sfruttano principalmente il codice scritto
+ senza pensare alla sicurezza. Non fidarti mai di nessun input, specialmente
+ dal lato client, anche se proviene da un menu a tendina,
+ un campo di input nascosto o un cookie. Il primo esempio mostra che una query così
+ semplice può causare disastri.
+
+
+
+ Una strategia di difesa in-depth comporta diverse Best Practics di scrittura del codice:
+
+
+
+ Non connettersi mai al database come amministratore o come proprietario.
+ Utilizzare sempre appositi utenti con privilegi minimi.
+
+
+
+
+ Controlla se l'input fornito è del tipo di dati previsto. PHP ha
+ una vasta gamma di funzioni per la convalida dell'input, da quelle più semplici
+ che si trovano in Funzioni variabili e
+ in Funzioni tipo carattere
+ (es.: rispettivamente is_numeric e ctype_digit)
+ oltre al supporto per le Espressioni regolari compatibili con Perl.
+
+
+
+
+ Se l'applicazione prevede un input numerico, prendere in considerazione la verifica dei dati
+ con ctype_digit, modificare con discrezione il suo tipo
+ usando settype o formattare la sua rappresentazione numerica
+ con sprintf.
+
+
+
+
+ Se l'interfaccia del database non supporta il binding delle variabili, allora
+ va messo tra virgolette ogni valore non numerico fornito dall'utente che viene passato al
+ database con la specifica funzione di escape del database per le stringhe (ad esempio
+ mysql_real_escape_string,
+ sqlite_escape_string, ecc.).
+ Le funzioni generiche come addslashes sono utili solo
+ in un ambiente molto specifico (ad esempio MySQL in un set di caratteri a singolo byte
+ con NO_BACKSLASH_ESCAPES disabilitato) e quindi è
+ meglio evitarle.
+ mysql_real_escape_string,
+
+
+
+
+ Non far visualizare a qualunque costo le informazioni dettagliate del database
+ e in particolare la struttura . Vedere anche le sezioniSegnalazione degli errori e Funzioni di gestione e registrazione degli errori.
+
+
+
+
+
+
+ Oltre a ciò, puoi trarre vantaggio dal log delle query tramite il tuo script
+ o, se lo supporta, attraverso il database stesso. Ovviamente, il log non è in grado
+ di prevenire alcun tentativo d'attacco, ma può essere utile per capire quale
+ applicazione è stata colpita. Il registro non è utile di per sé, ma
+ sono utili le informazioni che contiene. Generalmente più dettagli ci sono nel log meglio è.
+
+
+
+
+
+
diff --git a/security/errors.xml b/security/errors.xml
new file mode 100644
index 000000000..59593b0ea
--- /dev/null
+++ b/security/errors.xml
@@ -0,0 +1,150 @@
+
+
+
+
+
+
+
+ Segnalazione degli errori
+
+ Dal punto di vista della sicurezza di PHP, ci sono due aspetti nella segnalazione degli errori. Uno è
+ utile per aumentarne la sicurezza, l’altro è dannoso.
+
+
+ Una tattica d'attacco di solito prevede la profiliazione di un sistema reperendo
+ dati dagli errori, dal controllo dei tipi e dai contesti degli
+ errori che vengono restituiti. Ciò consente al cracker del sistema di analizzare
+ le informazioni del server, per determinare possibili punti deboli.
+ Ad esempio, se un'utente malintenzionato avesse raccolto informazioni su una pagina
+ con l'invio di un modulo precedente, potrebbe tentare di sovrascrivere le
+ variabili o modificarle:
+
+ Attaccare le Variabili in una pagina HTML personalizzata
+
+
+
+
+
+]]>
+
+
+
+
+ Gli errori che vengono normalmente restituiti da PHP possono essere molto utili allo
+ sviluppatore che sta tentando di eseguire il debug di uno script, indicando quali
+ funzioni o file hanno avuto esito negativo, il file PHP
+ e il numero di riga in cui si è verificato l'errore. Queste sono tutte le
+ informazioni che possono essere visualizzate. Non è raro che in php
+ lo sviluppatore debba utilizzare show_source,
+ evidenzia_stringa, o
+ highlight_file come strumento di debug, ma in
+ un sito live, questo può esporre le variabili nascoste, sintassi non controllate,
+ e altre informazioni pericolose. Particolarmente pericoloso è far eseguire
+ codice da fonti conosciute con gestori di debug incorporati o utilizzando
+ tecniche comuni di debug. Se l'attaccante può determinare quale
+ tecnica conosciuta stai usando, potrebbero provare a forzare una pagina,
+ inviando varie stringhe di debug usate da queste tecniche:
+
+ Sfruttare le variabili di debug classiche
+
+
+
+
+
+
+]]>
+
+
+
+
+ Indipendentemente dal metodo di gestione degli errori, la capacità di sondare un
+ sistema tramite gli errori porta a fornire ad un'utente malintenzionato
+ più informazioni.
+
+
+ Ad esempio, lo stile di un errore PHP generico indica che un sistema
+ sta eseguendo PHP. Se l'aggressore stava guardando una pagina .html e
+ volevo sondare il back-end (per cercare punti deboli noti nel
+ sistema), fornendo dati errati che potrebbero essere in grado di
+ determinare che un sistema è stato creato con PHP.
+
+
+ L'errore di una funzione può indicare se un sistema sta eseguendo uno
+ specifico database engine o fornire indizi su come una specifica pagina web, è
+ programmata o progettata. Ciò consente un'indagine più approfondita per
+ aprire porte del database o cercare bug o punti deboli specifici
+ di una pagina web. Fornendo diversi dati errati, per esempio,
+ un utente malintenzionato può determinare l'ordine di autenticazione in uno script,
+ (dagli errori con il numero di riga) e cercare i vari exploit che
+ possono essere sfruttati nello script.
+
+
+ Un errore di filesystem o un'errore generale di PHP può indicare quali autorizzazioni
+ il server web ha, nonché la struttura e l'organizzazione dei
+ file sul server web. Il codice di errore scritto dallo sviluppatore può aggravare
+ questo problema, portando ad un facile reperimento delle informazioni
+ di risorse precedentemente "nascoste".
+
+
+ Esistono tre soluzioni principali a questo problema. Il primo è quello
+ esaminare attentamente tutte le funzioni e tentare di risolvere la maggior parte
+ degli errori. Il secondo è disabilitare completamente la segnalazione degli errori
+ nel codice di produzione. Il terzo consiste nell'utilizzare la funzione custom
+ della gestione degli errori di PHP per creare il proprio gestore di errori. A seconda
+ sulla tua politica di sicurezza, potresti riuscire ad applicare tutte e tre
+ le soluzioni alla tua situazione.
+
+
+ Un modo per impedire in anticipo questo problema è quello di utilizzare
+ error_reporting di PHP, può aiutarti a
+ proteggere il tuo codice e trovare vari utilizzi che potrebbero essere pericolosi.
+ Testando il tuo codice, prima della distribuzione, con E_ALL,
+ puoi trovare rapidamente le aree in cui le tue variabili potrebbero essere
+ esposte all'inquinamento o alla modifica. Una volta pronto per la distribuzione,
+ dovresti disabilitare completamente la segnalazione degli errori impostando
+ error_reporting su 0 o disattivare l'opzione di visualizzazione
+ dell'errore nel file &php.ini; display_errors,
+ per isolare il codice dall'analisi(). Se scegli di applicare quest'ultima soluzione,
+ dovresti anche definire il percorso al tuo file registro usando il file
+ error_log e attivare nella direttiva ini
+ log_errors.
+
+ Trovare variabili pericolose con E_ALL
+
+
+]]>
+
+
+
+
+
+
diff --git a/security/filesystem.xml b/security/filesystem.xml
new file mode 100644
index 000000000..6557913a6
--- /dev/null
+++ b/security/filesystem.xml
@@ -0,0 +1,235 @@
+
+
+
+
+
+ Sicurezza del Filesystem
+
+ PHP dipende dalla gestione della sicurezza di molti sistemi server che usano
+ i permessi basati su file e directory. Ciò consente
+ di controllare quali file nel filesystem possono essere letti. Si dovrebbe prestare attenzione
+ a tutti i file che sono pubblici per garantire
+ che siano sicuri in lettura da parte degli utenti che hanno accesso a quel
+ file system.
+
+
+ Poiché PHP è stato progettato per consentire l'accesso a livello utente al file system,
+ potrebbe essere possibile scrivere uno script PHP che ti consenta
+ di leggere file di sistema come /etc/passwd, modificare le connessioni ethernet,
+ inviare enormi documenti in stampa, ecc. Questo suggerisce alcune
+ ovvie implicazioni, in quanto devi assicurarti che i file
+ da cui leggi e su cui scrivi siano quelli appropriati.
+
+
+ Considerate il seguente script, dove l'utente indica che vorrebbe
+ eliminare un file nella propria directory home. Ciò presuppone una
+ situazione in cui un'interfaccia web PHP viene regolarmente utilizzata per la
+ gestione dei file, quindi all'utente Apache è consentito eliminare i file nelle
+ directory home dell'utente.
+
+
+
+ Un controllo non accurato di una variabile porta a...
+
+
+]]>
+
+
+ Poiché il nome utente e il nome file possono essere inviati da un form,
+ possono inviare un nome utente e un nome file appartenenti a un'altro utente,
+ ed eliminarli anche se non dovrebbero essere autorizzati a farlo.
+ In questo caso, dovresti usare un'altra forma di autenticazione.
+ Considera cosa potrebbe accadere se le variabili inviate fossero
+ "../etc/" e "passwd".
+ Il codice quindi leggerebbe effettivamente:
+
+ ... un'attacco al filesystem
+
+
+]]>
+
+
+ Ci sono due misure importanti che dovresti adottare per prevenire questi problemi.
+
+
+
+ Consentire solo autorizzazioni limitate ai file binari da parte dell'utente web PHP.
+
+
+
+
+ Controllare tutte le variabili inviate.
+
+
+
+ Ecco uno script migliorato:
+
+ Controllo più sicuro dei nomi dei file
+
+
+]]>
+
+
+ Tuttavia, anche questo non è privo di difetti. Se il tuo sistema di autenticazione
+ consentiva agli utenti di creare i propri accessi e un'altro utente
+ voleva accedere a "../etc/", il sistema è nuovamente esposto. Per
+ questo motivo, potresti preferire scrivere un controllo più personalizzato:
+
+ Controllo più sicuro dei nomi dei file
+
+
+]]>
+
+
+
+
+ A seconda del sistema operativo, esiste un'ampia varietà di file
+ di cui dovresti preoccuparti, tra cui nomi di risorse (/dev/
+ o COM1), file di configurazione (file /etc/ e
+ file .ini), cartelle di archiviazione classiche (/home/,
+ My Documents), ecc. Per questo
+ motivo, di solito è più facile creare una policy in cui proibisci tutto tranne ciò che consenti esplicitamente.
+
+
+ Problemi relativi ai valori NULL
+
+ Poiché PHP utilizza le funzioni derivate da C per le operazioni correlate
+ al file system, potrebbero gestire i valori NULL in un modo del tutto inaspettato.
+ Poiché i valori NULL indicano la fine di una stringa in C, le stringhe che li contengono
+ non saranno valutate nella loro interezza, ma solo finché non incontreranno un valore NULL.
+
+ Il seguente fa vedere un codice vulnerabile che mostra questo problema:
+
+
+ Script vulnerabile ai valori NULL
+
+
+]]>
+
+
+
+ Pertanto, qualsiasi stringa contaminata utilizzata in un'operazione sul file system dovrebbe sempre
+ essere convalidata correttamente. Ecco una versione migliore dell'esempio precedente:
+
+
+ Convalida corretta dell'input
+
+
+]]>
+
+
+
+
+
+
+
diff --git a/security/general.xml b/security/general.xml
new file mode 100644
index 000000000..d86f4c617
--- /dev/null
+++ b/security/general.xml
@@ -0,0 +1,72 @@
+
+
+
+
+
+ Considerazioni Generali
+
+ Un sistema completamente sicuro è virtualmente impossibile, quindi un
+ approccio spesso utilizzato nella professione della sicurezza è quello
+ di bilanciare rischio e usabilità. Se ogni variabile inviata da un
+ utente richiedesse due forme di convalida biometrica (come una scansione
+ della retina e un'impronta digitale), si avrebbe un livello di identificazione
+ estremamente elevato. Ci vorrebbe anche mezz'ora per compilare un modulo abbastanza
+ complesso, il che porterebbe a incoraggiare gli utenti a trovare dei modi per
+ aggirare la sicurezza.
+
+
+ La migliore sicurezza è spesso abbastanza discreta da soddisfare
+ i requisiti senza che all'utente gli venga impedito di svolgere il proprio
+ lavoro o caricare troppo l'autore del codice con un'eccessiva complessità.
+ In effetti, alcuni attacchi alla sicurezza sono semplicemente degli exploit di
+ questo tipo di sicurezza eccessivamente complessa, che tende a perdersi nel tempo.
+
+
+ Una frase che vale la pena ricordare: un sistema è valido quanto l'anello più debole
+ di una catena. Se tutte le transazioni vengono registrate in modo massiccio in base a
+ ora, posizione, tipo di transazione, ecc. ma l'utente viene verificato solo in base a
+ un singolo cookie, la validità del collegamento degli utenti
+ al log degli accessi è gravemente compromessa.
+
+
+ Quando esegui un test, tieni presente che non sarai in grado di testare tutte le
+ casistiche, nemmeno per la più semplice delle pagine. L'input che
+ potresti aspettarti sarà completamente diverso dall'input fornito da
+ un dipendente insoddisfatto, un cracker con mesi di tempo libero o un gatto
+ che cammina sulla tastiera. Ecco perché è
+ meglio guardare il codice da una prospettiva logica, per discernere
+ dove possono essere introdotti dati imprevisti e quindi seguire come vengono
+ modificati, ridotti o amplificati.
+
+
+ Internet è pieno di persone che cercano di diventare famosi
+ violando il tuo codice, mandando in crash il tuo sito, pubblicando
+ contenuti inappropriati e rendendoti la giornata interessante in altri modi.
+ Non importa se hai un sito grande o piccolo, sei
+ un bersaglio semplicemente perché sei online, perché hai un server a cui
+ puoi connetterti. Molti programmi di cracking non distinguono le dimensioni del bersaglio,
+ semplicemente analizzano enormi blocchi di IP alla ricerca di vittime. Cerca di non
+ diventarne uno.
+
+
+
+
diff --git a/security/hiding.xml b/security/hiding.xml
new file mode 100644
index 000000000..f1ba05db2
--- /dev/null
+++ b/security/hiding.xml
@@ -0,0 +1,78 @@
+
+
+
+
+
+ Hiding PHP
+
+ In generale, la sicurezza tramite l'occultamento è una delle forme di sicurezza più deboli.
+ Ma in alcuni casi, ogni piccolo briciolo di sicurezza in più è benvenuto.
+
+
+ Alcune semplici tecniche possono aiutare a nascondere PHP, rallentando
+ eventualmente un aggressore che sta tentando di scoprire debolezze nel tuo
+ sistema. Impostando exhibit_php su off nel tuo
+ file &php.ini;, riduci la quantità di informazioni a loro disposizione.
+
+
+ Un'altra tattica è quella di configurare il server Web come Apache per
+ analizzare diversi tipi di file tramite PHP, con una direttiva &htaccess;
+ o nel file di configurazione di Apache. Puoi quindi
+ utilizzare estensioni di file falsi:
+
+ Nascondere PHP come se fosse un altro linguaggio
+
+
+
+
+ O lo nasconde completamente:
+
+ Using unknown types for PHP extensions
+
+
+
+
+ Oppure nasconderlo come codice HTML, ma questo fa si avrà un leggero calo di prestazioni perché
+ tutto l'HTML verrà processato tramite il motore di PHP:
+
+ Usando <acronym>HTML</acronym> come se fosse l'estensione di PHP
+
+
+
+
+ Per far funzionare tutto in modo efficace, devi rinominare i tuoi file PHP con
+ le estensioni di cui sopra. Sebbene sia una forma di sicurezza attraverso
+ l'occultamento, è una misura preventiva minore con pochi inconvenienti.
+
+
+
+
+
diff --git a/security/intro.xml b/security/intro.xml
new file mode 100644
index 000000000..ef11cf478
--- /dev/null
+++ b/security/intro.xml
@@ -0,0 +1,59 @@
+
+
+
+
+
+ Introduzione
+
+ PHP è un linguaggio potente e l'interprete, che sia incluso in un server web come modulo o eseguito come binario separato
+ CGI, è in grado di accedere ai file, eseguire
+ comandi e aprire connessioni di rete sul server. Queste
+ proprietà rendono qualsiasi cosa eseguita su un server web non sicura per default.
+ PHP è progettato specificamente per essere un linguaggio più sicuro per
+ scrivere programmi CGI rispetto a Perl o C e, con la corretta configurazione
+ in fase di compilazione e runtime e le corrette pratiche di codifica, può darti
+ giusta combinazione di libertà e sicurezza di cui hai bisogno.
+
+
+ Poiché ci sono molti modi per utilizzare PHP, ci sono molte opzioni
+ di configurazione che ne controllano il comportamento. Un'ampia selezione
+ di opzioni garantisce che puoi utilizzare PHP per diversi scopi, ma significa
+ anche che ci sono possibili configurazioni del server
+ che risultano non sicure.
+
+
+ La flessibilità di configurazione di PHP è pari alla flessibilità del codice.
+ PHP può essere utilizzato per creare applicazioni server
+ complete, con tutta la potenza di una shell, oppure può essere utilizzato
+ per semplici Server Side Include con pochi rischi e in un ambiente strettamente
+ controllato. Il modo in cui si crea quell'ambiente e quanto sia
+ sicuro, dipende in gran parte dallo sviluppatore PHP.
+
+
+ Questo capitolo inizia con alcuni consigli generali sulla sicurezza, spiega
+ le diverse combinazioni di configurazione e le situazioni
+ in cui possono essere utilizzate in modo sicuro e descrive diverse considerazioni nella
+ codifica per diversi livelli di sicurezza.
+
+
+
+
diff --git a/security/sessions.xml b/security/sessions.xml
new file mode 100644
index 000000000..6328797a6
--- /dev/null
+++ b/security/sessions.xml
@@ -0,0 +1,34 @@
+
+
+
+ Sicurezza della sessione
+
+
+ È importante mantenere sicura la gestione delle sessioni HTTP.
+ La sicurezza relativa alle sessioni è descritta nella sezione
+ Sessione e Sicurezza
+ del riferimento Gestione delle sessioni.
+
+
+
+
+
diff --git a/security/variables.xml b/security/variables.xml
new file mode 100644
index 000000000..fa73cb3a9
--- /dev/null
+++ b/security/variables.xml
@@ -0,0 +1,118 @@
+
+
+
+
+
+
+
+
+ Dati inviati dall'utente
+
+ La più grande debolezza di molti programmi scritti in PHP
+ non è insita nel linguaggio, ma semplicemente un problema di codice scritto
+ non tenendo a mente la sicurezza. Per questo motivo, dovresti sempre prenderti
+ il tempo di considerare le implicazioni di una certa parte di codice, per
+ accertare il possibile malfunzionamento se gli viene inviata una variabile
+ inaspettata.
+
+ Utilizzo pericoloso delle variabili
+
+
+]]>
+
+
+
+
+ Bisognerebbe esaminare attentamente il codice per assicurarci
+ che tutte le variabili inviate da un browser web siano state correttamente
+ controllate e porsi le seguenti domande:
+
+
+
+ Questo script avrà effetto solo sui file previsti?
+
+
+
+
+ Può un dato indesiderato o inusuale interferire con il funzionamento?
+
+
+
+
+ Questo script può essere utilizzato in modi non previsti?
+
+
+
+
+ Può essere usato insieme ad altri script in modo dannoso?
+
+
+
+
+ Le transazioni verranno adeguatamente tracciate?
+
+
+
+
+
+ Ponendosi queste domande durante la scrittura dello script,
+ piuttosto che farsele dopo, si previene una difficile riscrittura quando
+ invece si ha bisogno di migliorarne la sicurezza. Iniziando a usare queste
+ regole, non si garantisce la sicurezza del sistema, ma si può contribuire a
+ migliorarlo.
+
+
+ Migliorare la sicurezza disabilitando le impostazioni utili per nascondere
+ l'origine dei dati, la validità o l'integrità dell'input. La creazione di variabili implicite e
+ l'input incontrollato può portare a vulnerabilità come attacchi di injection e
+ manipolazione dei dati.
+
+
+ Funzionalità come register_globals e
+ magic_quotes (entrambi rimossi in PHP 5.4.0) hanno contribuito
+ ad agevolare questi rischi creando automaticamente variabili dall'input dell'utente e
+ escape dai dati in modo incoerente. Sebbene queste funzioni non siano più in PHP, persistono rischi simili
+ se la gestione dell'input è gestita in modo errato.
+
+
+ Abilitare error_reporting(E_ALL)
+ aiuta a rilevare le variabili non inizializzate e a convalidare l'input. Utilizzare la modalità strict
+ (declare(strict_types=1),
+ introdotto in PHP 7) per garantire la sicurezza dei tipi, prevenire conversioni involontarie,
+ e migliorare la sicurezza generale.
+
+
+
+