La sicurezza aumenta utilizzando un sottodominio per cliente in un'app web?

Dipende da cosa è l'applicazione e da cosa è il controllo dei client su di essa. La stessa politica di origine si applica ancora, quindi è consigliabile utilizzare il sottodominio come perimetro di sicurezza, ma - come sempre, ci saranno alcuni accorgimenti.

I tuoi utenti possono ancora effettuare richieste tra domini con Condivisione delle risorse di origine incrociata . Se le intestazioni HTTP non possono essere modificate, perderebbero l'accesso alla risposta, ma, ad esempio, un utente potrebbe simulare un caricamento file silenzioso ad altri sottodominio senza problemi.

I tuoi clienti potrebbero anche, a volte inconsapevolmente, rilassare la stessa politica sulle origini. Ad esempio, se possono caricare file, molto probabilmente qualcuno caricherà allow-all crossdomain.xml . Inoltre, potevano impostare document.domain al dominio genitore in modo che tutti i sottodomini di pari livello potessero accedere al DOM.

Per quanto riguarda i cookie, l'attaccante può ancora impostarlo per il dominio genitore e altri sottodomini (del client vittima) otterrebbero comunque il cookie, i sottodomini non ti proteggeranno da questo, solo i domini separati lo farebbero.

Ci sono molti modi in cui le applicazioni installate su domini diversi potrebbero comunicare tra loro, alcuni di questi modi possono essere utilizzati per un attacco. Se sospetti che i tuoi clienti possano tentare di attaccarsi a vicenda, presta particolare attenzione per impedire Forgery di richiesta cross-site (token!) e Correzione della sessione . Ad esempio, imposta un nome diverso per i cookie di sessione per ogni sottodominio. Archiviare le sessioni sul lato server in un archivio per client (ovvero non nella directory common / tmp) e negare i cookie con ID di sessione sconosciuti al server.

Commenti generali. Esistono varie architetture, con un livello diverso di robustezza per le vulnerabilità della sicurezza nel codice lato server.

La strategia più efficace consiste nell'utilizzare un dominio non correlato per ciascun cliente (ad esempio, customera.com, customerb.com). Questo ti offre tutti i vantaggi della politica della stessa origine. Ad esempio:

• Se un cliente trova un modo per caricare Javascript dannoso sul proprio sito, non può attaccare altri clienti (il criterio di origine identica del browser non consente al codice malevolo di interferire con altri domini).

• Se il sito di un cliente presenta una vulnerabilità di sicurezza (ad esempio, XSS), gli autori di attacchi non possono utilizzarlo come punto di partenza per attaccare gli altri clienti.

Tuttavia, l'utilizzo di un dominio non correlato per cliente ti fa pagare il costo di un dominio separato per cliente. Questo costo potrebbe non essere necessario, a seconda della particolare applicazione.

La strategia più avanzata consiste nell'utilizzare un sottodominio diverso per cliente (ad es. customera.mysite.com, customerb.mysite.com). Questo ti offre la maggior parte dei vantaggi della politica della stessa origine, ma con alcuni avvertimenti e lacune:

• Se non fai attenzione, il codice sul sito di un cliente potrebbe comunque essere in grado di leggere i cookie dai siti di altri clienti. In particolare, è importante che tutti i cookie impostati dal sito per il cliente A debbano avere il loro attributo dominio impostato su customera.mysite.com , non .mysite.com (come spiegato da @dgarcia). Se controlli il codice lato server e il codice lato client, puoi farlo rispettare. Tuttavia, se esegui il codice fornito dal cliente, potrebbe essere più difficile applicare questo requisito e potresti voler andare con un dominio non correlato per cliente.

• Indipendentemente dal modo in cui configuri il tuo sito, il sito di un cliente avrà comunque il potere di impostare i cookie per il sito di un altro cliente. Questo è un vuoto poco conosciuto nella politica della stessa origine; customera.mysite.com può impostare un cookie con l'attributo di dominio .mysite.com , e quindi quel cookie verrà inviato insieme a tutte le richieste a customerb.mysite.com. (Vedi anche document.domain per altre vie d'attacco). Questa è una potenziale violazione dell'isolamento, le cui implicazioni possono variare da "nessuna" a "serie". Non esiste un buon modo per prevenire questo vettore di attacco. Pertanto, se si utilizza un sottodominio diverso per cliente, potrebbe essere necessario che il codice lato server sia interamente sotto il proprio controllo ed esente da vulnerabilità; e lo stesso per tutti i Javascript pubblicati sul sito di ciascun cliente.

  Questa limitazione potrebbe essere accettabile nella tua applicazione o potrebbe non esserlo. Se non è un rischio accettabile, puoi utilizzare domini non correlati per ciascuno dei tuoi clienti.

La strategia meno solida è quella di servire tutti i tuoi clienti dallo stesso dominio (ad es., mysite.com/customera, mysite.com/customerb o mysite.com con un accesso diverso per cliente). Lo svantaggio di questo approccio è che non è più possibile fare affidamento sulla politica della stessa origine del browser per aiutarti a tenere separati i clienti, quindi ora la responsabilità passa al tuo server. Non fraintendermi: questo approccio può sicuramente essere sicuro se il tuo codice è privo di vulnerabilità e il tuo codice garantisce che nessun cliente possa attaccare nessun altro. Questa architettura è probabilmente la più diffusa sul web: la maggior parte dei siti web che usano l'utente usano questa architettura. La limitazione di questa architettura è che è meno affidabile per i difetti del codice lato server; un bug XSS, un errore di disinfezione o un altro problema nel codice possono consentire a un cliente di attaccarne un altro o violare l'isolamento del cliente.

Consigli per la tua situazione particolare. Per la tua applicazione, immagino che ognuno di questi andrebbe bene. Sembra che tu non abbia un'applicazione ad alto valore, quindi questa non è una situazione ad alta sensibilità ad alto rischio. Inoltre, sembra che non ci sia modo per i clienti di caricare contenuti, caricare documenti HTML, caricare Javascript, caricare documenti, ecc. Queste operazioni sono rischiose e se il tuo sito le ha consentite, sarei più propenso a utilizzare diversi sottodomini o domini non correlati; ma dal momento che il tuo sito non lo consente, non vedo un motivo valido per cui hai bisogno di domini diversi.

Per ragioni simili, non vedo una strong motivazione per cui è necessario un certificato SSL diverso per cliente. Pertanto, sospetto che tu stia bene con un'architettura in cui utilizzi un singolo dominio e faccia affidamento sul codice del server per autenticare ciascun cliente e applicare i controlli di accesso appropriati per proteggere i clienti gli uni dagli altri.

Impedisce inoltre alle persone di vedere e impostare cookie l'uno per l'altro, invece di avere i clienti sotto un'unica radice. Difficile valutare quanto sia importante senza conoscere la tua app.

A proposito, i certificati con caratteri jolly sono pericolosi: la casella più sensibile è protetta solo come la più debole. I cerattivi con caratteri jolly tendono ad abituarsi molto dopo averli ricevuti. Le persone li mettono su server di posta, Sharepoint, ecc. Non sono sicuri se usati correttamente, ma sono piuttosto una tentazione di usarli pericolosamente e, per questioni di politica, li evito.