Protezione di una chat [ajax / php / mysql]

Protezione di una chat [ajax / php / mysql] postato il 14/10/2009 00:28:42 nel forum programmazione, open source e hosting e modificato da ghennadi72 il 14/10/2009 10:08:30

Ciao, ho alcuni dubbi sul come proteggere al meglio la chat che sto realizzando. Ero partito con l'idea di impementare una chat "old-style", poi mi sono incuriosito sui thread che parlano delle possibili implementazioni di ajax, e ho provato a fare quanto segue.

Premetto che ho una formazione da autodidatta, cominciata con turbo pascal, transitata brevemente in delphi, piccola carrellata su c++ e poi l'approdo a php, saltando del tutto o quasi javascript (allergia di pelle?). Peggio, ho una mentalità tipicamente da programmazione strutturata, la OOP mi causa malditesta già al classico esercizio dell'ascensore... 😁

Quello che ho fatto forse può sembrare molto raffazonato, un po' come un carro funebre ottocentesco dotato di compressore e dipinto a vernice rossa fosforescente (citazione da Stephen King).

Il sistema chat si compone di 5 file:

chatpub.php : é solo il frameset (lo so, sono deprecabili e deprecati, mi cospargerò il capo di cenere) che contiene le due pagine legate all'input e all'output.
Riceve l'id della locazione con metodo GET (filtrato con intval() per evitare il get di stringhe impostate manualmente) e lo scrive anche in una variabile di sessione; al caricamento (e all'eventuale refresh forzato) imposta a zero una variabile di sessione lastchat (che mi serve dopo, per verificare se l'utente é appena entrato in chat o se ci stava già) e una variabile di sessione ingressochat impostata con la funzione time() di php.

chatpub_input.php: é il frame di inserimento del testo. Riceve l'ID della locazione dalla sessione, ed invia a sé stesso con metodo POST. In base alla presenza o meno di caratteri speciali (per le azioni, le stringhe di masterizzazione o moderazione, sussurri, etc)
classifica il tipo di messaggio per tipo e lo salva nel database. La logica é quasi identica a quella delle chat di GDR-CD extreme.

chatpub_view.php: é il frame visibile in cui viene mostrato l'output della chat. La pagina di per sè non si refresha. Qui interviene ajax, che tramite un js incluso avvia una funzione al primo caricamento della pagina e aggiorna i contenuti del DIV principale, identificato tramite il parametro ID="div_main".

chatajax.js: é il "motore" dell'inserimento dei contenuti nel DIV principale della chatbub_view.php; la funzione effettua una chiamata XMLHttpRequest all'ultimo file della cinquina, che va a cercare nel database secondo l'ID della locazione (in sessione) e le variabili lastchat e ingressochat (anche quest in sessione). Saltando i dettagli, richiama un contenuto col sistema XmlHttp.responseText e aggiunge il contenuto in coda al contenuto già presente nel DIV con la funzione .innerHTML. Poi si auto timerizza per un nuovo ciclo dopo 2 secondi e posiziona la barra di scrolling in fondo.

chatpub_xmlhttp.php: é il "motore" nascosto, che in base ai parametri di cui sopra presenti in sessione (e altri, tipo l'id del personaggio, etc) compone il DIV da mostrare alla pagina richiedente sotto forma di normale codice html, trattato come se fosse un file di testo dal metrodo .responseText
A seconda che sia il primo ingresso in chat, la pagina genera l'html necessario a visualizzare le azioni degli ultimi 10 minuti, se presenti, oppure solo le azioni inviate dopo l'ultima già visualizzata in precedenza.
Terminato l'output che viene inviato a chatpub_view.php, la pagina aggiorna in sessione la variabile lastchat.

I tipico output di chatpub_xmlhttp.php potrebbe somigliare a questo (supponendo che la riga da mostrare sia identificata come una stringa di normalissimo parlato):

<div class="parlato"> <?=$ora;?> <.. codice simboletti vari e nome personaggio>: toh, guarda quanta gnocca c'è in taverna stasera...
</div>

Questa roba viene presa da chatpub_view.php e aggiunta dentro al div principale. Il parametro "class" del div ricevuto dalla pagina di output ovviamente varia a seconda del tipo di contenuto da mostrare (azione, parlato, azioni speciali, moderazione, game masters, etc) e le relative proprietà grafiche sono definite in un foglio CSS a cui chatpub_view.php é collegato.

...

Ora, mi chiedevo quali possono essere i modi migliori di proteggere una chat costruita secondo questa logica.

chatpub_input.php, quando riceve i dati da sé stesso, tratta già il testo inviato (POST) con htmlspecialchars(). Prima di passare il testo alla query di inserimento nel database della chat, il testo subisce una ulteriore passata in una funzione che converte gli apici singoli (apostrofi) in &_acute e gli apici doppi (virgolette) in &_quot, oltre a strippare i vari tags eventualmente residui.
(Gli underscore qua sopra sono fittizi, li ho messi se no venivano visualizzati i caratteri corrispondenti).

Al momento dell'output, in teoria, chatpub_xmlhttp.php dovrebbe poter prendere il testo così com'é salvato nel database e passarlo a chatpub_view.php per la visualizzazione all'utente finale.

Ho fatto qualche prova sia tentando di inviare tag html o di script, sia cercando di inviare query mysql o pezzi di query, col risultato che mi sono sempre trovato, almeno finora, le "query" e i tag html piazzati in chiaro in chat (quindi non trattati come tali).

Domanda... cosa potrebbe andare storto? Come porvi rimedio?
Leggendo i thread sugli XSS suppongo che quanto sopra possa non essere sufficiente, ma non mi é del tutto chiaro a quali vulnerabilità espone l'uso di htmlspecialchars() e quando sia preferibile usare invece htmlentities().

ps: faccio presente che ogni file "sensibile" include un controllo sulla sessione, per verificare lo stato del login e la titolarità dell'account in uso; un ulteriore JS incluso si occupa di verificare che la finestra contenitore sia la stessa in cui é lanciato il motore della land al momento del login (il js che si occupa di questo é simile a quello utilizzato da eXtremelot).
Avevo in mente di implementare anche un ulteriore controllo sulla provenienza degli input, usando le variabili $_SERVER['PHP_SELF'] e $_SERVER['HTTP_REFERER'] dove possibile, anche se sull'uso dell'ultima ho qualche dubbio.

14/10/2009 14:18:18

Fai l'escape, in input, di ogni carattere potenzialmente pericoloso direttamente da funzione e non manualmente con un replace :)
mysql_real_escape_string($testo) è la funzione definitiva e più sicura.
Ti consiglio htmlentities($var) perchè a differenza di specialchars, quest'ultima codifica ogni carattere html nella sua relativa entità. Ma sono scelte che non intaccano molto la tua sicurezza :P
Per il resto la sicurezza in chat (se non sono in ballo altri meccanismi oltre al testo) è abbastanza semplice, l'importante è che usando ajax lo si usi un po' con la testa e non semplicemente per evitare lo sfarfallio o il reload.

14/10/2009 14:25:23

Dopo aver effettuato gli escape di cui ti ha suggerito Il "mistico" Lato Oscuro della Colazione, converti tutto (server side, in post) in hex con rawurlencode e te lo riconverti in lettura con javascript con decodeURIcomponent.

Questa soluzione oltre a fornire un perfetto escape delle informazioni che passi alla query, ti torna utile per far visualizzare sempre e comunque alla perfezione qualsiasi carattere, indipentendemente dalla codifica (giuro, ho provato b.b).

15/10/2009 01:21:52

Aggiungo: l'importante è che tutti i controlli di sicurezza li esegui lato server, lato client lascia solo tutte quelle scemenze che riguardano la visualizzazione in quanto è facile eseguire a piacimento gli script nella pagina, basta utilizzare la barra degli indirizzi del browser addirittura.

es:

javascript:alert("ciao");

Allo stesso modo, invece di richiamare un alert si possono richiamare a piacimento le funzioni nella pagina e con un po di abilità scrivere degli interi script inline per far funzionare differentemente ciò che tu avevi progettato in un certo modo.

Per cui prima di fare qualcosa lato client, rifletti sempre bene ;)