C'è qualche problema di sicurezza nell'host di Wordpress sul server web principale?

2

Abbiamo ospitato il nostro blog Wordpress su una macchina virtuale Linux e la nostra applicazione web principale su un server IIS. Il nostro sito web è www.mainsite.com e wordpress è su www.blog.mainsite.com.

Ora è necessario che il blog appaia come www.mainsite.com/blog. Posso installare PHP, MySQL e Wordpress sul nostro server IIS sito principale; la mia domanda è se ci sono problemi di sicurezza e prestazioni? Ogni tanto, una nuova vulnerabilità si trova in Wordpress e PHP; Va bene portare queste tecnologie vulnerabili al nostro server web principale? Qualcuno può dire "se l'account amministratore del blog wordpress viene compromesso, ciò può causare problemi per l'applicazione Web principale?"

e se è una cattiva idea portare un nuovo stack di tecnologia sul nostro server web IIS principale, come possiamo ottenere www.mainsite.com/blog invece di www.blog.mainsite.com?

    
posta Goli E 29.12.2014 - 21:11
fonte

2 risposte

6

L'installazione di più software su qualsiasi macchina (quasi) aumenta sempre il numero di modi in cui la macchina può essere attaccata. Quindi è generalmente buona norma separare i componenti quando possibile. Supponiamo che un utente malintenzionato possa utilizzare un difetto nel blog wordpress per eseguire codice PHP, ora è di proprietà del server che ospita il sito principale.

Un altro problema che viene in mente con questa nuova configurazione è che ospitare il blog sullo stesso dominio del tuo sito principale può dare al blog l'accesso ai cookie impostati dal tuo sito principale. Quindi ora questi cookie potrebbero essere vulnerabili agli attacchi XSS sul sito wordpress, quando non lo sarebbero stati se il sito principale fosse ospitato su www.example.com e il blog su blog.example.com.

Modifica

Dato che hai chiesto: credo che l'amministratore di un sito wordpress possa installare plug-in / upload di file php, quindi se questo account fosse compromesso, anche la macchina sarebbe stata compromessa.

    
risposta data 29.12.2014 - 21:22
fonte
1

Un'alternativa sarebbe utilizzare il servizio di routing delle richieste dell'applicazione di IIS come una sorta di proxy per il server web.

Ecco alcune informazioni:

Routing della richiesta di applicazione:

Utilizzo di ARR come proxy diretto:

Dato che non c'è nulla di particolarmente stravagante da parte dell'utente, questa configurazione dovrebbe funzionare senza problemi.

** Il secondo articolo ha esattamente quello che stai cercando di fare.

    
risposta data 29.12.2014 - 21:57
fonte

Leggi altre domande sui tag