Proteggi contro il clickjacking ma permetti il framing sul dominio?

3

Vorrei proteggermi dal clickjacking utilizzando le Opzioni X-Frame intestazione, ma occasionalmente inseriamo contenuti protetti nella versione non protetta del nostro sito 1 :

Poiché sembra che solo Firefox supporti attualmente la forma ALLOW-FROM dell'intestazione, sto considerando di servire condizionalmente l'intestazione:

  • Per impostazione predefinita, includi X-Frame-Options.
  • Se il tuo referrer è ^(.*\.)?example.com$ , lascia l'intestazione.

Sembra che funzionerebbe, e non è sicuro: se il browser di qualcuno non invia un referrer o un firewall aziendale lo spoglia, non ci pagano (il che è male), ma i nostri contenuti possono mai essere incorniciato su siti di terze parti (che sarebbe peggio).

Come funzionerebbe questa strategia nel mondo reale?

1 Alcuni dei nostri partner pubblicitari storicamente non hanno supportato la pubblicazione di annunci su HTTPS. Stiamo esaminando se questo è cambiato.

EDIT : per chiarire, in un caso annidiamo solo un iframe sicuro in una pagina non sicura: un utente supportato dalla pubblicità che acquista qualcosa per la prima volta in linea. Al momento non possiamo offrire l'intero sito tramite HTTPS per tali utenti e non vogliamo inviarli a una pagina separata o aprire una finestra popup.

Gli utenti privi di annunci ottengono sempre HTTPS e stiamo valutando la possibilità di pubblicare annunci anche su HTTPS.

    
posta s4y 18.12.2014 - 00:11
fonte

1 risposta

2

Per prima cosa consiglierei di semplificare il problema eliminando il contenuto sicuro offerto su un frame.

Nonfarescavicontroteolatuaorganizzazione,mastiamocercandodiaddestrareilmondononafidarsidiformecomequellapercuihaifornitoun'immagine.Sochequestononfapartedellatuadomanda,mal'immagineTransazionesicuranonsostituiscequellahttpscert.

Seituoipartnerditerzepartinonhannobisognodifunzionarecomeportaleperituoicontenutisicuri,eliminarequestapossibilitàsemplificherebbeiltuoproblema.Implementaeccezionianti-click-jackingperiltuocontenutosicuro.Fail'interapaginacomeHTTPS,nonsolounaformaounacornice.Sequalcunoutilizzailmiohotspotwifigratuitoinunaeroporto,possofacilmentecaricarel'interomodulooframeesostituirloconilmiochesembraidentico,completodiimmagineTransazionesicura.

Backonpoint,conl'eliminazionedicontenutiprotettichesemplificanoilproblema,ciòcherimaneèunproblemadicompatibilitàdelbrowserconX-Frame-Options.

C'èunadomanda over over stack che tratta questo , ma non sembra davvero risolvere il problema, ma risponde alla domanda: La compatibilità del browser continua a essere un problema.

Un'altra cosa che potresti prendere in considerazione, ho lavorato un po 'con porthole.js prima per la comunicazione cross-frame e una delle cose che mi ha fatto pensare è avere la possibilità per un frame figlio di convalidare il suo genitore, e per il genitore di convalidare il frame secondario.

Puoi verificare rapidamente la compatibilità di oblò tramite visitando il loro sito demo con i browser che ti interessano.

Inoltre, i tuoi partner potrebbero identificarsi con una querystring.

<iframe src="www.site.com/?partner=3tqdHB"></iframe>

Quindi, quando il rilevamento del click-jacking rileva una finestra genitore, verificare che esista il parametro querystring appropriato. Se lo fa, sfida il frame genitore per provare la sua identità, inviando un nonce.

Il frame genitore potrebbe quindi utilizzare il nonce fornito con la sua chiave per dimostrare la sua identità.

Se tutto funziona, non eseguire il tuo kill script, altrimenti, esegui kill script.

    
risposta data 18.12.2014 - 16:55
fonte

Leggi altre domande sui tag