Frame Buster Buster ... codice buster necessario

Supponiamo che non desideri che altri siti "modellino" il tuo sito in un <iframe>:

<iframe src="http://example.org"></iframe>

Quindi inserisci JavaScript anti-framing e anti-frame in tutte le tue pagine:

/* break us out of any containing iframes */
if (top != self) { top.location.replace(self.location.href); }

Eccellente! Ora "rompi" o rompi automaticamente qualsiasi iframe contenente. Tranne un piccolo problema.

A quanto pare, il tuo codice di frame-busting può essere eliminato , come mostrato qui :

<script type="text/javascript">
    var prevent_bust = 0  
    window.onbeforeunload = function() { prevent_bust++ }  
    setInterval(function() {  
      if (prevent_bust > 0) {  
        prevent_bust -= 2  
        window.top.location = 'http://example.org/page-which-responds-with-204'  
      }  
    }, 1)  
</script>

Questo codice esegue le seguenti operazioni:

• incrementa un contatore ogni volta che il browser tenta di spostarsi dalla pagina corrente, tramite il window.onbeforeunloadgestore eventi
• imposta un timer che si attiva ogni millisecondo setInterval()e, se vede incrementare il contatore, cambia la posizione corrente in un server di controllo dell'attaccante
• quel server serve una pagina con codice di stato HTTP 204 , che non fa navigare il browser da nessuna parte

La mia domanda è - e si tratta più di un puzzle JavaScript che di un problema reale - come si può sconfiggere il busto del frame-busting?

Ho avuto alcuni pensieri, ma nulla ha funzionato nei miei test:

• il tentativo di cancellare l' onbeforeunloadevento tramite onbeforeunload = nullnon ha avuto alcun effetto
• l'aggiunta di un alert()processo interrotto informa l'utente che stava accadendo, ma non ha interferito in alcun modo con il codice; facendo clic su OK, il busting continua normalmente
• Non riesco a pensare ad alcun modo per azzerare il setInterval()timer

Non sono un programmatore JavaScript, quindi ecco la mia sfida per te: hey buster, riesci a sballare il frame-busting buster?

Non sono sicuro che questo sia fattibile o meno, ma se non riesci a rompere il frame, perché non visualizzare semplicemente un avviso. Ad esempio, se la tua pagina non è la "pagina principale", crea un metodo setInterval che tenti di rompere il frame. Se dopo 3 o 4 tentativi la tua pagina non è ancora la pagina principale, crea un elemento div che copra l'intera pagina (casella modale) con un messaggio e un link come ...

Stai visualizzando questa pagina in una finestra non autorizzata - (Blah blah ... potenziale problema di sicurezza)

fai clic su questo link per risolvere questo problema

Non è il migliore, ma non vedo in alcun modo che possano uscirne.

FWIW, la maggior parte dei browser attuali supporta la direttiva X-Frame-Options: deny , che funziona anche quando lo script è disabilitato.

IE8:
http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx

Firefox (3.6.9)
https://bugzilla.mozilla.org/show_bug.cgi?id=475530
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header

Chrome / Webkit
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
http://trac.webkit.org/changeset/42333

Abbiamo utilizzato il seguente approccio in uno dei nostri siti Web da http://seclab.stanford.edu/websec/framebusting/framebust.pdf

<style>
 body { 
 display : none   
}
</style>
<script>
if(self == top) {
document.getElementsByTagName("body")[0].style.display = 'block';
}
else{
top.location = self.location;
}
</script>

Venne con questo, e sembra funzionare almeno in Firefox e nel browser Opera.

if(top != self) {
 top.onbeforeunload = function() {};
 top.location.replace(self.location.href);
}

Considerando l'attuale standard HTML5 che ha introdotto sandbox per iframe, tutti i codici di busting dei frame forniti in questa pagina possono essere disabilitati quando l'attaccante utilizza sandbox perché limita l'iframe a seguire:

allow-forms: Allow form submissions.
allow-popups: Allow opening popup windows.
allow-pointer-lock: Allow access to pointer movement and pointer lock.
allow-same-origin: Allow access to DOM objects when the iframe loaded form same origin
allow-scripts: Allow executing scripts inside iframe
allow-top-navigation: Allow navigation to top level window

Si prega di consultare: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Ora, considera l'attaccante usato il seguente codice per ospitare il tuo sito in iframe:

<iframe src="URI" sandbox></iframe>

Quindi, tutto il codice di busting del frame JavaScript non riuscirà.

Dopo aver verificato tutto il codice di frame busing, funziona solo questa difesa in tutti i casi:

<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
   if (self === top) {
       var antiClickjack = document.getElementById("antiClickjack");
       antiClickjack.parentNode.removeChild(antiClickjack);
   } else {
       top.location = self.location;
   }
</script>

quello originariamente proposto da Gustav Rydstedt, Elie Bursztein, Dan Boneh e Collin Jackson (2010)

Dopo aver riflettuto per un po ', credo che questo mostrerà loro chi è il capo ...

if(top != self) {
  window.open(location.href, '_top');
}

L'utilizzo _topcome parametro target per window.open()lo avvierà nella stessa finestra.

if (top != self) {
  top.location.replace(location);
  location.replace("about:blank"); // want me framed? no way!
}

Ho intenzione di essere coraggioso e gettare il mio cappello sul ring su questo (così com'è), vedere quanti voti negativi posso raccogliere.

Ecco il mio tentativo, che sembra funzionare ovunque l'ho testato (Chrome20, IE8 e FF14):

(function() {
    if (top == self) {
        return;
    }

    setInterval(function() {
        top.location.replace(document.location);
        setTimeout(function() {
            var xhr = new XMLHttpRequest();
            xhr.open(
                'get',
                'http://mysite.tld/page-that-takes-a-while-to-load',
                false
            );
            xhr.send(null);
        }, 0);
    }, 1);
}());

Ho inserito questo codice nel <head>e lo ho chiamato dalla fine del <body>per assicurarsi che la mia pagina sia resa prima che inizi a discutere con il codice maligno, non so se questo è l'approccio migliore, YMMV.

Come funziona?

... ti sento chiedere - beh, la risposta onesta è, non proprio so . Ci sono voluti molti tentativi per farlo funzionare ovunque stavo testando, e l'effetto esatto che ha varia leggermente a seconda di dove lo si esegue.

Ecco il pensiero dietro di esso:

• Impostare una funzione per l'esecuzione all'intervallo più basso possibile. Il concetto alla base di una qualsiasi delle soluzioni realistiche che ho visto è quello di riempire lo scheduler con più eventi di quanti ne abbia il frame buster-buster.
• Ogni volta che la funzione viene attivata, prova a cambiare la posizione del riquadro superiore. Requisito abbastanza ovvio.
• Pianifica anche una funzione da eseguire immediatamente che richiederà molto tempo per il completamento (impedendo così al buster-buster del telaio di interferire con il cambio di posizione). Ho scelto un XMLHttpRequest sincrono perché è l'unico meccanismo a cui riesco a pensare che non richiede (o almeno richiede) l'interazione dell'utente e non mastica il tempo di CPU dell'utente.

Per il mio http://mysite.tld/page-that-takes-a-while-to-load(il bersaglio dell'XHR) ho usato uno script PHP che assomiglia a questo:

<?php sleep(5);

Che succede?

• Chrome e Firefox attendono i 5 secondi mentre l'XHR è completo, quindi reindirizzano correttamente all'URL della pagina incorniciata.
• IE reindirizza praticamente immediatamente

Non puoi evitare i tempi di attesa in Chrome e Firefox?

Apparentemente no. All'inizio ho indicato l'XHR a un URL che restituiva un 404 - questo non funzionava in Firefox. Quindi ho provato l' sleep(5);approccio che alla fine ho ottenuto per questa risposta, quindi ho iniziato a giocare con la lunghezza del sonno in vari modi. Non sono riuscito a trovare un modello reale per il comportamento, ma ho scoperto che se è troppo corto, in particolare Firefox non giocherà a palla (Chrome e IE sembrano essere abbastanza ben educati). Non so quale sia la definizione di "troppo breve" in termini reali, ma 5 secondi sembra funzionare ogni volta.

Se qualche ninja Javascript di passaggio vuole spiegare un po 'meglio cosa sta succedendo, perché questo è (probabilmente) sbagliato, inaffidabile, il peggior codice che abbia mai visto ecc. Ascolterò felicemente.

A partire dal 2015, è necessario utilizzare la frame-ancestorsdirettiva CSP2 per questo. Questo è implementato tramite un'intestazione di risposta HTTP.

per esempio

Content-Security-Policy: frame-ancestors 'none'

Naturalmente, non molti browser supportano ancora CSP2, quindi è consigliabile includere la vecchia X-Frame-Optionsintestazione:

X-Frame-Options: DENY

Consiglierei di includerli entrambi, altrimenti il ​​tuo sito continuerebbe a essere vulnerabile agli attacchi Clickjacking nei vecchi browser e, naturalmente, otterrai frame indesiderati anche senza intenzioni dannose. La maggior parte dei browser si aggiorna automaticamente al giorno d'oggi, tuttavia si tende comunque a bloccare gli utenti aziendali su vecchie versioni di Internet Explorer per motivi di compatibilità delle applicazioni legacy.

Ok, quindi sappiamo che erano in una cornice. Quindi location.href passa a un'altra pagina speciale con il percorso come variabile GET. Spieghiamo ora all'utente cosa sta succedendo e forniamo un collegamento con un'opzione target = "_ TOP". È semplice e probabilmente funzionerebbe (non l'ho testato), ma richiede una certa interazione da parte dell'utente. Forse potresti segnalare all'utente il sito offensivo e creare una sorta di vergogna di click jackers sul tuo sito da qualche parte .. Solo un'idea, ma è notte di lavoro ..

Tutte le soluzioni proposte impongono direttamente un cambiamento nella posizione della finestra in alto. Cosa succede se un utente desidera che il frame sia presente? Ad esempio il frame superiore nei risultati delle immagini dei motori di ricerca.

Ho scritto un prototipo in cui per impostazione predefinita tutti gli input (collegamenti, moduli ed elementi di input) sono disabilitati e / o non fanno nulla quando attivati.

Se viene rilevato un frame contenente, gli input vengono lasciati disabilitati e viene visualizzato un messaggio di avviso nella parte superiore della pagina. Il messaggio di avviso contiene un collegamento che aprirà una versione sicura della pagina in una nuova finestra. Ciò impedisce che la pagina venga utilizzata per il clickjacking, pur consentendo all'utente di visualizzare i contenuti in altre situazioni.

Se non viene rilevato alcun frame contenente, gli ingressi sono abilitati.

Ecco il codice È necessario impostare gli attributi HTML standard su valori sicuri e aggiungere attributi aggiuntivi che contengono i valori effettivi. Probabilmente è incompleto e per la massima sicurezza gli attributi aggiuntivi (sto pensando ai gestori di eventi) dovranno probabilmente essere trattati allo stesso modo:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
  <head>
    <title></title>
    <script><!--
      function replaceAttributeValuesWithActualOnes( array, attributeName, actualValueAttributeName, additionalProcessor ) {
        for ( var elementIndex = 0; elementIndex < array.length; elementIndex += 1 ) {
          var element = array[ elementIndex ];
          var actualValue = element.getAttribute( actualValueAttributeName );
          if ( actualValue != null ) {
            element[ attributeName ] = actualValue;
          }

          if ( additionalProcessor != null ) {
            additionalProcessor( element );
          }
        }
      }

      function detectFraming() {
        if ( top != self ) {
          document.getElementById( "framingWarning" ).style.display = "block";
        } else {
          replaceAttributeValuesWithActualOnes( document.links, "href", "acme:href" );

          replaceAttributeValuesWithActualOnes( document.forms, "action", "acme:action", function ( form ) {
            replaceAttributeValuesWithActualOnes( form.elements, "disabled", "acme:disabled" );
          });
        }
      }
      // -->
    </script>
  </head>
  <body onload="detectFraming()">
    <div id="framingWarning" style="display: none; border-style: solid; border-width: 4px; border-color: #F00; padding: 6px; background-color: #FFF; color: #F00;">
      <div>
        <b>SECURITY WARNING</b>: Acme App is displayed inside another page.
        To make sure your data is safe this page has been disabled.<br>
        <a href="framing-detection.html" target="_blank" style="color: #090">Continue working safely in a new tab/window</a>
      </div>
    </div>
    <p>
      Content. <a href="#" acme:href="javascript:window.alert( 'Action performed' );">Do something</a>
    </p>
    <form name="acmeForm" action="#" acme:action="real-action.html">
      <p>Name: <input type="text" name="name" value="" disabled="disabled" acme:disabled=""></p>
      <p><input type="submit" name="save" value="Save" disabled="disabled" acme:disabled=""></p>
    </form>
  </body>
</html>

Bene, puoi modificare il valore del contatore, ma questa è ovviamente una soluzione fragile. Puoi caricare i tuoi contenuti tramite AJAX dopo aver stabilito che il sito non si trova all'interno di un frame - inoltre non è un'ottima soluzione, ma si spera che eviti di attivare l'evento on onunload (suppongo).

Modifica: un'altra idea. Se rilevi di essere in un frame, chiedi all'utente di disabilitare javascript, prima di fare clic su un link che ti porta all'URL desiderato (passando una stringa di query che fa sapere alla tua pagina di dire all'utente che possono riattivare javascript una volta che hanno ci sono).

Modifica 2: diventa nucleare: se rilevi di essere in una cornice, basta eliminare il contenuto del corpo del documento e stampare qualche brutto messaggio.

Modifica 3: puoi enumerare il documento principale e impostare tutte le funzioni su null (anche quelle anonime)?

Se aggiungi un avviso subito dopo il codice buster, l'avviso interromperà il thread javascript e consentirà il caricamento della pagina. Questo è ciò che StackOverflow fa, e viene espulso dai miei iframe, anche quando utilizzo il busting del frame busting. Ha funzionato anche con la mia semplice pagina di test. Questo è stato testato solo in Firefox 3.5 e IE7 su Windows.

Codice:

<script type="text/javascript">
if (top != self){
  top.location.replace(self.location.href);
  alert("for security reasons bla bla bla");
}
</script>

Penso che tu fossi quasi arrivato. Hai provato:

window.parent.onbeforeunload = null;
window.parent.location.replace(self.location.href);

o, in alternativa:

window.parent.prevent_bust = 0;

Nota: in realtà non l'ho provato.

Che ne dici di chiamare ripetutamente anche il buster? Questo creerà una condizione di gara, ma si potrebbe sperare che il buster esca in cima:

(function() {
    if(top !== self) {
        top.location.href = self.location.href;
        setTimeout(arguments.callee, 0);
    }
})();

Se guardi i valori restituiti da setInterval()quelli di solito sono cifre singole, quindi di solito puoi disabilitare tutti questi interrupt con una singola riga di codice:

for (var j = 0 ; j < 256 ; ++j) clearInterval(j)

Potrei aver appena ottenuto un modo per sballare il frame buster buster javascript. Usando getElementsByName nella mia funzione JavaScript, ho impostato un ciclo tra il frame buster e l'effettivo script buster frame buster. controlla questo post. http://www.phcityonweb.com/frame-buster-buster-buster-2426

setInterval e setTimeout creano un intervallo di incremento automatico. Ogni volta che viene chiamato setTimeout o setInterval, questo numero aumenta di uno, quindi se si chiama setTimeout, si otterrà il valore corrente più alto.

   var currentInterval = 10000;
   currentInterval += setTimeout( gotoHREF, 100 );
   for( var i = 0; i < currentInterval; i++ ) top.clearInterval( i );
   // Include setTimeout to avoid recursive functions.
   for( i = 0; i < currentInterval; i++ )     top.clearTimeout( i );

   function gotoHREF(){
           top.location.href = "http://your.url.here";
   }

Poiché è quasi inaudito che ci siano 10000 setIntervals e setTimeouts simultanei funzionanti e poiché setTimeout restituisce "ultimo intervallo o timeout creato + 1", e poiché top.clearInterval è ancora accessibile, questo sconfiggerà gli attacchi black hat al frame siti Web descritti sopra.

Usa htaccess per evitare set di frame high-jacking, iframe e qualsiasi contenuto come le immagini.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://www\.yoursite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule ^(.*)$ /copyrights.html [L]

Questo mostrerà una pagina di copyright invece del previsto.