quali metodi di sicurezza adottare per chiamate asincrone?

[the-bit]

Buon giorno,
ho creato un servizio per la creazione di messaggi ed annessi commenti, facendo largo uso di jQuery.
Ora però mi son bloccato perchè sto considerando gli aspetti della sicurezza.
Ad esempio se io ho un messaggio con id=1, creo affianco un bottone che richiama una funzione JS di tipo inserisciCommento(1), una funzione JS in cui appunto specifico a quale messaggio fanno riferimento i commenti inseriti.
Ma in questo modo, però, chiunque mastichi un po di JS potrebbe farlo anche senza essere loggato al sito, mandandomi tutto in crash, visto che esistono proprio dei plugins per i browser che permettono di eseguire direttamente codice JS sulle pagine.
Perciò mi rivolgo a voi: quali misure mi consigliate di adottare?

[cavicchiandrea]

Di norma le verifiche come sicurezza è lato server, non per l'invio dei dati lato client
Per scrupolo potresti criptare i dati lato client e decriptarli lato server ma non credo ne valga la pena, considera che facebook fa un grosso uso di jquery e non credo che cripti nulla per l'invio dei dati.
Io comunque quando eseguo accessi ajax/jquery l'unica accortezza e inviarli in post

[the-bit]

si ma li invio anche io in post, ma poi ti bastano plugin come firebug o - peggio ancora - plugin integrati in chrome per vedere in chiaro tutto quello che passa.
Ecco perchè, a mio avviso, c'è poca differenza tra post e get...dipende dal tipo di utente con cui si ha a che fare.
Se volessi invece considerare l'idea di criptarli, come dovrei fare?

[cavicchiandrea]

Allora forse ho frainteso credevo tu cercassi una codifica per l'invio dei dati cioè trasferimento client > server che non potessero essere letti da "terzi", mentre tu cerchi altro come non detto

[rsdpzed]

gli url che richiami con ajax devono essere protetti a prescindere dal fatto che li richiami con ajax. La gestione del cookie di autenticazione è una cosa che gestisce il browser: se la pagina è accessibile solo agli utenti loggati lo sarà anche se la chiami via ajax. Il tuo sembra essere un problema di autorizzazione a monte.

Per lo stesso motivo il fatto che una funzione sia "visibile" in internet non vuol dire che debba essere accessibile. Oltre all'autenticazione devi sempre controllare lato server che l'utente sia autorizzato a compiere una determinata azione. Questo generalmente lo si fa con la gestione dei ruoli e degli utenti ma anche con controlli piu restrittivi (es. se l'utente X non è un moderatore, il commento che l'utente X sta eliminando appartiene all'utente X?)

Ad essere precisi, in ambito sicurezza devi RITENERE visibili e alla "luce del sole" tutti i metodi richiamabili da web perche di fatto questa è la loro natura.

A questo punto si puo parlare di argomenti piu "avanzati" ma assolutamente non trascurabili ed in tema con la domanda che hai posto. Devi proteggerti da un tipo di attacco difficile da effettuare ma molto pericoloso: il cross site request forgery (CSRF). L'attacco consiste nel rubare con un link fake ad una pagina contraffatta il cookie di autenticazione di un utente autorizzato ma poco accorto. A questo punto dalla pagina stessa uno script sarebbe in grado di fare quello che tu temi possa avvenire in questo post: un altro fa cose che non è autorizzato a fare.
La difesa è semplice: lato server devi controllare che i dati inviati via POST arrivino effettivamente da chi ha inviato la richiesta. Questo lo si puo ottenere in due fasi.
- inviando la pagina con il form invii anche in un campo nascosto, un guid generato e conservato in una variabile di sessione.
- alla ricezione dei dati post controlli che ti arrivi anche il guid e soprattutto che coincida con quello generato precedentemente lato server (ricordati di cancellare la variabile di sessione subito dopo).
Se il confronto va a buon fine procedi altrimenti rispondi picche al client.

[Al_katraz984]

non si può lavorare lato client se la logica lato server non è fatta bene... sono fighe le applicazioni con jquery e balle varie ma mi sa che mi metto a fare l'hacker e li buco tutti... senza tanta fatica

[the-bit]

Non l'ho specificato ma mi sembrava scontato: è chiaro ed ovvio che lato server io faccia i dovuti controlli (se l'utente è loggato, se può postare, ecc ecc).
La mia preoccupazione era dovuta dal caso in cui un utente/lamer/cracker si registri regolamente al sito per poi, sempre da loggato, crearsi una funzioncina jquery che invii centinaia di INSERT al DB al minuto facendolo esplodere in breve tempo ed eseguendola attraverso una delle tante console per browser.
@rsdpzed: il tuo consiglio sul generare una sessione sembra buono, però - se non ricordo male - in jQuery non si possono gestire sessioni, ma solo cookies. Quindi qualora un utente disabiliti i cookies, cosa faccio?
Inoltre, se avessi un link a qualche guida da cui prendere spunto per realizzare il sistema in 2 fasi di cui parlavi (ovvero campo nascosto guid e sessione, un po come avviene col captcha se non erro) mi faresti un gran favore.

[rsdpzed]

la risposta era in merito a

Originariamente inviato da the-bit
Ma in questo modo, però, chiunque mastichi un po di JS potrebbe farlo anche senza essere loggato al sito, mandandomi tutto in crash, visto che esistono proprio dei plugins per i browser che permettono di eseguire direttamente codice JS sulle pagine.

Se inseriscicommento(1) esegue una chiamata ajax alla pagina inserisciCommento.php e quella pagina contiene funzioni accessibili solo agli utenti autorizzati non sara accessibile da nessuno se non da utenti autorizzati quale che sia la tecnologia usata per realizzare il client... sempre di http si tratta. Con le console e programmini vari, si possono fare tutte le cose che tu dici su tutti i siti. La differenza è che invece di vedere le chiamate ajax e il javascript devo vedere le action dei form e i tag input, non cambia nulla (per es. in questo forum c'è il form con la action newreply.php, so i nomi di tutti i campi, posso anche evincere il loro significato, e c'è anche l'hiddenfiled per la protezione csrf subito sotto il form: il campo s).

Nell'ultimo reply hai citato anche un altro problema (non da poco): utenti autorizzati che eseguono volontariamente operazioni di bombing. Lo si puo fare a tutti i siti e se esistesse un metodo semplice per risolvere il problema non esisterebbero piu i captcha. Anche qui la soluzione va implementata lato server: memorizzi in un area cache (piu l'applicazione è grossa piu deve essere performante) gli ip e il timestamp di chi fa le operazioni e controlli che qualcuno non cominci a fare troppi invii post in intervalli di tempo troppo brevi. La cosa è delicata e va studiata bene perche altrimenti le contromisure potrebbero costare piu risorse di quelle che si intende salvare.

Ogni linguaggio/piattaforma ha il suo modo di implementare la protezione csrf. Asp.net la fa dietro le quinte (e non ci si deve preocccupare di questo visto che non si lavora direttamente con il form), php la si fa a mano (php lo conosco solo a livello base, non ci lavoro). In asp.net mvc c'è qualcosina ma per ajax devi lavorarci a mano. La soluzione teoricamente è quella che ti ho dato nel post di prima ma per implementazioni specifiche basta fare una ricerca su google.