[JavaScript] Problema sicurezza applicativi WEB e tabs browser !!

[simo6784]

CIao,

ho notato un problema con i tabs di qualsiasi browser
mi spiego meglio...
... se sviluppiamo un applicativo in ASP ad esempio con un aria di login e delle variabili di sessione per gestirne l'accesso e iMMAginiamo di avere del codice javascript ad esempio all'interno di una procedura per modificare determinati dati (es un anagrafica).. .. volendo un utente malintenzionato potrebbe salvarsi la pagina html in locale ... modificarne il codice javascript di qualche funzione o anche qualche campo hidden o text di una form... aprire in un altro tab del browser la pagina modificata per non perdere i valori di sessione che controllano se è effettivamente loggato al sistema e bypassare così eventuali controlli.... mi sembra una cosa abbastanza grave .... oppure esiste qualche trucchetto per evitare che avvenga e mi sto perdendo in un bicchier d'acqua ?!!!
mi intimorisce il fatto che se apro un tab del browser riesco a caricare una pagina HTML che mantiene validi i valori di sessione di un altro tab... voi che ne dite ?!!

grazie



Simone

[gugoXX]

Giusta osservazione, che puo' pero' derivare da un approccio sbagliato.
Non deve esserci nulla, nella pagina, che serve al "server" per identificare chi e' che sta facendo le operazioni.
Non si deve salvare la "login" nella pagina per poi rimandarla al server quando si devono fare le operazioni.
Le variabili di stato come queste, soprattutto queste, devono rimanere come variabili di sessione nel server.
E fin qui mi sembra di aver capito che da quello che hai scritto ci sei.

Il resto dellla logica di controllo deve essere messo tutto sul server, non sulla UI del client.
Che l'utente abbia scritto "Nome e cognome" sulla mia form, oppure su una sua form, nulla dovrebbe cambiare.
Se si fanno gli applicativi bene, ovvero se si disegna un buon modello dati, un buon servizio che interagisce con il database (tipicamente web service), poi ci potro' attaccare una qualsiasi UI, sia che sia una pagina ASP.net, sia che sia un'applicazione WinForm, sia che sia un'applicazione pinco pallo che l'utente ha voluto crearsi da se' per chissa' quale motivo.

L'intelligenza nel caso da me menzionato (classico) dovra' stare sul web-service. Ogni funzione esposta dovra' controllare la validita' dei dati passati, la possibilita' che quell'utente possa averli scritti, la possibilita' di usare la funzione stessa, etc.

[DioBrando]

CIao,

ho notato un problema con i tabs di qualsiasi browser
mi spiego meglio...
... se sviluppiamo un applicativo in ASP ad esempio con un aria di login e delle variabili di sessione per gestirne l'accesso e iMMAginiamo di avere del codice javascript ad esempio all'interno di una procedura per modificare determinati dati (es un anagrafica).. .. volendo un utente malintenzionato potrebbe salvarsi la pagina html in locale ... modificarne il codice javascript di qualche funzione o anche qualche campo hidden o text di una form... aprire in un altro tab del browser la pagina modificata per non perdere i valori di sessione che controllano se è effettivamente loggato al sistema e bypassare così eventuali controlli.... mi sembra una cosa abbastanza grave .... oppure esiste qualche trucchetto per evitare che avvenga e mi sto perdendo in un bicchier d'acqua ?!!!

La parte di validazione deve sempre stare sul lato server, solitamente gestita dall'ApplicationServer (a seconda poi chiaramente di come sia la struttura su cui andrete a implementare, se 1/2/3tier ecc.).
In questo modo anche salvando la pagina HTML che sarà l'output risultante dalla richiesta fatta lato client nel momento in cui l'utente andrà ad effettuare il login, sulla pagina HTML stessa (per meglio dire nel codice della pagina) non ci sarà alcuna traccia della coppia di dati sensibili utilizzati (login e password), proprio perchè l'autenticazione avviene lato server e la pagina HTML è già di per sè il prodotto di quell'autenticazione.

Gli script che vorrete utilizzare ( e che io solitamente consiglio di ridurre al minimo per un discorso di accessibilità) serviranno, qualora servissero, ad altro e saranno slegati dalla logica di cui sopra.


mi intimorisce il fatto che se apro un tab del browser riesco a caricare una pagina HTML che mantiene validi i valori di sessione di un altro tab... voi che ne dite ?!!

grazie



Simone

Solitamente non è il tab o non tab a fare la differenza.
Una volta che ti sei autenticato, se tu apri una finestra dello stesso browser, resti autenticato per effetto del meccanismo di sessione (tramite cookie) che ogni sito utilizza.
In base poi alle policy che variano dalle scelte fatte a monte da parte dell'amministratore, la sessione dopo tot minuti di inattività scade e l'utente deve ripetere la procedura di login.
Ma non cambia niente che tu operi con tab +ttosto che finestre.
Logicamente devi lavorare nel medesimo ambiente (browser) altrimenti il meccanismo dei cookie non funziona.
Se parti con Firefox, ti autentichi e poi provi a navigare con Opera è chiaro che il discorso non funzioni, ma anche qui l'utilizzo dei tab non c'entra nulla.


*pardon non avevo refreshato dal pomeriggio e non mi sn accorto della precedente risposta di gugo...spero di nn aver scritto un doppione

[simo6784]

ok, grazie ragazzi... quindi il tutto dipende da una logica durante la fase dello sviluppo del software...
probabilmente una tecnologia cme ASPx è più sicura rispetto ad ASP(ma anche qui pensando le cose per benino si potrebbe risolvere il problema).

grazie

S.

[cionci]

Per queste cose, se non se può proprio fare a meno, si usa una one-time password.
Ad esempio un md5 della concatenazione fra nomeutente-password-data_ora-numero_casuale.
La one-time password deve essere memorizzata nella sessione e data in pasto anche al JavaScript. Al momento in cui si riceve la richiesta tramite JavaScript svolgiamo la verifica della one-time password e la eliminiamo dalla sessione.
In questo modo non sarà possibile ad esempio svolgere due volte la stessa operazione o fare operazioni diverse con la stessa one-time password (la one-time password viene invalidata dopo la prima).

[simo6784]

dunque vediamo se ho capito...
... a questo punto il codice andrebbe creato lato client (immaginiamo che il codice venga generato da un timestamp di una funzione javascript+usr così è sempre diverso anche quando lo ricarico lato client) con javascript ed inviato subito al server che lo memorizza in una variabile di sessione.
Alla successiva richiesta si manda il codice generato lato client che se nel frattempo è stato ricaricato in locale con il trucco che dicevo sopra dovrebbe essere diverso da quello sul server e sarebbe dunque possibile bloccare la pagina...
Ovviamente ad ogni richiesta al server bisogna verificare se il codice session esiste già ... nel caso esiste ed è diverso o nullo allora posso bloccare tutto .. altrimenti è la prima richiesta e comincio il giro...

ho capito bene ?!!!

[cionci]

No il codice lo devi creare lato server e salvare nella sessione, poi dopo lo devi poi "stampare" all'interno del codice Javascript che lo deve usare.

[simo6784]

ok ... ma così mi ritrovo con lo stesso problema !!
poiche lato client il codice chiave creato anche se in MD5 è comunque visibile e se uno si copia l'HTML , lo modifica senza toccare quel codice è perfettamente in grado di riaprirlo in un altro tab e mantenere la pagina valida... come se non fosse stata modificata perchè non c'è un altra chiamata al server...

[simo6784]

.. e poi stavo pensando anche a quelle estensioni che hanno browser come firefox che permettono di modificare il codice html e javascript senza neanche aprire un altro tab...

questo è ancora più pericoloso ... si potrebbe inibire un controllo javascript in un batter d'occhio...

[cionci]

ok ... ma così mi ritrovo con lo stesso problema !!
poiche lato client il codice chiave creato anche se in MD5 è comunque visibile e se uno si copia l'HTML , lo modifica senza toccare quel codice è perfettamente in grado di riaprirlo in un altro tab e mantenere la pagina valida... come se non fosse stata modificata perchè non c'è un altra chiamata al server...
No...perché è una one-time password...cioè è valida solo per una operazione, appena questa viene effettuata il codice viene invalidato rimuovendolo dalla sessione.

[simo6784]

.. ma se la mofica al codice viene effettuata prima di quella operazione ?!! ...
scusa ma non risco a capire il discorso di questa one-time-psw ... mi sembra efficace solo se il submit della pagina è già avvenuto... ma se devo ancora farlo e prima di cliccare sul pulsantino SUBMIT vado a modificare del codice che effettua determinati controlli non corro il rischio cmq di bypassare qualche funzione ?!!!
IL codice ricaricato nel tab non viene dal server ma dalla pagina che ho già ricevuto e della quale mi sono salvato l'HTML in locale e che quindi sarà identica nel codice client (eccetto per le funzioni che vado a modificare) ricevuto e dunque con la chiave valida ... dopodichè dalla pagina del tab (che continua ad avere la sessione attiva..quindi non posso buttare fuori l'utente con la scusa SESSIONE SCADUTA) lancio il submit della form che nel metodo action punterà al server ed il gioco è fatto.

...forse non ho capito bene il discorso della one time psw ... ma mi sembra efficace solo in determinate circostanze...

..in che senso viene invalidato rimuovendolo dalla sessione ?!

[gugoXX]

Il metodo della one-time password puo' servirti per esempio per aggirare il problema delle variabili di sessione, ovvero quando stai utilizzando tecnologie session-less, quando non vuoi o quando il tuo server non puo' (o non ti permette) di usare le variabili di sessione.

scusa ma non risco a capire il discorso di questa one-time-psw ... mi sembra efficace solo se il submit della pagina è già avvenuto... ma se devo ancora farlo e prima di cliccare sul pulsantino SUBMIT vado a modificare del codice che effettua determinati controlli non corro il rischio cmq di bypassare qualche funzione ?!!!

Questo e' il punto.
NON e' il codice javascript che deve fare i controlli (presentation layer). Puoi bypassare qualunque funzione del javascript, ma e' il server che deve fare i controlli (business o logic layer), prima di agire e "servire" l'operazione richiesta.

Es: Ipotizza di fare un sito che permette la prenotazione dei voli aerei di una determinata compagnia.
Non si vuole che un cliente di una nazione possa prenotare un volo in partenza da un aeroporto che non e' di quella nazione.

Sul sito, in javascript, presentero' a ciascun utente solo gli aeroporti della propria nazione, cosicche' lui possa scegleire comodamente solo parametri gia' permessi.
In questo modo l'utente verra' guidato dalla UI nelle sue scelte, e non ricevera' messaggi di errore.

MA il codice di controllo deve essere sul server. E' il server che quando riceve la notifica di prenotazione deve controllare se l'aeroporto di partenza e' uno di quelli validi. NON ci si puo' fidare di cio' che e' arrivato dalla richiesta.

[cionci]

.. ma se la mofica al codice viene effettuata prima di quella operazione ?!! ...
scusa ma non risco a capire il discorso di questa one-time-psw ... mi sembra efficace solo se il submit della pagina è già avvenuto... ma se devo ancora farlo e prima di cliccare sul pulsantino SUBMIT vado a modificare del codice che effettua determinati controlli non corro il rischio cmq di bypassare qualche funzione ?!!!
Come ho scritto prima il metodo che ti ho spiegato serve per evitare che possa ricevere due richieste diverse, chiaro che se vado a modificare il codice i dati ricevuti devono essere validati a mano.
Il metodo che ti ho spiegato è fondamentale ad esempio quando:
- viene premuto due volte il tasto di conferma
- viene modificata una pagina dopo che la prima form è stata inviata
Per validare i dati ti devi comunque memorizzare l'elaborazione intermedia nelle variaibili di sessione. Se una procedura è composta da diversi passi, ad ogni passo dovrò memorizzare nella sessione i dati che compongono l'output dato all'utente. In questo modo se l'utente modifica la pagina, quando ricevo la richiesta i dati non corrispondono più con quelli che avevo memorizzato e mi accorgo della modifica.