Sto lavorando sulla sicurezza logica basata sulle informazioni dell’utente corrente, ad esempio: ‘se topic.creator.username è uguale a User.current().username’, permetto all’utente di modificare o eliminare l’argomento!
Il punto è che devo garantire alcune azioni basate sulla sessione dell’utente! Ho fatto alcuni test ed è per questo che sono qui a chiedervelo.
Attraverso JavaScript nel browser web (anche in modalità produzione), riesco a eseguire Discourse.User.current().set(‘username’, ‘sometestename’). In questo modo, alcune azioni nel mio sistema verrebbero abilitate solo con questa modifica. So che non è l’obiettivo del 99% degli utenti, ma al di là di questo caso, sapete come fare in modo che l’utente non possa manipolare le informazioni dell’utente?
Se modifichi le informazioni nel tuo browser locale, ciò non cambia nulla sul back-end.
L’utente è autenticato tramite un token di autenticazione, credo, quindi non puoi impersonare un altro utente verso il back-end:
Poiché non è possibile ingannare il server, non sarai in grado di apportare alcuna modifica come un altro utente.
Non appena aggiorni il browser, le tue modifiche locali verranno probabilmente cancellate. Nel peggiore dei casi, potresti compromettere lo stato dell’app JavaScript e dovrai cancellare la tua cache.
Come hai detto, il modo migliore sarebbe quindi ottenere sempre la sessione dell’utente corrente dal server back-end.
In questo modo, le modifiche alla cache dal browser non potrebbero avere alcun effetto! Sai dove potrei verificare che la sicurezza logica si basi sulla sessione dell’utente dal server back-end e non da PreloadStore?
Avvisami se sto indicando la strada sbagliata! Grazie Robert per l’aiuto!
Non sono un esperto di sicurezza, solo uno sviluppatore di app, ma tutte le modifiche persistenti possono essere effettuate solo sul server. Ciò che avviene nel browser in EmberJS è a vantaggio dell’utente per migliorare l’esperienza d’uso, ad esempio la memorizzazione nella cache per la velocità o il comportamento automatico dell’interfaccia simile a un’app. Questo non cambia il fatto che, in definitiva, ogni modifica persistente deve essere negoziata con il server Rails e, nel farlo, si avrà il permesso di farlo solo per l’utente loggato.
Lo stesso vale per il recupero di tutti i dati: il server Rails invierà solo i dati a cui l’utente loggato ha accesso.
Non penso che tu debba preoccuparti di questo, perché se qualcuno tentasse di aggirare queste misure, si fermerebbe al primo ostacolo: non c’è modo di ingannare l’API.
Sono preoccupato perché sto lavorando su alcune funzionalità in cui tale azione sarà disponibile o meno a seconda dell’utente: se sei il creatore dell’argomento, se sei il creatore del post. In questo modo devo validare in base alla sessione utente del backend.
Ad esempio, nel post l’utente può modificarlo, se è il creatore del post.
AGGIORNAMENTO: Come per le autorizzazioni dei post su Discourse, lo controllerò.
Ho analizzato il codice del plugin e la codebase relativa ai controlli dei post (azioni), per verificare su quali potessi intervenire maggiormente in termini di sicurezza.
Come analizzato! Dal lato front-end ci sono alcuni passaggi che verificano se l’utente può modificare o meno il post, come:
