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 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.

A 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 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

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.

CSRF Cross site request forgeries: difendersi con i tokens

In un precedente articolo, ho introdotto il concetto di CSRF, questa volta ci occuperemo di ovvero fornire i concetti di base della protezione contro questo tipo di attacchi.

Ci tengo a precisare che anche questo articolo conterrà metodi di base per la protezione delle proprie applicazioni, in quanto la scienza dietro gli attacchi è davvero molto sviluppata al momento.Abbiamo visto che un attacco di tipo CSRF consiste nel fare in modo che la vittima invii delle richieste inconsapevolmente, sfruttando le sue credenziali. Riportiamo brevemente un esempio per riprendere le fila del discorso: Mentre visitiamo la pagina “posta in arrivo” del nostro account email non protetto, apriamo un altra scheda del browser, capitando in un sito malevolo creato ad hoc per attaccare la pagina del nostro email service provider. Cliccando su un semplice link del tipo:

<a href=”happy_page.php” onClick=”document.send_mail_form.submit()”>Click</a>

e magari avendo semplicemente (ci sono modi di gran lunga migliori per inviare richieste POST) predisposto il seguente form nascosto:

<form name=”send_mail_form” method=”POST” action=”www.unsafe-email-service.com”>

<input type=”hidden” name=”receiver” value=”randomReceiver1”>

<input type=”hidden” name=”receiver” value=”randomReceiver2”>

<input type=”hidden” name=”receiver” value=”randomReceiver3”>

..

<input type=”hidden” name=”receiver” value=”randomReceiverN”>

<input type=”hidden” name=”object” value=”Object”>

<input type=”hidden” name=”text” value=”randomText”>

</form>

comporterebbe l’immediato e totalmente involontario invio delle email con il nostro account di posta elettronica.

Come possiamo mitigare il rischio CSRF ,quantomeno, rendere gli attacchi meno scontati e facilmente implementabili? Un metodo largamente usato, in quanto offre un buon rapporto sicurezza/facilità di implementazione è quello dei Token.

Un token è una stringa di testo che funge da validazione per le richieste che inviamo alla nostra applicazione e deve essere correlata alla sessione dell’utente.

Potremmo sintetizzare il concetto nei seguenti passi: Creo il token, lo salvo nella sessione e lo richiedo per validare ogni input utente. Se il sistema rileva una richiesta POST non accompagnata dal corretto token ci permetterà di riconoscere un probabile tentativo di attacco e di interrompere l’esecuzione.

Parte 1: creiamo il token.

Presupponendo che la sessione sia già stata inizializzata

<?php

$token = sha1(uniqid(rand(),TRUE));

$_SESSION['token'] = $token;

?>

Parte 2: generiamo il form

<form name=”myForm” method=”POST” action=”myPage.php”>

<input type=”hidden” name=”token” value =” <?php echo $_SESSION['token']; ?> “ />

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

<input type=”submit” value=”invia”>

Parte 3: controlliamo la validità della richiesta

<?php

if (!isset ($_POST['token'] OR !isset ($_SESSION['token'] OR $_POST['token'] != $_SESSION['token'] OR)

{

//errore! Interrompere l’esecuzione

} else {

//Il token è validato, possiamo procedere

}

?>

n questo modo costringiamo l’attaccante a scoprire il token assegnato alla sessione della vittima, inoltre questo fa si che l’attacco colpisca soltanto quell’utente, o comunque costringe l’attaccante a replicare il token di ogni vittima, affinchè le richieste artificiali da lui create bypassino il sistema di controllo.

Come migliorare questo approccio?

Come ho già detto, questo metodo non garantisce la sicurezza assoluta, quindi se state cercando di mettere al sicuro i form di un sito di e-commerce, non vi consiglierei mai di fermarvi a questo livello di validazione; possiamo però migliorare il nostro codice di controllo in diversi modi. Vediamone alcuni.

Generiamo un token per ogni form della pagina che l’utente visualizza, così da aumentare la complessità del problema, potremmo dire che creare un token per ogni richiesta dell’applicazione sarebbe un’ottima cosa.

Associamo un tempo di validità del token dopo il quale non verrebbe più considerato valido:

<?php

$token = sha1(uniqid(rand(),TRUE));

$_SESSION['token'] = $token;

$_SESSION['token_time'] = time();

?>

e successivamente controlliamo che non sia passato troppo tempo dalla creazione del token, altrimenti lo consideriamo scaduto :

<?php

if (!isset ($_POST['token'] OR !isset ($_SESSION['token'] OR $_POST['token'] != $_SESSION['token'] OR)

{

//errore! Interrompere l’esecuzione

} else {

$token_time = time() – $_SESSION['token_time'];

//Facciamo in modo che la durata massima del token sia di 10 minuti

if ($token_time < 600)

{

//interrompiamo l’interruzione informando che la pagina è scaduta

}

//Il token è validato, possiamo procedere

}

?>

Concludo proponendovi una riflessione: anche la miglior difesa contro attacchi di tipo CSRF può essere superata se non vi affianchiamo una ottima difesa per gli attacchi di tipo XSS, in quanto questi ultimi potrebbero essere utilizzati come “apripista” verso le nostre difese.

Spam is not Dead

Faceboobs

Il paradosso del video

Personalmente sono un utente di diversi social network come twitter, netlog, livespace, e facebook (ahimè per quest’ultimo se non fosse per i giochini lo avrei abbandonato), e sono in media collegato con 150 persone per ognuno. Diciamo che molti contatti si ripetono, in quanto molti di essi sono strambi come me ed utilizzano diversi social networks ed io li ho aggiunti in ognuno. In definitiva potrei avere 90 contatti per ognuno dei social sopra citati, quindi arriviamo a circa 450 contatti. Diciamo anche, che un mio amico decida di condividere con me uno di questi video divertenti e che io rimanga colpito a tal punto da postarlo in ognuno dei suddetti siti. Non per vantarmi ma io sono un tipo simpatico e supponiamo che per questo la gente sia portata a cliccare sui miei link e che il giorno della pubblicazione, 180 persone abbiano visto il mio link, ma solo 110 abbiano cliccato.

Questo avrebbe portato un +110 al contatore di click di quel video divertente. Notate poi che io non sono l’unico simpatico stronzo (scusate il termine ma la consonanza è perfetta) che ha postato il video e che ha tanti amici virtuali… in definitiva quel giorno, il video avrà ricevuto, via passa parola , qualche migliaio di click.

Un po di considerazioni

Ogni utente di un social network è dotato di un potenziale comunicativo che rende potenti le sue pubblicazioni, potremmo fare una bella similitudine con una piazza piena di gente che parla : chi ha la voce più potente o comunque chi riesce a farsi sentire da più gente ha il potenziale comunicativo più alto.

Queste considerazioni sono facilmente traducibili in un modello matematico, così come sarebbe facilmente facile fare supposizioni sul potenziale comunicativo non degli utenti, ma dei social network stessi! Fondamentalmente, un contatto ha la possibilità di comunicare con un altro contatto, ma il social network ha la possibilità di comunicare con tutti i suoi contatti!

Quando spuntiamo la casellina con scritto “accetto il trattamento dei dati personali bla bla bla” autorizziamo il social network e soprattutto gli amici del social network a comunicare con noi! E decidono loro cosa comunicarci. Cosa ci comunicheranno? La risposta è semplice: come farli guadagnare.

Perché tutto questo?

Tempo fa ho loggato in msn utilizzando un vecchissimo e decaduto contatto che avevo e udite udite c’erano 857 email belle pronte per essere cancellate (ne avrò cancellate almeno 840).

Inoltre, controllando la sezione “spam” del mio account di posta gmail ho notato che ogni giorno ricevo circa dalle 8 alle 13 email di spam (ma gmail mi conosce bene e sa cosa farsene)

Per questo ho deciso di fare un piccolo test con dei miei indirizzi e mail personali, li iscriverò progressivamente a diversi siti internet (non solo i social networks) e monitorerò la quantità di email pubblicitarie a cui sarò sottoposto.

Appena avrò dei dati interessanti scriverò il seguito di questo articolo.

Nel frattempo non date via il vostro indirizzo email come se foste un verginello nel pianeta delle amazzoni. (singolare che un verginello nel pianeta delle amazzoni scambi il proprio contatto email eh? Beh altrimenti non sarebbe verginello). Magari procuratevi più caselle email: una per le cose importanti ed un altra per riempirla di spam dei siti a cui vi iscriverete

MyBrute.com

Lo svago non può mai mancare! Anche se in questo momento della mia vita  dovrei eliminarlo per riprendermi da questa fase di assoluta improduttività xD Se però, trovo uno svago che contiene : Ottimizzazione, Fama, Crescita e Competizione…. perdo la testa… ed eccomi qua  a parlarvi non di codici che iniziano con <?php ma di un giochino flash molto divertente

il mio stylahhhhhhh impegnato nel primo round del torneo (round vinto ovviamente xD)

MyBrute.com vi permette di creare il vostro personaggio e di farlo evolvere massacrando di schiaffi gli altri , non è un gioco interattivo dovete solamente sedervi comodi e pregare che il vostro personaggio distrugga l’avversario, combattimenti sempre  brevi ma intensi, divertimento assicurato!

Ad ogni combattimento guadagnate punti esperienza e con l’avanzare dei livelli guadagnate armi o abilità! L’unica limitazione che mi ha fatto storcere il naso inizialmente è la limitazione ad un certo numero di incontri al giorno…. probabilmente implementata per eliminare il fenomeno del NERDING estremo… anche perchè per essere un giochino flash da una certa dipendenza Però ogni tanto vengono organizzati dei tornei che vedono il vostro personaggio impegnato in una marea di scontri ravvicinati, è una goduria rivedersi i replay dei propri combattimenti

Cominciate pure sfidando il mio:

http://stylahhhhhhh.mybrute.com

Buon divertimento e che vinca il migliore !