In genere no, non è ragionevole forzare gli utenti a una singola scheda. Non esistono motivi tecnici di sicurezza per rendere un sito Web disponibile solo per una singola scheda. Questo è generalmente comune solo a causa della cattiva progettazione del sistema.

Forzare una singola scheda significa anche che quando ti disconnetti, non lascerai le tue informazioni sensibili intonacate in altre venti schede. Questa è una scarsa ragione, tuttavia, poiché un sito che si preoccupa di questo può utilizzare localStorage o websocket per cancellare simultaneamente tutte le schede quando si disconnette da una scheda.

Il fattore umano della sicurezza è una ragione marginale per cui alcuni siti potrebbe 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, questo è un motivo infausto, poiché gli svantaggi superano i vantaggi.

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

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

Pur facendo affidamento su un client leggero (un browser web generico), tali applicazioni sono spesso (scarsamente) progettate allo stesso modo a quelli che utilizzano un client pesante (software eseguito da un file eseguibile installato sulla macchina).

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

Ma le applicazioni web come quella che stai affrontando sono progettate con un modello di transizione di stato in mente.

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 fai clic sul pulsante 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 delle tue attuali azione, ecc.

In qualsiasi momento ti trovi in ​​uno stato definito e, a seconda della tua azione con i controlli dell'applicazione, passerai dal tuo stato attuale a un altro, e così via. Ogni possibile transizione di stato è ben definita dal progettista dell'applicazione.

Tale applicazione web prende semplicemente questo modello di sviluppo inizialmente progettato per applicazioni client pesanti e lo applica alle applicazioni web. Ovviamente questo non scala bene poiché, aprendo più tab, stai confondendo l'applicazione che non è in grado di determinare qual è il tuo stato attuale: stai consultando il saldo del tuo conto o stai inserendo un nuovo bonifico? Entrambi non sono accettabili, puoi essere solo in uno stato alla volta! E non menziono nemmeno le caratteristiche specifiche del browser come il pulsante Indietro o il bookmark di una pagina specifica che spesso non sono supportate da tali applicazioni web.

Questa non è una scelta di sicurezza, solo economica poiché rende l'applicazione programmazione più semplice, veloce e quindi più economica.

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

Se si consente più di un'istanza, gli aggressori possono potenzialmente attaccare da un'altra macchina durante una sessione valida. Se ne consenti solo uno, la maggior parte delle varianti viene rimossa.

Il modo in cui quelle banche lo hanno implementato era controllare i token / cookie e chiudere tutte le sessioni esistenti non appena viene negoziata una nuova sessione, non trasportava se si trattava di una nuova scheda, browser o altro.

C'è una banca svedese che lo sta facendo. Passano un token monouso su ciascuna 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 può usarlo senza che nessuno se ne accorga.

È una piccola aggiunta alla sicurezza (che potrebbe anche non essere un'aggiunta in questi giorni, dal momento che SSL / TLS è migliorato) per un successo abbastanza grande nell'esperienza utente.

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

In definitiva, la banca è responsabile di fare questo compromesso e limitare l'utente a una singola scheda potrebbe aiutare in qualche modo, ad esempio ridurre il rischio di fuga di dati sensibili se un utente dimentica di chiudere tutto le schede.

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

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

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

Esiste una classe di vulnerabilità delle applicazioni web chiamate "difetti della logica aziendale". Questi sono particolarmente diffusi quando è necessario seguire un processo in più fasi. Assegnando a un utente un token, che viene passato da pagina a pagina e viene modificato a ogni passaggio, si garantisce che gli utenti seguano i processi in più passaggi nell'ordine impostato. Ciò mitiga il rischio che uno sviluppatore presuma che, poiché è stata raggiunta una determinata pagina, tutti i passaggi precedenti siano stati legittimamente seguiti.

Poiché il token viene passato da una pagina all'altra nei parametri GET o POST, aprendo un'altra pagina in un'altra scheda fa sì che il token venga modificato, e quindi il token nella scheda originale non sarà più valido per la navigazione.

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

Aiuta. Potresti 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 io lo legga correttamente), e quindi non c'è dom o sandbox con cui evadere, in caso di furto di cookie, che può accadere con più schede.

Oh, ecco un link: http://www.infoq.com/ news / 07/2015 / douglas-crockford-new-web-upgrade