Proteggi una singola pagina in un sito se il sito è violato?

Il principio di SSL è che quando il browser client visualizza https://secure.example.com/whatever.html , la barra degli URL nel browser mostra quell'URL esatto e l'utente umano può essere sicuro del fatto che ciò che vede è davvero ciò che il server possiede veramente il nome secure.example.com ha deciso di inviare in quel momento. Questo è completamente estraneo a qualsiasi cosa accada con qualsiasi altro sito, sia esso main.example.com .

E questo è tutto.

Questo significa che se si utilizza un iframe non c'è alcuna barra URL e quindi nessuna garanzia. Dal punto di vista dell'utente, quando si connette a main.example.com , vede ciò che quel server desidera che visualizzi; se il server è sotto il completo controllo dell'aggressore, l'utente vede ciò che l'utente malintenzionato vuole che l'utente veda. In particolare, l'autore dell'attacco non vorrà che l'utente veda la versione iframed di https://secure.example.com/ ; invece, l'attaccante servererà un'immagine che assomiglia alla pagina sicura, ma non è la cosa reale. Poiché si tratta di un iframe, l'utente non può vedere la differenza. La barra degli URL è il fondamento della sicurezza HTTPS . Altrimenti, sono solo immagini, che sono facilmente contraffatte.

Non c'è davvero salvezza per un sito compromesso. Nessuna quantità di SSL, Ajax o iframe la risolveranno.

SSL protegge solo la trasmissione e l'autenticità della connessione server / client. Non aiuta a proteggere il contenuto sul server in questione.

Per risolvere il tuo problema, devi creare un hash del contenuto e firmarlo con la tua chiave privata aziendale. L'utente può ora utilizzare la chiave pubblica per verificare che il contenuto non sia stato manomesso.

Se mantieni la tua chiave privata, beh, privata, allora questo approccio è estremamente sicuro.

Puoi utilizzare qualcosa come GnuPG per implementarlo.

Aggiornamento: Se qualcuno ha hackerato il tuo sito "principale", può pubblicare qualsiasi contenuto desideri, compreso falsificare il contenuto del tuo iframe "sicuro". Non c'è nulla che tu possa fare al riguardo, tranne assicurarti che il tuo sito non sia compromesso in primo luogo. Scusate. L'approccio che firma il contenuto con gnupg funziona ancora, ma richiede all'utente di controllarlo autonomamente usando la tua chiave pubblica.

Non penso che cercare di nascondere una violazione sia l'approccio migliore, dovresti probabilmente concentrarti prima sulla revisione della sicurezza, magari assumere un pentester professionista se la tua azienda è davvero preoccupata per la sicurezza piuttosto che per la sua immagine pubblica.

Detto questo, vedo 3 diversi problemi che devi risolvere se vuoi continuare a seguire questa strada:

1. Scopri se la pagina principale è stata compromessa.
2. Come eseguire il failover sul server secondario.
3. Non viene compromesso il server secondario.

Quello che farei per 2 è probabilmente un approccio DNS, quando si rileva che la pagina è stata modificata si modifica il nome del dominio principale per puntare all'indirizzo del server secondario, è necessario un provider DNS che offra un'API a fai questo in modo programmatico.

Per il problema 3 devi avere il server secondario su un provider di rete / hosting completamente diverso, solo per essere al sicuro, e avere solo una singola pagina statica.

Il problema 1 potrebbe essere il più difficile, dal momento che ci sono tanti modi per modificare un sito, oppure l'autore dell'attacco potrebbe non modificarlo affatto.

Ricordo anni fa che esisteva un fornitore che forniva una soluzione hardware al problema che descrivi.

Era un dispositivo di rete in linea. Dovresti generare un checksum per la pagina che desideri proteggere e il dispositivo dovrebbe convalidare il checksum prima di consentire la pubblicazione del contenuto.

Potresti anche creare stop & vai a parole. (la maggior parte dei WAF oggi lo farà)

Non so se la compagnia è ancora in giro o no ... Farò qualche ricerca. Non ricordo il loro nome.

EDIT: ho esaminato alcuni vecchi biglietti da visita e la società si chiamava Vericept. Colpisco il sito Web e sembrano Trustwave e sono nello spazio DLP. Potrebbero ancora avere un dispositivo che faccia ciò che ho menzionato sopra.