PHPBlog.it » sicurezza

Creare random password user friendly

Daniel — Mon, 17 Nov 2008 06:00:56 +0000

Quello delle password è un tema che offre sempre spunti di riflessione sul come agire al meglio per offrire un prodotto migliore. La generazione di password random è una pratica molto diffusa su molti sistemi e rappresenta l’approccio principale per il primo passo nel flusso di registrazione dell’utente ad un servizio. Questa password random spesso però non tiene conto delle possibili difficoltà che l’utente può incontrare nel leggerla: pensate solo alla somiglianza di caratteri come “l e I” o “O e 0″ che in base al font utilizzato possono essere più o meno simili.

Craig Anderson affronta il problema su SitePoint offrendo il suo punto di vista ed una possibile soluzione.

Password: questione di sicurezza

Daniel — Fri, 17 Oct 2008 05:00:55 +0000

La password è forse il sistema di sicurezza più utlizzato sul web per la difesa dei dati degli utenti. Ad ogni profilo, utente, cliente corrispondono uno username ed una password per limitare l’accesso ai dati ed alle funzionalità ad esso associati. Tuttavia può spesso capitare che la sicurezza fornita dall’accoppiata username/password non sia all’altezza auspicata dagli sviluppatori mettendo a rischio i dati e l’applicazione stessa. Come? Molto semplice: pippo/pippo o nome/cognome vi dicono niente? L’utente per pigrizia utilizzerà una password reciclata, magari semplice e corta cosa che implica un basso grado di sicurezza: l’alfanumerico di almeno 6 caratteri sarà un miraggio.

Per questo motivo in un progetto che sto affrontando in questo periodo ho deciso che l’utente non potrà agire direttamente sulla password ma sarà sempre il sistema ad occuparsene. Al momento della registrazione verrà creata una password comunicata all’utente via mail (caratteri alfanumerici); in caso di smarrimento l’utente potrà richiedere una nuova password con relativo reset della precedente dovuto al fatto che la password non verrà memorizzata in chiaro sul database.

L’approccio non è certo rivoluzionario, tuttavia in molte applicazioni la gestione password è diversa e lascia più libertà all’utente andando a dare spazio quindi ai problemi visti in precedenza.

Come criptare i nostri scripts in PHP – Zend Guard

Davide Martignetti — Wed, 15 Oct 2008 05:00:13 +0000

Questo articolo è un approfondimento di “Offuscare o proteggere il nostro codice PHP – Introduzione“, analizzeremo le funzionalità, i pregi ed i difetti di Zend Guard al fine di criptare uno script PHP.
Zend Guard non è l’unico programma che permette di cifrare uno script in PHP, per la lista completa vi rimando a Offuscare o proteggere il nostro codice PHP – Introduzione.

Zend Guard

Zend Guard è senz’altro il più usato strumento a pagamento ( 600$ ) che permette di criptare i files PHP, forse perchè si integra perfettamente nell’interfaccia di Zend Studio, usandolo potrete anche creare delle licenze per i vostri prodotti, l’interfaccia è semplice ed intuitiva così come la sua installazione. Per usare Zend Guard è però necessario avere installato sul nostro webserver Zend Optimizer (Zend Optimizer è gratuito).
Seppur il più usato Zend Guard non è di certo lo strumento più sicuro al quale affidare i nostri script. Esistono vari servizi gratuiti e a pagamento offerti dalla comunità online, di questi, però, troviamo online solamente quelli a pagamento: primo fra tutti Zend Decode ( 50$ – per PHP4 e PHP5, solo per Windows ).
Per provare Zend Guard scaricate ed installate Zend Guard [
Scarica ] ed anche Zend Optimizer [ Scarica - Quando lo si installa fare molta attenzione a non premere invio senza curarsi di ciò che ci viene chiesto perchè è molto importante configurarlo correttamente! ].

Ecco come si presenta un semplicissimo script prima e dopo essere stato criptato ( ho usato la versione demo ):

Prima

[source:Php] function isOnline($address=”localhost”, $port=”80″, $timeout=”1″)
{
@$fp=fsockopen($address,$port,$err_no,$errstr,$timeout);
if($fp)
{
return 1;
fclose($fp);
}
else
{
echo “Errore numero $err_no: $errstr\n”;
return 0;
}
}
?>[/source]

Dopo

[source:Php] 4123;
/* ñ!This is not a text file!Þí */
print <<

Zend Optimizer not installed

This file was encoded by the Zend Guard. In order to run it, please install the Zend Optimizer (available without charge), version 3.0.0 or later.

Seeing this message instead of the website you expected?

This means that this webserver is not configured correctly. In order to view this website properly, please contact the website’s system administrator/webmaster with the following message:The component “Zend Optimizer” is not installed on the Web Server and therefore cannot service encoded files. Please download and install the Zend Optimizer (available without charge) on the Web Server.Note: Zend Technologies cannot resolve issues related to this message appearing on websites not belonging to Zend Technologies.

What is the Zend Optimizer?

The Zend Optimizer is one of the most popular PHP plugins for performance-improvement, and has been available without charge, since the early days of PHP 4. It improves performance by scanning PHP’s intermediate code and passing it through multiple Optimization Passes to replace inefficient code patterns with more efficient code blocks. The replaced code blocks perform exactly the same operations as the original code, only faster.

In addition to improving performance, the Zend Optimizer also enables PHP to transparently load files encoded by the Zend Guard.

The Zend Optimizer is a free product available for download from Zend Technologies. Zend Technologies also developed the PHP scripting engine, known as the Zend Engine.

EOM;
exit();
__halt_compiler();
?>
200407220335061262xù
Ÿ2}W½N#1ö!t‚,Ez„Ñƒvìõ=5=Wœ¢Ä›5ò&Å=Â½/Á# ^€Ž’††‚’@ºæüŸÍÖÍ|ãÙùÆóc»æ©šéè¼qƒÆØa:×Z`_ÊJÉ¬f%a˜2iŠ¿LW‹ÅŸÓñtjœq‰fž\ëÕ@)¥ Bº[ïlRëVœ#’k„ûT‹þ×’w™{/‘ÒøzÜÚWÃS~ú$š·º©çŠ©.¬àÂœ
ñïè¨¶õ.ìBISÈ´Y†# ö8ZÎJ¯ºB_n…ð¯aüq¦òù~o©õd\_év‡åÑ0„<éâ¬‹‘Hõ}žwI‰d%@u^w¾
uêoÊé¸-³ÝžFµ‹ÜIÀ5Ö‡m~Žð0Ã¸?d˜D˜táÃW®¶Ã8Â´ßïvî»rMÏ¿#_zô0šÝl2;ö/ÈÌ¼5‘ÐbëààmvŒÇRº91Cÿ¾Ë[èŒÿÓ¢BçÆh£FÍj¡Œm$2Fw(öÓ£ãMkvõ
¼uâüÙÀSÏ€}Úö4{„z&HÞ°É…ÈÐ:çö Â5ƒP^Ì¡”Øö˜Ny
(ã¸â üneÌïF )'„b^Ea»4N(JV²Š#ò¤’Àyjîÿrý—Ä
[/source]

Se volete provare il programma dovete creare un nuovo progetto seguendo le istruzioni, una volta creato vi comparirà una schermata, sulla destra della sezione centrale cliccate sull’opzione “Encode project”, vi troverete il file criptato nella path specificata alla voce “Output Location”.

Conclusioni: Il programma è caro, richiede zend optimizer installato sul webserver e la protezione è facilmente aggirabile, a mio parere esistono alternative più valide e più economiche .

Come criptare i nostri scripts in PHP – Source Guardian

Davide Martignetti — Wed, 08 Oct 2008 05:00:09 +0000

Questo articolo è un approfondimento di “Offuscare o proteggere il nostro codice PHP – Introduzione“, analizzeremo le funzionalità, i pregi ed i difetti di Zend Guard al fine di criptare uno script PHP.
Source Guardian non è l’unico programma che permette di cifrare uno script in PHP, per la lista completa vi rimando a Offuscare o proteggere il nostro codice PHP – Introduzione.

Source Guardian

Source Guardian (250$, windows, linux, mac), tramite un’interfaccia che lascia un po’ a desiderare vi permette di criptare il vostro codice. Il primo approcio con la versione Demo è stato ottimo, l’interfaccia scarna del programma è compensata da una semplicità di utilizzo veramente alta. Con pochi clicks guidati potremo visualizzare il nostro sorgente criptato.

I nodi giungono però al pettine dopo poco tempo: al momento dell’esecuzione dello script comparirà la richiesta di installazione di Source Guardian loader, dopo una ricerca un po’ macchinosa sono giunto ad una pagina (nei files di installazione di source guardian) che spiega come effettuarne l’installazione:

Prima

[source:php]
function isOnline($address=”localhost”, $port=”80″, $timeout=”1″)
{
@$fp=fsockopen($address,$port,$err_no,$errstr,$timeout);
if($fp)
{
return 1;
fclose($fp);
}
else
{
echo “Errore numero $err_no: $errstr\n”;
return 0;
}
}
?>[/source]

Dopo

[source:php] if(!function_exists(‘sg_load’)){$__v=phpversion();$__u=strtolower(substr(php_uname(),0,3));$__f=$__f0=’ixed.’.substr($__v,0,strpos($__v,’.',3)).’ev.’.$__u;$__ff=$__ff0=’ixed.’.$__v.’ev.’.$__u;$__ed=ini_get(‘extension_dir’);if(!$__e=realpath($__ed)) die(‘extension_dir does not exists ‘.$__ed);if(file_exists($__e.’/’.$__ff)) dl($__ff);else if(file_exists($__e.’/’.$__f)) dl($__f);else {$__d=getcwd();if(@$__d[1]==’:'){$__d=str_replace(‘\\’,'/’,substr($__d,2));$__e=str_replace(‘\\’,'/’,substr($__e,2));}$__e.=($__h=str_repeat(‘/..’,substr_count($__e,’/')));$__f=’/ixed/’.$__f;$__ff=’/ixed/’.$__ff;while(!file_exists($__e.$__d.$__ff) && !file_exists($__e.$__d.$__f) && strlen($__d)>1){$__d=dirname($__d);}if (file_exists($__e.$__d.$__ff)) dl($__h.$__d.$__ff);else if (file_exists($__e.$__d.$__f)) dl($__h.$__d.$__f);}if(!function_exists(‘sg_load’)){die(‘PHP script ’.__FILE__.’ is protected by SourceGuardian and requires the SourceGuardian loader ’.$__f0.’. The SourceGuardian loader has not been installed, or is not installed correctly. Please find the required loader in the ixed subdirectory within your SourceGuardian installation directory.’);exit();}}return sg_load(‘AAQAAAAMAAAABHAAAACABAAAAAAAAAD/MPqWt4A0hGDqoOPTsBY0RZWEFiSW1kqExXhlpjyQDLwnMRC8v35pX6HyAI+7v3Ow8PdnvlntxY0OSjK47/S16KIMnwGoGnn+RS3NZU/IK+RUOGKterxnfOUmdRO7scw5higAnljyrSheIJ9xpznOtXu84okXfng7KaDUJVHQTnexmk67Hv9lmlTeB3qs7S2poluC+X9Orbf3jJUB81Fxq+mlXpAQ6vnsFPbcagkOm1jByfXqIif7NlZDTYjACjsYlN3SYQbDICuZrHrMp5wNgl+SFXGQ4FYaazeuCL3KTKGSOTPN/U4NVJuEl21MhJ+bfETcmKxSaEI4TjGgrp2PjKNelGWkrKCj7zrBo+UrOBXQaKjFvizt1t4pxNNEiKykkyTDN1X0v0+ivxOqBkIjX4hnR0NJpQ0rsdFN5EnnRJsgbxQIsmGHz+fDvPtuOZNenYtFl4/NKnlOJd9GAcnzUW2Vwnw6WsQ7jIERVeXy5m1720krTsE+DutbBGFe8kHgaXUXtUU0S9b8TwIk7rBkDkiOaITzGKdT+Rk7Xw4p8DEjOFDWZ0IA1IJflsNZuN1WZilX8m05xJzni+bc8fmWdHsblHnKtFKdUylX01gONZ11uSHWPMJoGEcp7uGBTGenLrt5AYUHUisEMjXU1muZi0ipz3DybGtaWVwDuQ59tTVGPViyVzXrPoV5dQTPTyY8zXW7xqEtkQBB5wLAcJo5IYJrjEjWS7M8WkssAf+Ib/eyI2JClqqd/ij2eRtd6XekeuQH5VjoenL5QNnP2QklrkncXzlNK4cwhvRy9sj2Zp11zBAcBWL0Ws7V80Sx/LAZf0frzxSwP0co5kWwf/OSDmNITmCWP8z2gXSu1ApmraB4664UdYxPUHTft8fUjaB5′);
?>[/source]

Conclusioni: Source Guardian è un po’ difficile da installare, ha un’interfaccia che di certo non è delle migliori ma pare che decifrare il codice sia più complicato. E’ anche vero che costa molto meno di Zend Guard.

Diamo l’addio a PHP4

Daniel — Fri, 08 Aug 2008 05:00:17 +0000

Oggi è il giorno dell’addio a PHP4. E’ arrivato la fatidica data 08/08/08, giorno in cui la versione 4 di PHP viene definitivamente abbandonata: non verranno più rilasciati nemmeno aggiornamenti sulla sicurezza. Proprio ieri è stata rilasciata l’ultima release di PHP4 con la versione 4.4.9 di cui potete leggere il changelog direttamente sul sito ufficiale.Se quindi non avete ancora fatto il salto verso PHP5 è vivamente consigliato fare l’aggiornamento a quest’ultima release (4.4.9) e pianificare poi abbastanza in fretta il passaggio alla versione successiva aggiornando le vostre macchine prima di andare incontro spiacevoli inconveniente.

Offuscare o proteggere il nostro codice PHP – Introduzione

Davide Martignetti — Mon, 21 Jul 2008 05:00:23 +0000

Attenzione: Questo articolo è un’introduzione alle possibili soluzioni adottabili per offuscare il nostro codice, le varie soluzioni saranno approfondite in una serie di articoli successivi.

Penso che molti programmatori PHP sarebbero contenti di poter proteggere il loro codice da sguardi indiscreti o da utilizzi non autorizzati.
Si pensi per esempio a quando si realizza una bozza di un progetto, sareste contenti di sapere che il committente lo distribuisce a vostra insaputa? A me no di certo. Potremmo ospitare la bozza su un nostro server senza consegnare il codice, potremmo anche rimuovere il progetto dopo la sua analisi da parte del cliente, ma se ciò non fosse possibile per motivi di stile o per altri motivi dovremmo affidarci ad altre tecniche.

Esistono due principali metodi che ci permettono di proteggere il nostro codice, attenzione però: il livello di protezione non è mai totale (è cioè sempre possibile aggirare il metodo di protezione per ottenere il sorgente dello script) ma con un po’ di fortuna riusciremo ad allontanare il nostro codice da sguardi indiscreti, eccoli:

Il primo metodo è molto semplice: nominare le variabili in modo da renderle simili fra loro, rimuovere gli spazi e non andare a capo, come nell’esempio (non testato), che vi fa capire in linea di massima ciò che intendo:

[source:Php]
$mysql_address=”localhost”;
$mysql_username=”root”;
$mysql_password=”";
$mysql_database=”mio_database”;
$mysql_connessione=mysql_connect($mysql_address,$mysql_username,$mysql_password);
mysql_select_db($mysql_database,$mysql_connessione);
$query=”SELECT * FROM $mysql_database.visite WHERE data=’19910429′”;
$risultato=mysql_query($query, $mysql_connessione);
$quanti=mysql_num_rows($risultato);
echo “il 29 aprile 1991 sono venuti a trovarci $quanti visitatori!”;
mysql_close($mysql_connessione);
?>
[/source]
Questo diventerà
[source:Php]

[/source]

Esistono software come PHP Obfuscator (nell’immagine di questo articolo) che automatizzano il processo di sostituzione.

Un utente esperto sarà indubbiamente in grado di risalire al codice originale in poco tempo: il livello di protezione di questa soluzione è proporzionale alla sua facilità d’uso, cioè basilare. E’ però vero che potremo utilizzare lo script senza dover installare alcun software aggiuntivo, e questo è davvero un bel vantaggio.

Non vi preoccupate se l’efficacia del metodo precedentemente descritto non vi soddisfa: esiste un secondo metodo: utilizzare software progettati per gestire la protezione (quella seria) del nostro codice (come Zend Guard).
Come funzionano questi software? E’ bene aver presente la strada che percorre il nostro script prima di tornare nel browser: esso infatti, dopo essere stato riconosciuto in una pagina, viene interpretato e successivamente viene restituito l’output che verrà caricato all’interno della pagina. Il riconoscimento dei frammenti di codice avviene tramite la ricerca dei tags php (in genere ), dopo aver riconosciuto il codice esso viene trasformato in linguaggio macchina, ecco il problema: il codice PHP deve essere “puro”, ovvero non cifrato per essere comprensibile! I software che si occupano di cifrare e poi decifrare il codice (l’analisi ed il giudizio di questi saranno il tema di una serie di articoli che approfondiranno l’argomento) inseriscono un controllo del sorgente tra la fase di riconoscimento del codice e quella di trasformazione in linguaggio macchina, se il controllo troverà files cifrati li trasformerà nel linguaggio comprensibile dal compilatore, ovvero quello “puro”. Attenzione però: non tutti i servizi di hosting offrono la possibilità di utilizzare queste soluzioni.

Indice: Introduzione

Generare password casuali

Daniel — Mon, 18 Feb 2008 06:00:47 +0000

In tutte le applicazioni che richiedono l’autenticazione da parte degli utenti un ruolo fondamentale per quanto riguarda la sicurezza dell’intero sistema è rappresentato dalla password inserita. Molte volte (se non nella totalità dei casi) lasciare all’utente la gestione completa della propria password è fonte di rischio visto che per semplice pigrizia l’utente medio utilizza spesso la stessa parola chiave sicuramente appartenente alla tipologia che possiamo definire debole: il proprio nome, date di nascita, parole estremamente corte. Oggi quindi presento una semplice classe per la generazione di password casuali scritta in PHP5.

Una strada per innalzare la sicurezza della propria applicazione e dell’intero sistema è quella di fornire all’utente una password creata dal sistema seguendo un determinato criterio con l’intento di rispettare quelli che sono i requisiti minimi per una password sicura. Vogliamo quindi utilizzare:

un insieme di caratteri alfabetici maiuscoli e minuscoli
un insieme di numeri

La classe che vediamo di seguito è molto semplice prende 2 valori in input length e numbers che indicano rispettivamente la lunghezza totale della password ed il numero di cifre intendiamo inserire nella stringa che andiamo a generare. E’ costituita dal costruttore che si occupa di creare l’oggetto al momento dell’istanziazione della classe e dal metodo getPassword() che si occupa dell’elaborazione vera e propria dell’input per la generazione dell’output: la password.

Il costruttore si occupa appunto di costruire l’oggetto facendo le dovute verifiche sui tipi, di cui abbiamo parlato in un post precedente, ed agendo in base alla situazione che si verifica.

public function __construct($length, $numbers) { if (!is_int($length) || !is_int($numbers)) { die("randoPassword() richiede argomenti di tipo intero\n"); } if ($length < $numbers) { die("length deve essere maggiore di numbers\n"); } $this->length = $length; $this->numbers = $numbers; }

Come anticipato il metodo getPassword() si occupa del lavoro vero e proprio, vediamo quindi come si comporta. Innanzitutto andiamo ad inserire nell’array random_char un numero di caratteri alfabetici presi da $alphabet pari al valore di $length meno il valore di $numbers. In secondo luogo aggiungiamo dei caratteri numerici presi casualmente tra 0 e 9 fino a raggiungere una numerosità dell’array random_char pari a $length. A questo punto avremmo già una password composta da lettere (maiuscole e minuscole) con n=$numbers caratteri numerici in coda. Per rendere le password meno ripetitive ho deciso di rimischiare i valori interni all’array con la comoda funzione shuffle prima di eseguire il return del metodo.
public function getPassword() { $a = 0; while ($a < ($this->length - $this->numbers)) { $random_char[$a] = $this->alphabet[rand(0,51)]; $a++; }
while ($a < $this->length) { $random_char[$a] = rand(0,9); $a++; }shuffle($random_char);$a = 0; while ($a < ($this->length + $this->numbers)) { $password .= $random_char[$a]; $a++; } return $password; }

Come sempre potete scaricare il codice completo della classe randomPassword.class.php in modo da studiarlo attentamente (l’indentazione lì è corretta) e provarlo ma soprattutto modificarlo e perfezionarlo in base a quello che vi ha insegnato la vostra esperienza.

Usate i commenti qui sotto per esprimere il vostro parere, i vostri dubbi, le vostre critiche e i suggerimenti che riteniate possano essere utili a me ed ai lettori.

CREDITS
L’immagine utilizzata nell’articolo proviene da Flickr, dove è stata pubblicata da Imagined Reality con licenza Creative Commons.

La questione dei tipi primitivi

Daniel — Tue, 12 Feb 2008 06:00:34 +0000

Sappiamo tutti (oppure lo scoprite ora) che PHP non è un linguaggio fortemente tipizzato. Questo cosa vuol dire? Significa che non è necessario dichiarare il tipo di una variabile perchè essa possa gestire un particolar tipo di dato. In questo modo potremmo assegnare a $numero il valore 2 oppure “due” alla stessa maniera. Nei linguaggi fortemente tipizzati (C, Java…) è obbligatorio dichiarare il tipo di una variabile prima di assegnarle un valore, valore che chiaramente deve rispettare il tipo specificato.

Questo non significa certo che PHP non rispetti il concetto di tipo, ogni valore che possiamo assegnare ad una variabile ha un tipo che possiamo verificare attraverso delle utili funzioni per la gestione delle variabili. Avremo quindi la possibilità di utilizzare is_bool(), is_integer(), is_string()…per verificare il tipo di una variabile passata come parametro, in caso positivo il valore di ritorno sarà true.

Effettuare il controllo del tipo di una varibile torna particolarmente importante quando si ha a che fare con gli argomenti di metodi e funzioni, casi in cui bisogna prestare particolare attenzione al codice che si scrive. Vediamo un esempio. Immaginiamo di estrarre delle informazioni di configurazione da un file XML, l’elemento specifica all’applicazione se provare o meno ad eseguire il reverse DNS di un IP.
false

La stringa “false” viene letta dall’appliccazione e passata ad un metodo chiamato outputAddress() che si occupa di visualizzare i dati di un determinato IP.

[php]
function outputAddresses($resolve) {
foreach($this->addresses as $address) {
print $address;
if ($resolve) {
print “(“. gethostbyaddr($address) .”)”;
}
print “\n”;
}
}
[/php]

Il metodo outputAddresses() non fa altro che iterare su un array di indirizzi IP mostrandoli uno ad uno, nel caso in cui $resolve sia true il metodo restituisce anche il dominio assieme all’IP. Vediamo una porzione di codice che potrebbe essere chiamata da questo metodo:
$settings = simplexml_load_file("settings.xml"); $manager = new AddressManager(); $manager->outputAddresses($settings->resolvedomains);

Questo codice non si comporta come ci si aspetterebbe: passando la stringa “false” al metodo outputAddress() trascuriamo l’assunzione implicita che il metodo fa riguardo all’argomento passato. Infatti il metodo si aspetta un valore di tipo booleano (true o false) ma la stringa “false” corrisponde al valore true in un test. Questo è dato dal fatto che PHP esegue un cast di una stringa non vuota al valore booleano true in un test if. Di conseguenza:
if ("false") { //.. }

è equivalente a
if (true) { //.. }

Esistono diverse strade per risolvere questo problema, quella più metodica e sicura richiede di modificare il metodo outputAddress() per fare in modo che sia pronto ad aspettarsi il corretto tipo di dato riferito all’argomento $resolv.

[php]
function outputAddresses($resolve) {
if (!is_bool($resolve)) {
die(“outputAddress() richiede un argomento di tipo booleano\n”);
}
}
[/php]

Un approccio di questo tipo obbliga chi utilizza il metodo a fornire l’argomento $resolv nel tipo di dato corretto evitando problemi di ogni sorta. Detto questo sta al programmatore considerare il potenziale impatto che l’utilizzo di tipi inaspettati potrebbe avere sulla propria applicazione. Non pensate di lasciare nulla al caso, chi userà le vostre classi non può leggere quello che avete in mente quando le realizzate quindi è consigliabile pensare sempre come i metodi che scrivete possano reagire alla “spazzatura” che potrebbero ricevere in input.

Inspekt, la libreria firewall

Daniel — Thu, 07 Feb 2008 06:00:49 +0000

Inspekt è una libreria per PHP (4 e 5) promossa dal Open Web Application Security Project (OWASP) in occasione del Spring of Code 2007 e realizzata da Ed Finkler sulla base di quello che era Zend_Filter_Input (ex componente del framework Zend). Lo stesso Ed afferma che dai dati di NIST NVD relativi al 2006 risulta che oltre il 40% di tutte le vulnerabilità riportate riguardano PHP, ma non il linguaggio in sè bensì le applicazioni sviluppate con esso e quindi il codice realizzato. E’ quindi necessario seguire nuovi paradigmi che impongano in un certo qual modo l’applicazione di tecniche di filtering e validation necessarie a garantire il corretto funzionamento delle applicazioni.

Inspekt si piazza come una specie di firewall tra l’input dell’utente e l’applicazione vera e propria. La libreria si preoccupa di prendere gli array superglobali ($_GET e $POST), esegue l’incapsulamento dei dati contenuti in un oggetto definito “cage” (letteralmente “gabbia”) e distrugge gli array superglobali. L’accesso ai dati è garantito da una vasta serie di metodi che si occupano già del filtering e da altri che permettono la validazione dei dati stessi. L’accesso ai dati originali (raw) può essere fatto solamente tramite il metodo ‘getRaw()’ che obbliga quindi lo sviluppatore ad aver ben sotto controllo la situazione e quello che sta facendo.
Dalla documentazione di Inspekt è facile capire quanto sia semplice da utilizzare e quali siano le sue potenzialità nel rendere anche più semplice e leggibile il codice piuttosto che avere tutti i controlli e la validazione direttamente nell’action dei form. Consiglio di dare un’occhiata agli esempi contenuti nell’archivio che scaricate assieme alla libreria, permettono di vedere in azione Inspekt e di lavorare direttamente su codice già pronto per eseguire i propri test e fugare i propri dubbi.

php4 è morto

Daniel — Tue, 05 Feb 2008 06:00:43 +0000

In un comunicato del 13 luglio 2007 gli sviluppatori di PHP davano l’annuncio dell’end of life di PHP4, comunicando che dopo il 31 dicembre 2007 non avrebbero rilasciato ulteriori versioni di PHP4.4. Tuttavia si impegneranno fino al 08/08/08 per gli aggiornamenti sulla sicurezza per dare modo agli sviluppatori di migrare le proprie applicazioni a PHP5 in tutta comodità.

La campagna GoPHP5 punta a far aggiornare tutte le installazioni di PHP presso service provider, non solo, ha imposto il termine del 5 febbraio (oggi) per il passaggio all’ultima versione di PHP disponibile. Il problema di fondo è un circolo virtuoso dal quale si può uscire solamente imponendosi bloccando una variabile del sistema: gli sviluppatori non possono sfruttare le nuove potenzialità di PHP5 senza tagliare nettamente i ponti con il 4 che è ancora attualmente la versione più diffusa presso i servizi di hosting condivisi; i gestori di servizi di web hosting non possono passare alla versione 5 per non bloccare il funzionamento di tutte le applicazioni basate su PHP4; lo stesso team di sviluppo non può smettere di seguire completamente PHP4 dato il massiccio utilizzo che ne viene fatto dagli sviluppatori in tutto il mondo…

Ecco quindi che la comunità di sviluppatori PHP ha deciso di aderire e migrare i propri progetti verso PHP5, dall’altro lato hanno risposto gli hoster che si impegnano ad aggiornare le proprie macchine rendendo finalmente disponibili dei servizi basati su PHP5. Sulle pagine di goPHP5.org trovate l’elenco di chi ha già comunicato la propria adesione alla campagna.

Credits
Le foto utilizzate nell’articolo sono state distribuite con licenza Creative Commons e prelevate da Flickr. Sono reperibili nel formato originale ai seguenti indirizzi:

http://www.flickr.com/photos/zackv/446415923/