Domanda:
Ci sono vantaggi in termini di sicurezza derivanti dalla disponibilità di un sito Web da una sola scheda alla volta?
d33tah
2015-12-28 20:36:45 UTC
view on stackexchange narkive permalink

Ho appena scoperto che il sito web di una banca polacca costringe gli utenti ad aprirlo in una sola scheda del browser. Ad esempio, non puoi controllare la cronologia dei trasferimenti mentre cerchi un numero di conto a cui desideri inviare denaro. Non riesco a pensare a nessuna buona ragione per farlo, tranne possibili ragioni di sicurezza. Ci sono vantaggi in termini di sicurezza nel limitare un sito a un solo sito? In caso affermativo, cosa sono?

E se crei una seconda sessione in una nuova finestra, non in una scheda?
Immagino che non avrebbe avuto importanza, ma non ci avevo provato.
Come lo fanno rispettare? Passano un nuovo ID con ogni collegamento cliccato?
@StackzOfZtuff: C'è solo un ID di stato (può essere chiamato pagina, schermata, azione, ecc.) Che dice il tuo stato corrente nel flusso di lavoro dell'applicazione web (e molto spesso un singolo URL in cui il contenuto è gestito dinamicamente da un'overdose di script Ajax) . Se fai clic su un'opzione o invii un modulo non corrispondente al tuo stato attuale, tale applicazione potrebbe produrre un risultato fasullo, mostrare una pagina di errore o rimandarti alla home page.
Il sistema di valutazione / iscrizione online della mia università fa la stessa cosa ed è super fastidioso. Non penso che sia fatto per nessuna ragione di sicurezza tanto quanto lo è perché il sistema è progettato in modo orribile. (Il pulsante Indietro non funziona, tra le altre cose.)
C'è un motivo per cui non puoi fornire il nome della banca? Sarei interessato a esaminarlo ulteriormente.
Questo mi ricorda una società di servizi pubblici il cui sito web impedisce il copia / incolla. Suppongo che quello che volevano fosse scoraggiare le persone dal mantenere le loro informazioni in un documento di blocco note sul desktop, ma soprattutto mi ha solo causato frustrazione nel provare a usare il mio gestore di password.
È una domanda di sicurezza? Sta facendo una domanda relativamente soggettiva ("è ragionevole") e il testo della domanda non menziona la sicurezza o altri argomenti correlati.
Poiché la domanda era sul punto di essere chiusa, l'ho riformulata per renderla più obiettiva e incentrata sulla sicurezza. Spero di averlo fatto senza modificare l'intento originale dell'OP.
Migliora notevolmente la sicurezza guidando i clienti verso altre banche il cui web design non è danneggiato dal cervello.
@NeilSmithline: grazie, hai letto correttamente il mio intento. :)
@ColBeseder Conosco almeno una banca polacca che lo fa: mBank. Poi di nuovo potrebbero essere * leggermente * perdonati perché è un'app web a pagina singola, non un normale sito web.
Uno dei motivi non ancora menzionati potrebbe essere un'eccessiva protezione CSRF (in pratica non è necessario un nuovo token per ogni richiesta per impedire CSRF, ma solo un nuovo token ogni volta che si effettua il login o si cambia livello di privilegi). Ma più probabilmente è correlato allo stack tecnologico utilizzato come indicato dalle due risposte più votate.
@d33tah: Hai provato ad aprire due sessioni simultanee da due browser diversi? Funziona o invalida la tua prima sessione? Dalla mia esperienza, questo ha funzionato poiché era la soluzione alternativa che ho usato quando l'apertura di una nuova scheda non era consentita, ma in quest'ultimo caso potrebbe mostrare qualche problema di sicurezza dalla tua banca.
@GrandOpener Evidentemente non sono consapevoli di come funziona Internet o che la "visualizzazione dell'origine" è un'opzione comune del browser.
Ancora meglio: il sistema di tracciamento dei bug danneggiati dal cervello a $ work, che ha l'abitudine di mescolare il flusso di attività dalle tue più schede / finestre, se le hai. Quindi, se apri il bug 1 e il bug 2 (per visualizzarli) e fai clic su modifica sul bug 1, le tue modifiche potrebbero finire in bug2. Oppure potresti ottenere una finestra di modifica per bug2, ma nella finestra in cui avevi bug1.
Sette risposte:
#1
+80
Lie Ryan
2015-12-28 20:57:31 UTC
view on stackexchange narkive permalink

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.

Potrebbero non essere correlati alla sicurezza, ma ci sono ragioni per cui una webapp lo fa per progettazione.
Come ha detto una bugia, è fondamentalmente un cattivo design del sistema. Dal punto di vista dell'esperienza utente, è peggio se le persone sono costrette a fare qualcosa che non aiuta nemmeno davvero (ad esempio, raggiungere la sicurezza).
Questa funzione "force single tab" può essere considerata un teatro di sicurezza?
@Mindwin: se "force single tab" viene presentato per motivi di sicurezza, allora sì, IMO, è un teatro di sicurezza.
Non sono esattamente esperto in questo, ma c'è una possibilità che questo sia stato fatto per ridurre i falsi di richieste tra siti?
Uso solo un account Facebook falso su una scheda privata, mentre la navigazione normale è in modalità normale, questo garantisce che Facebook non possa tenere traccia di ciò che faccio al di fuori della scheda privata, interagire con i cookie di altri siti e così via ... ma è solo applicabile per finestre private
Per quello che vale, non è * sempre * una cattiva progettazione del sistema. Alcune pagine / app di tipo esame lo fanno per essere utilizzate sui Chromebook nelle scuole, quindi gli insegnanti non devono preoccuparsi che gli studenti cerchino le risposte in altre schede. Non quello che sta succedendo per l'OP, ma è comunque una cosa reale.
@Ramrod Potrebbe essere correlato a CSRF poiché il documento di ciascuna scheda avrebbe il proprio token anti-CSRF. Se lo stato della sessione sul server Web tiene traccia di un singolo token, ciascuna scheda interromperà il funzionamento dell'altra. D'altra parte, ciò tornerebbe di nuovo a una progettazione del sistema scadente perché si potrebbe memorizzare una raccolta di token e rimuoverli dopo l'uso.
Avevo l'impressione che, utilizzando Javascript, ogni scheda fosse in grado di leggere il contenuto dell'altra scheda, dando potenziale accesso di codice dannoso al documento della scheda della banca. Non è vero?
@corsiKa: Certamente non * dovrebbe * essere vero, anche se è possibile (per quanto ne so) che alcuni browser abbiano avuto un bug che potrebbe essere sfruttato in tal senso.
@Jefromi: non posso semplicemente aprire Wikipedia? A meno che non cerchi le cose in un'altra scheda della stessa piattaforma di e-learning e in qualche modo lo rendi robusto.
@Blaisorblade Ah, immagino di aver capito male: questo sito ti consente di aprire altre schede, ma non un'altra copia di se stesso? La cosa di cui stavo parlando è seriamente solo una scheda solo, nient'altro a lato, quindi niente Wikipedia.
@Jefromi Sì, cosa diversa; questo è fatto dal sito web bancario. Per fortuna, un sito Web che navighi non può impedirti di aprire altre schede: solo il browser ha quel privilegio.
#2
+47
WhiteWinterWolf
2015-12-29 00:07:06 UTC
view on stackexchange narkive permalink

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.

Contesterei che questo semplifichi la programmazione delle applicazioni, almeno oggi. Forse lo è stato in passato quando questi sistemi sono stati progettati, ma oggi ci sono innumerevoli framework moderni disponibili per assistere nella creazione di applicazioni web RESTful ben progettate. In effetti, sospetto che provare a creare un'app utilizzando un anti pattern come quello oggi sarebbe * più difficile * che crearne uno senza stato.
Progettare in questo modo sarebbe più economico solo se si riutilizza il progetto da un'applicazione client con stato pesante esistente. In quasi tutti gli altri progetti nativi per il Web, il client senza stato è più facile da costruire, più veloce e scalabile meglio.
Le webapp J2EE di @Ajedi32: sono un mondo completamente diverso dallo sviluppo web tradizionale. Accumula livelli di astrazione, fornisci una classe Java a cui colleghi un percorso e la tua applicazione non ha nemmeno accesso alla richiesta HTTP che viene astratta dal server delle applicazioni. Suppongo che tutto ciò possa implicare un approccio diverso nello sviluppo. Tuttavia, dove sono pienamente d'accordo con te è che, a mio * parere *, la maggior parte delle volte usare tale webapp J2EE è una decisione puramente gestionale (forse non la più saggia) e non una scelta tecnica poiché spesso porta più problemi che soluzioni.
@LieRyan: La mia risposta ad Ajedi32 si applica anche. Tale scelta può essere concepita solo in un'infrastruttura aziendale dove devi fare i conti con l'esistente. Se stai già inviando grandi somme di denaro a IBM per supportare la tua piattaforma WebSphere in cui la connessione backend è già funzionante e supportata (code JMS, integrazione SAP, ecc.), Potresti preferire di riutilizzarla per implementare la tua nuova interfaccia web invece di partendo da zero, anche se questo significa utilizzare tecnologie più pesanti e poco pratiche invece di tecnologie più moderne e di facile utilizzo.
+1 Rende la programmazione più facile per i programmatori di una certa mentalità piuttosto che in generale. I programmatori Java con uno sfondo non Web e client controllato riempiranno felicemente grandi quantità di stato nella sessione senza rendersi conto che stanno infrangendo le comodità di navigazione / usabilità che il Web "senza stato" fornisce naturalmente. Non è più sicuro (infatti ho visto che causa falle di sicurezza introducendo problemi di ToC / ToU) ma si adatta meglio a questa mentalità. È in calo in generale a causa della maggiore familiarità con il Web, ma lo si vede ancora nei buchi infernali delle imprese come le banche.
#3
+14
Rory Alsop
2015-12-30 04:31:50 UTC
view on stackexchange narkive permalink

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.

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/33682/discussion-on-answer-by-rory-alsop-are-there-security-advantages-gained-from-for) .
#4
+5
Filip Haglund
2015-12-29 03:07:44 UTC
view on stackexchange narkive permalink

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.

#5
+3
JamesRyan
2015-12-29 00:16:22 UTC
view on stackexchange narkive permalink

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.

Direi che stateful richiede più lavoro, dal momento che devi tenere traccia dello stato. Ora, se vuoi dire che qualcuno potrebbe provare a operare su dati non aggiornati (ad esempio spendere due volte i soldi), il tuo programma ** deve ** controllare comunque queste cose per prevenire malizia. Coprire un cattivo design con una coperta non lo farà bene.
#6
  0
SilverlightFox
2016-01-25 16:14:43 UTC
view on stackexchange narkive permalink

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.

#7
-3
m2kin2
2015-12-28 20:56:31 UTC
view on stackexchange narkive permalink

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

Una scheda all'interno di un browser condivide ancora l'archiviazione dei cookie, la cronologia, ecc. Con tutte le altre schede o finestre nel browser che consentono attacchi come CSRF. Non aiuta limitare l'utilizzo a una singola scheda, ma è invece necessario utilizzare un browser diverso o almeno un profilo del browser diverso.
Cosa ha a che fare la limitazione dei browser attuali a una singola scheda con la revisione del funzionamento del Web?
@SteffenUllrich In realtà, l'utilizzo di un sito Web sensibile su schede private aumenta solo la sicurezza e la privacy, utilizzo solo un account Facebook falso su una finestra privata, questo garantisce l'isolamento tra Facebook e tutto il resto che faccio su schede "normali"
@Freedo: Non esiste una scheda privata solo in modalità privata. Questa modalità è simile a un diverso profilo del browser in quanto non condivide alcun cookie, ecc. Con il profilo originale. Ma questi sono ancora condivisi tra diverse schede all'interno della modalità privata. A parte questo, la domanda riguardava la limitazione a una singola scheda (all'interno della normale modalità browser) e non la limitazione all'uso della modalità privata.
Strano, ho sempre pensato che i biscotti sarebbero stati comunque presentati da finestre private. Sì, l'ho provato e quindi solo la modalità privata non memorizza la cronologia sul lato client.
Non so perché Crockford abbia una così grande reputazione; questa è una delle tante cattive idee che ha.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...