Ci sono vantaggi di sicurezza acquisiti costringendo un sito web a essere disponibile da una sola scheda alla volta?

In generale, no, non è ragionevole forzare gli utenti a una singola scheda. Non ci sono motivi di sicurezza tecnica per rendere un sito web disponibile solo per una singola scheda. Questo è generalmente comune solo a causa di un design del sistema scadente.

Forzare una singola scheda significa anche che quando esci, non lascerai intatti i tuoi dati sensibili in altre venti schede. Questa è una cattiva ragione, dato che un sito che si preoccupa di questo può usare localStorage o websocket per cancellare contemporaneamente tutte le schede quando si disconnette da una scheda.

Il fattore umano di sicurezza è una ragione marginale per cui alcuni siti potrebbero deliberatamente limitarsi a una singola scheda. Forzando una singola scheda, costringi le persone a concentrarsi su una cosa alla volta, e questo ti rende meno probabile che dimentichi qualcosa. IMO, questa è una cattiva ragione, in quanto gli svantaggi superano i vantaggi.

Questa limitazione non è causata da misure di sicurezza, ma semplicemente da misure economiche.

Questo comportamento osservato può essere effettivamente trovato in molte applicazioni Web interne aziendali e lo troverete collegato molto a Java J2EE Web Application Server (IBM WebSphere Application Server è il più diffuso).

Pur facendo affidamento su un client leggero (un browser Web di uso generale), tali applicazioni sono spesso (scarsamente) progettate nello stesso modo di quelle che utilizzano un client pesante (software eseguito da un file eseguibile installato sulla macchina).

I siti web sono generalmente progettati tenendo presente un modello di richiesta-risposta. Il progettista decide quali richieste sono consentite all'utente e quale dovrebbe essere l'elaborazione e la risposta del server appropriato. Ciò ti consente di aprire comodamente tutte le schede che desideri ogni volta che il browser invia una richiesta al server.

Ma le applicazioni web come quella che stai affrontando sono progettate pensando a un modello di transizione statale.

Con un software client pesante, sei vincolato a un flusso di lavoro molto preciso: quando fai clic su un elemento ti verranno proposte alcune opzioni e sarai costretto a sceglierne una o fare clic su Annulla se è disponibile, potresti non essere in grado di aprire direttamente alcune finestre senza passare prima da altre finestre o menu, alcune opzioni potrebbero non essere sempre accessibili o abilitate a seconda dell'azione in corso, ecc.

In qualsiasi momento sei in uno stato definito e, in base all'azione con i controlli dell'applicazione, passerai dallo stato corrente a un altro e così via. Ogni possibile transizione di stato è ben definita dal progettista dell'applicazione.

Tale applicazione web prende questo modello di sviluppo inizialmente progettato per applicazioni client pesanti e lo applica alle applicazioni web. Ovviamente questo non si adatta bene poiché, aprendo diverse schede, si confonde l'applicazione che non è in grado di determinare quale sia il tuo stato attuale: stai consultando il saldo del tuo conto o immettendo un nuovo bonifico? Entrambi non sono accettabili, puoi essere solo in uno stato alla volta! E non menziono nemmeno le funzionalità specifiche del browser come il pulsante Indietro o il bookmarking di una pagina specifica che spesso non sono supportate da tali applicazioni web.

Questa non è una scelta di sicurezza, ma economica dato che rende la programmazione delle applicazioni più facile, più rapida e quindi più economica.

Avendo lavorato con 8 banche che l'hanno implementato in un modo o nell'altro, sono convinto che sia una funzione di sicurezza importante. Trattandosi di una scheda è irrilevante, ma limitare a un'istanza è molto utile per ridurre molte vie di attacco.

Se autorizzi più di un'istanza, gli aggressori possono potenzialmente attaccare da un'altra macchina durante una sessione valida. Se ne permetti solo uno, allora molte varianti di questo sono rimosse.

Il modo generale in cui le banche l'hanno implementato è stato quello di controllare i token / cookie e chiudere tutte le sessioni esistenti non appena viene negoziata una nuova sessione, non portando con se una nuova scheda, browser o altro.

C'è una banca svedese che fa questo. Passano un token monouso su ogni richiesta, in modo che nessuna richiesta possa essere eseguita due volte. Ciò significa che se qualcuno riesce a rubare il tuo cookie di sessione, non possono usarlo senza che nessuno se ne accorga.

Si tratta di una piccola aggiunta in sicurezza (che potrebbe non essere nemmeno un'aggiunta in questi giorni, dal momento che SSL / TLS è migliorata) per un grande successo nell'esperienza utente.

Altre banche, come Klarna, utilizzano una soluzione di pagamento con un solo clic per un enorme incremento dell'esperienza utente, ma con un lavoro molto più difficile di messa in sicurezza.

In definitiva, la banca è responsabile di questo compromesso e limitare l'utente a una singola scheda potrebbe aiutare un po ', come ridurre il rischio di fuga di dati sensibili se un utente dimentica di chiudere tutti il schede.

Se si tratta di un'app di stato che apre le schede separate confonde l'utente perché i dati mostrati in una scheda non includeranno alcuna azione eseguita da un'altra scheda.

Questo non è un problema di sicurezza ma una scelta progettuale comune nelle applicazioni web perché consente operazioni più complesse senza il lavoro aggiunto per renderlo stateless.

Sì, sebbene impedisca all'applicazione di funzionare in schede diverse in modo accidentale.

Esiste una classe di vulnerabilità delle applicazioni Web denominate "difetti della logica aziendale" . Questi sono particolarmente diffusi quando c'è un processo in più fasi da seguire. Dando a un utente un token, che viene passato da una pagina all'altra, e viene modificato in ogni fase, si assicura che gli utenti seguano i processi a più fasi nell'ordine impostato. Ciò riduce il rischio che uno sviluppatore supponga che, poiché è stata raggiunta una determinata pagina, tutti i passaggi precedenti sono stati legittimamente seguiti.

Poiché il token viene passato da una pagina all'altra nei parametri GET o POST, l'apertura di un'altra pagina in un'altra scheda provoca la modifica del token, pertanto il token nella scheda originale non sarà più valido per la navigazione.

Questo metodo di passare un token attorno a quello che può essere convalidato nella sessione lato server protegge anche intrinsecamente da CSRF. La protezione dell'intero sito con questo metodo garantisce inoltre che nulla venga perso perché per ogni richiesta la convalida del token non viene mai ignorata. Questo può anche proteggere da un doppio clic dell'utente, ad es. un pulsante per il trasferimento, in quanto il token sarà valido solo per la prima richiesta e garantirà che tali azioni non vengano inviate per errore due volte.

Aiuta. Ti potrebbe piacere dare un'occhiata al suggerimento di douglas crockford di un Internet più sicuro attraverso l'uso di un motore di rendering basato su QT separato. Ha alcuni pregi.

I meriti sono: la natura dom e sandbox di un browser web è abrogata dall'uso di un motore di rendering separato per ogni pagina (supponendo che l'abbia letto correttamente), e quindi non ci sono dom o sandbox con cui uscire da , in caso di furto di cookie, che può accadere con più schede.

Oh ecco un link: link