È ragionevole mantenere il pannello di controllo in sottodominio o dominio separati?

Would implementation of separation of frontend and backend increase website security in any noticeable or reasonable way?

Sì. La divisione delle interfacce su due nomi host o, in effetti, due numeri di porta o protocolli (HTTP / HTTPS), potrebbe fornire due origini JavaScript diverse. Ciò impedisce che qualsiasi attacco XSS (cross-site-scripting) accessibile su un sito si infetti automaticamente nell'altro sito.

Ad esempio, se hai una vulnerabilità di tipo HTML-injection nel tuo sito pubblico, potrebbe includere alcuni JavaScript che caricano automaticamente l'interfaccia di amministrazione e simulano l'utente premendo il pulsante rosso destroy-the-site (o qualunque altra caratteristica sensibile è Là). Se un amministratore ha sfogliato la pagina pubblica compromessa mentre aveva una sessione attiva sul sito di amministrazione, il sito andava a gonfie vele.

Con due origini diverse, il codice JavaScript iniettato su un'origine non può interagire con i controlli sull'altro, quindi il danno è limitato a tutto ciò che può essere fatto sul sito pubblico.

(Come problema collaterale, avere sessioni di accesso separate per ogni interfaccia può anche mitigare le vulnerabilità XSS e cross-site request forgery, in quanto è meno probabile che l'amministratore abbia effettuato l'accesso al sito admin nel momento in cui sfoglia il pubblico sito. È possibile avere sessioni di accesso separate o combinate con o senza nomi host diversi, ma in genere nomi host distinti vi daranno accessi separati, a meno che non abbiate lavorato in modo specifico intorno a questo.

Separare le interfacce del pubblico interno da hostname è generalmente una soluzione utile per questo motivo, ma ovviamente lo scripting cross-site è solo un aspetto secondario della sicurezza webapp e non dovresti immaginare che ti dia protezione contro l'altra applicazione e problemi di sicurezza dell'infrastruttura come DDoS.

(E sì, il commento sulla sicurezza del controllo accessi è irrilevante a causa di DDoS è completamente privo di senso: si tratta di attacchi quasi del tutto estranei, fatti da persone diverse per ragioni diverse: quanto si vuole concentrare sul contrastare ognuno dovrebbe essere guidato da il modello di minaccia per la tua applicazione, ma entrambi i tipi di attacchi sono comuni e l'esistenza di uno non è una scusa per ignorare l'altro. In genere un DoS da solo è considerato un attacco minore dell'intrusione o della perdita di dati, ma di nuovo dipende dal modello di minaccia: un attaccante ha qualcosa da guadagnare rendendo il servizio non disponibile? è abbastanza critico da causare gravi inconvenienti quando non è attivo?)

Mettere l'interfaccia di amministrazione su un dominio diverso è pura sicurezza per oscurità. Non importa quanto tu possa rendere l'URL oscuro, purché possa essere raggiunto dall'Internet pubblica, devi prendere in considerazione la possibilità che un giorno diventerà di dominio pubblico.

Ma anche quando si presume che SbO potrebbe essere un vantaggio per te, la registrazione di un altro dominio solo per la tua console di amministrazione potrebbe essere controproducente per la massima oscurità. Tieni presente che le registrazioni dei domini sono pubbliche. Qualcuno potrebbe accidentalmente scoprire che il dominio example.management è registrato e che il proprietario del dominio sei tu, che potrebbe attirare la loro attenzione. Ma un'interfaccia di amministrazione posizionata su un URL oscuro sul dominio stesso non lascia alcuna traccia pubblica della sua esistenza in qualsiasi luogo (purché il server sia configurato correttamente).

Bottom-line: non cercare di nascondere la tua interfaccia di amministrazione. Dovresti piuttosto investire quell'energia per svilupparla in modo sicuro in modo che anche quando tutto il mondo cerca di accedervi, non avrà successo.

One of my colleges claims, that nowadays intruders doesn't care for something like breaking into account or control panel or gaining someone's password. Nowadays intrusions are based on DDoS attacks and physically "killing" server.

Questo è sbagliato. Ci sono state molte intrusioni nel servizio di alto profilo con l'intenzione di ottenere ultimamente gli indirizzi email e le password degli utenti. Si può solo immaginare quante di queste violazioni si verificano ogni giorno, ma non vengono mai rilevate o segnalate al pubblico. Tuttavia, un'interfaccia di amministrazione vulnerabile è solo uno dei tanti potenziali vettori di attacco che possono portare a una violazione dei dati. Per informazioni sugli errori più comuni che portano a vulnerabilità del sito Web, consulta la lista dei primi dieci OWASP .

Un attacco DoS (denial-of-service) è un modo per causare problemi al proprietario di un sito Web, ma non "uccide fisicamente" un server. Rende il server difficile da raggiungere solo durante l'attacco, ma non provoca danni permanenti e, cosa più importante, non compromette alcun dato sul server. Vengono spesso eseguiti perché richiedono quasi nessuna esperienza tecnica da eseguire, ma sono lontani da una seria minaccia per la sicurezza.