Ajax-Jquery e PHP

Ajax-Jquery e PHP postato il 26/11/2015 09:29:17 nel forum programmazione, gdrcd, open source, hosting

Salve, più per passione che per necessità, sto programmando da zero un gdr.
Sono ad un buon punto, buttato giù l'intera base in php e poco html.

Ho l'idea di "rifare" tutto curando ora l'interfaccia per l'utente, la mia domanda o problema è il seguente: quanto è sicuro utilizzare molto ajax all'interno dei nostri siti/gdr?

Sinceramente lo trovo molto comodo per poter fare le richieste lato server, senza dover mischiare troppo php e html/js/jquery. Però, valutando un po' e facendo alcune prove, trovo che si perde un po' di sicurezza.
Forse sono io che sbaglio questo pensiero, difatti volevo chiedere a voi un po' come strutturate le vostre pagine, se utilizzate o meno tali approcci.

quota

26/11/2015 10:43:51

Grazie mille ^^

quota

26/11/2015 11:19:49

potresti essere più specifico di dove trovi che si perda sicurezza?

quota

26/11/2015 11:24:41

Allora, parto un attimo con il momento superquark, magari chiarisco indirettamente anche i dubbi di altra gente:
Che cos'è ajax?
Ajax è javascript. Semplicemente asincrono.

Differenza tra sincrono e asincrono?
Nel primo caso ogni volta che il sito deve fare una chiamata a qualcosa (una pagina, una risorsa, un servizio..) lui seguirà questo ordine:
1. Faccio la chiamata -> 2. Aspetto la risposta -> 3. Riprendo ad eseguire le altre operazioni da fare dopo la chiamata. Durante il punto 2 la pagina è temporaneamente bloccata, si ferma completamente per attendere la risposta.
Se invece parliamo di chiamate asincrone, lo scenario è più simile a questo
1. Faccio la chiamata -> 2. Continuo ad eseguire le altre operazioni come nulla fosse -> 3. Quando arriva la risposta della chiamata agisco di conseguenza.

Però consiglio la lettura di qualcuna di queste risposte, che saprà spiegare le cose meglio di come non l'ho fatto io: http://stackoverflow.com/questions/748175/asynchronous-vs-synchronous-execution-what-does-it-really-mean ↗

Quindi adesso possiamo avvicinarci all'argomento vero e proprio della discussione: è sicuro usare tutto questo javascript? (ajax alla fine è javascript. Così come lo è (in forma diversa) jquery.).
Purtroppo questa nuova domanda solleva una discussione non da poco, ovvero identificare gli ambiti di competenza del PHP e quelli del js.

Sintetizzando in maniera moooooolto estrema:
PHP -> Linguaggio lato SERVER -> Il codice scritto viene salvato, letto ed eseguito SUL SERVER. L'utente può interagire solamente con gli output di quel codice, non con il codice stesso. Se non hai modo di accedere al server, non hai modo di sapere cosa sta facendo il codice PHP di quella pagina.

JAVASCRIPT -> Linguaggio lato CLIENT -> Il codice viene scaricato, letto ed interpretato dal CLIENT. (=Google Chrome/Firefox/Safari/Edge...)
Questo si traduce nel fatto che se premi F12 durante la navigazione (o fai ispeziona elemento con click dx) tu puoi leggere e (in certa parte, in modi più o meno rapidi) manomettere quel codice. Ovviamente è una fotocopia dell'originale, quindi anche lo modifichi radicalmente... sul sito resta sempre uguale. È solo sul tuo pc che sta cambiando comportamento. Viceversa, se manometti il codice PHP, stai cambiando il comportamento della pagina per TUTTI gli utenti del tuo sito.

Allora se è una cosa che vedo solo io e non posso manometterla andrà bene usare tanto javascript!
Sni. Immagina di avere una chiamata javascript (asincrona o meno), oppure anche solo una semplicissima GET in HTML costruita in questo modo:

A primo sguardo è già lampante dove sia il problema di questa chiamata. Se io facessi una chiamata a quel link e cambiassi "abe" con.... "kasa"?
Vedrei la casella di posta di kasa. Direi che non è una scelta molto sicura.

Questo è il caso in cui il suddetto dato deve essere gestito SUL SERVER (=variabile di sessione PHP o qualcosa di simile). Così l'utente oltre a non poter leggere, non può neanche provare a cambiare il dato che viene passato. Se la pagina posta legge dalla sessione che l'utente è "ABE", allora visualizzerà solo ed esclusivamente la mia posta. Non serve nemmeno passarla come dato a quella pagina, sarebbe assolutamente inutile.

OMMIODDIO, allora usiamo sempre e solo PHP?
Nope. Oltre che a comportare un costo di risorse sul server, non sempre si può risolvere tutto lato server. Riquadri autoaggiornanti, messaggi che arrivano e suonano anche senza aggiornare la pagina, calendari e roba un po' più fighetta... sono tutte cose che devono essere fatte usando del buon sano javascript (insieme a css e html) che faccia da collante con la parte PHP.

La soluzione sta nel mezzo..
Facciamo un esempio reale di come usare server e client in maniera intelligente: la registrazione di un personaggio. Soffermiamoci solo sul campo "nome_pg".

(SOLUZIONE SBAGLIATA) - Validazione solo lato client.
Io faccio il mio form di iscrizione, dove scrivo a chiare lettere che i nomi utenti devono essere: minuscoli, solo lettere, senza spazi e senza numeri.
Faccio una validazione usando javascript man mano che l'utente inserisce il nome. Blocco l'inserimento di tutte le lettere che non rispettano i miei standard. La pagina funziona bene e tutti contenti. E se un bel giorno arriva il furbone che spegne il javascript? O che modifica direttamente l'input dentro l'html senza passare dalla parte visiva della pagina?

Succede che registrerai con successo un utente chiamato "T. h0_ Fr3Gat0!%%&<br/>". E per quanto possa sembrare poco importante, ti assicuro che se al posto di quel <br/> ci fosse scritto altro (' OR TRUNCATE TABLE utenti;) avresti GROSSI problemi.

(SOLUZIONE GIUSTA, MA BRUTTA) - Validazione solo lato server
L'utente scrive quel che vuole, preme conferma. Caricamento. Errore, il formato del nickname non è valido. Inserisce un nuovo nome, preme invio, carica, errore, formato nickname non valido. Ancora un nuovo nome, stavolta controlla tutto nei minimi dettagli. Preme invio. Caricamento.... . Errore, nome utente non disponibile.
Se il tuo form di iscrizione è fatto da 18 campi, e se questi vengono resettati ogni volta che sbagli la validazione... l'utente avrà mollato prima di riuscire a creare un pg.

(SOLUZIONE DECENTE) - Validazione mista
Il server implementa tutti i controlli di base, senza sforzarsi più di tanto nel gestire nel dettaglio i vari casi di errore. Se il formato non gli va bene, se l'utente è già preso, se qualcosa va male... return error;
Il client implementa in maniera più figa i controlli man mano che scrivi nella casella di input. Se premo spazio semplicemente non me lo inserisce, così come non inserisce un numero.
Ciliegina sulla torta: quando l'utente fa il focus out da quella casella, parte una chiamata ajax (quindi asincrona) che chiama una pagina così:

Che in maniera piuttosto veloce ti fa comparire un bel messaggio che ti avvisa se quel nickname è disponibile o meno!

Più lungo da implementare? Sì. Ma migliora l'esperienza per l'utente, protegge te da eventuali furbate.

Tl;DR
1) Valida SEMPRE E COMUNQUE tutti gli input che prendi dalle tue pagine. TUTTI, anche le <input type='hidden'>. Assicurati anche solo che siano davvero numerici (se ti aspetti un numero).
2) Non scrivere MAI sulle variabili js (o dentro l'html in generale) dati importanti presi dal database.
3) Allo stesso modo non passare lato client dati non strettamente necessari (l'id per farsi identificare nelle pagine private, la variabile che contiene i privilegi del suo account.. tutta roba inutile lato client, fondamentale in sessione lato server)
4) Usa ajax, ma non farti prendere la mano. Inserire troppe chiamate nella stessa pagina, o ripeterle troppo frequentemente può rallentarti la pagina in maniera indecente.
5) Fai l'escape di tutte le stringhe che passano da/verso il database. Assicurati che il db non possa in alcun modo leggere l'input dell'utente come fosse un pezzo di query, ma piuttosto che lo tratti sempre come un pezzo di stringa da confrontare/inserire/leggere.
6) Hashing. Non crypting, hash. E NON in MD5!
7) https://it.wikipedia.org/wiki/Cross-site_scripting ↗
8) https://it.wikipedia.org/wiki/SQL_injection ↗
9) Se c'è una perdita di sicurezza, non è colpa del linguaggio client ma di come lo usi (o di come non usi il linguaggio server)

quota

26/11/2015 11:52:08

Quello che intendevo dire io quando ho chiesto dove lo trova meno sicuro, è che comunque il problema della manipolazione dei dati lo puoi avere anche su un passaggio dati tradizionale attraverso un form o un link se non viene fatta una validazione dei dati ove necessario

quota

27/11/2015 08:56:14

ne approfitto qui per domandare di una cosa che mi è capitata di recente(penso che la domanda sia più indirizzata a sandor, visto che sono sicuro lui usi il mio stesso framework).

Su ci avevo settato globalmente in token csfr(quello nativo di ci, non ddi google), ma mi ha bloccato tutte le chiamate ajax. c'è un modo per ovviare a cciò senza rinunciare alla protezione?

quota

Shenteon

Intervista ai gestori del gioco di ruolo fantasy classico Shenteon - L'Eredità delle Lune

Dunedan

I Dunedan: Indagine etnografica della popolazione tolkieniana

I Vampiri

Tesi di laurea dal titolo: Il vampiro della tomba accanto

Storia del GdR

Storia dei Giochi di Ruolo cartacei dagli albori al Duemila