È un po 'difficile rispondere in dettaglio quando non si forniscono informazioni critiche come l'architettura del sistema, la piattaforma, il server Web e le strutture coinvolte. Se le cose sono fatte bene, il rischio è trascurabile. Sapere se hanno fatto bene e continuare essere fatto bene ... ay, c'è il problema. Che dipende dalle informazioni di cui stavo parlando.
Mancando quelle informazioni ho intenzione di dare una risposta alla mia risposta con potrebbe e a volte ; per favore portami con me.
Are there any security risks that I should be aware of with this configuration?
Posso pensare ad alcuni di loro, ma sicuramente esistono altri. Molti di questi sono basati sul presupposto che possa esistere una vulnerabilità sul sito pubblico e si riferiscono a se e in che modo potrebbe influenzare il sito privato.
-
dirottamento di sessione e spigolatura. Su alcune piattaforme (principalmente stack PHP e * AMP), i dati di sessione potrebbero essere archiviati nel file system e potrebbe essere interrogabile per qualsiasi processo. Ciò significa che un processo anomalo sul server web pubblico potrebbe enumerare o indovinare i nomi dei file di sessione, leggerli e rivelare informazioni che potrebbero essere critiche.
-
bypass di autenticazione. Sempre a seconda della piattaforma, potrebbe essere possibile ingannare il sito sicuro per consentire l'accesso a un utente del sito pubblico. Ciò non ignora il controllo dell'indirizzo di rete, quindi se neghi l'accesso privato ad indirizzi esterni, questo specifico vettore di attacco viene sventato.
-
rifiuto del servizio. Naturalmente, il sito privato condivide alcune risorse con il sito pubblico e può essere soggetto a un rifiuto del servizio in questo modo.
-
attacchi cross-site. Ciò dipende troppo dalla struttura del sito per fornire dettagli. In generale, esistono misure di sicurezza per evitare che victimsite.com fornisca il codice che chiama home a evilhost.com . Molte di queste misure funzionano in misura minore, o non del tutto, se i due siti hanno la forma public.site.com e private.site.com . Questo vettore di attacco coinvolge qualcuno che fornisce un collegamento al sito pubblico a una vittima su all'interno (ad es. Tramite una e-mail) e un codice di scripting cross-site sul sito pubblico che tenterebbe di rubare informazioni o distruggere il sito privato. Se funziona, cioè se il sito pubblico è vulnerabile a questo tipo di attacco, funzionerà molto meglio sul sito privato sullo stesso dominio, che se fosse su un dominio diverso.
-
connessioni condivise, condivisibili o forzate. Se il sito pubblico è suddiviso, un utente malintenzionato è già all'interno del perimetro di identificazione del sito privato. Supponendo che possa recuperare le credenziali necessarie (e su alcune piattaforme, questo è possibile - richiede un hardening non predefinito per impedirlo), può identificarsi con altri host, ad es. il database con informazioni riservate, e si trova molto meglio (sulla maggior parte degli AMP *, che si avvicina al 100% dalla parte sbagliata) possibilità di essere autorizzato ad accedere.
-
accesso a livello di codice. Questo non è troppo probabile, perché richiederebbe altre vulnerabilità, ad esempio: accesso in scrittura tramite il processo del server Web e lo stesso livello di accesso tra i sottoprocessi appartenenti ai siti pubblici e privati. Tuttavia, fatta eccezione per alcune felici eccezioni (Debian e Ubuntu), questa è spesso la configurazione di default, a meno che il sysadmin non prenda passi specifici. Nel peggiore dei casi, ciò consente a una vulnerabilità sul sito pubblico di concedere a un utente malintenzionato l'accesso completo a tutto dalle password in poi relative al sito privato, oltre a modificare informazioni e rapporti, intercettando alcuni tipi di traffico (si pensi "webmail") e distruggi i dati.
Su un sistema correttamente protetto (ad es. qui , punti 6 in poi; alcuni indicatori su PHP ; e naturalmente OWASP ), avrei poche preoccupazioni. Ancora abbastanza da chiedermi, devo davvero farlo? ; non è come lo spazio del server è più costoso. Ma molto pochi. Soprattutto se gli amministratori di sistema tengono il passo con gli avvisi necessari.
D'altro canto, posizionare un sito privato e supposto per essere protetto su un sistema installato fuori dalla scatola e non troppo ben gestito (ad esempio un'installazione di Wordpress originale) equivale a evocare Murphy nel peggiore dei modi, e non posso consigliarlo troppo contro.