Javascript http to https redirect - quanto vulnerabili / quanto sicuri? [duplicare]

2

Se avessi un sito web link reindirizzato a link tramite javascript (con un HTTP/1.1 403 Forbidden ), quali sono i vettori di attacco che potrei essere anche vulnerabile?

Perché questa non è una buona pratica? (e il modo preferito è fare un 301 dal lato server)

  1. ok SEO mentre un 301 è preferito per i bot di ricerca.
  2. disabilita lo script nel browser, sei bloccato

qualcos'altro?

Per l'onething, secondo me, una fissazione della sessione tramite MITM non è possibile almeno perché tutta la risposta grezza mi dà è come sotto. Non ci sono cookie, qualunque cosa.

<html>
<head><title>hussh...</title></head>
<script language="JavaScript">
function redrToHttps()
{
 var httpURL= window.location.hostname + window.location.pathname + window.location.search;
 var httpsURL= "https://" + httpURL;
 window.location = httpsURL;
}
 redrToHttps();
</script>
<body>

Non so perché un sacco di tutorial su internet ti suggeriscono di farlo tramite javascript, mentre un permanente di 301 è una scelta perfetta. AFAIK, non sono riuscito a trovare un vettore di attacco in questa forma di reindirizzamento tramite javascript con intestazione 403.

Mi manca qualcosa? Ci sono dei vettori di attacco di cui potrei essere vittima in futuro? Perché non è questo il modo consigliato?

Modifica

Forse mi sono dimenticato di dire perché ho postato questa domanda. Ho già alzato una bandiera per usare HSTS, mancava nel sito web in questione. La mia preoccupazione è che le persone che hanno sviluppato questa applicazione hanno seguito il primo link in google (a quei tempi, quando si sono sviluppati) per rendere questo http a https il reindirizzamento tramite javascript. Onestamente, questa è la prima volta che ho visto un http per https reindirizzare per tutte le pagine dell'applicazione tramite javascript. Non devo dirti quanto sia pessimo, e stupido il javascript https reindirizza i suoni anche all'inizio. Ma ho guardato la risposta grezza, c'era un 403 che va bene (hey, sei proibito), anche se non è il modo migliore di farlo.

Il sito non serve mai alcuna informazione su http. Utilizza sempre il javascript per fare il reindirizzamento effettuare una nuova richiesta. Peccato. Capisco. Potrebbero essere le tue risposte / pensieri su quanto questo potrebbe essere suscettibile, vorrei aiutarmi a vendere perché questa è una pessima idea in termini di sicurezza.

Ho paura che questo non sia un possibile duplicato poiché nessuna domanda nella rete di stackexchange discute le implicazioni di sicurezza di un reindirizzamento http a https tramite javascript in specifico. Mantenendo le migliori pratiche a parte, apprezzerei le tue idee su quanto sia insicuro (e perché così) questo approccio .

Script lato client personalizzato che istruisce il browser per navigare verso una pagina diversa, e il browser che risponde a un 301 come in link presenta differenze fondamentali che credo . Lo sanno gli exploit dimostrati in questo caso?

Grazie.

Modifica 2: Qualcuno ha notato un 403? In IIS 6 se l'opzione era abilitata richiedeva HTTPS e se si tentava di accedere al sito tramite HTTP e se non si era configurato correttamente SSL, allora si otterrebbe una pagina di errore 403 non soddisfacente. La soluzione rapida per i vecchi tempi è quella di intercettare un server 403 nel server e restituire una pagina di errore personalizzata che conterrebbe un codice javascript come accennato nella domanda. Quel javascript richiederebbe quindi la versione HTTPS della pagina, che è una nuova richiesta del browser, e non un reindirizzamento di alcun tipo. Che è in realtà equivalente a una nuova richiesta https. Questo è cattivo, molto cattivo, scarsa attuazione. Ma la domanda ora è, tu chiedi una risorsa su http, che ti restituisce un 403 con qualche script java che aiuta a mettere https nell'url per te e quindi a lanciare una nuova richiesta https. Non un HTTPS indotto 301/301. Può essere la domanda che il titolo dice reindirizzare la parola, ma ora ho dei ripensamenti su questo termine improprio. Per mettere le cose in prospettiva ecco un post - link che descrive cosa sto dicendo Post molto vecchio davvero. Come si presenta una domanda doppia?

    
posta gmaran23 08.01.2014 - 18:05
fonte

1 risposta

1

Fare questo nel browser con JavaScript è insicuro e inefficiente.

Come hai già detto, se l'agente utente non esegue JavaScript, l'utente si troverà nella tua pagina Proibita 403. Se hai intenzione di restituire una risposta 403 a un utente, perché non restituire semplicemente un 301 e fare qualche uso della risposta? Questa è una brutta esperienza utente e risulterà in persone che colpiscono continuamente il tuo URL http per essere reindirizzati anziché https.

Da un punto di vista della sicurezza si sta aprendo l'utente agli attacchi di un MiTM. Se l'utente digita in site.com senza specificare un protocollo, il browser verrà impostato su HTTP e inoltrerà una richiesta al link per loro. Se il reindirizzamento viene eseguito in JavaScript, il browser non si ricorderà. Se il server risponde con un reindirizzamento permanente 301 a link , il browser memorizzerà nella cache questa risposta. La prossima volta che l'utente digiterà in site.com il browser visiterà il link link anziché come prima. Ciò aiuta a mitigare varie forme di attacchi SSL stripping ma non è una soluzione perfetta. Tuttavia, è leggermente più sicuro.

Ciò che potresti fare è emettere una norma HSTS per il tuo dominio. Ho approfondito alcuni dettagli su cosa sia HSTS sul mio blog intitolato " HSTS - Il collegamento mancante nella sicurezza dei livelli di trasporto ". In poche parole, HSTS ti consente di dire a un browser di sempre di utilizzare https senza alcun obbligo di reindirizzamento. È ancora necessario mantenere i reindirizzamenti per gli agenti utente non conformi, ma è un altro passo nella giusta direzione.

    
risposta data 08.01.2014 - 19:02
fonte