Come impedire al browser di rendere il contenuto malevolo se la richiesta o la risposta sono violate?

Question

Come impedire al browser di rendere il contenuto malevolo se la richiesta o la risposta sono violate?

#1 da (3 voti)

2

Al momento stiamo lavorando su correzioni di sicurezza OWASP e abbiamo identificato uno scenario di attacco per il quale stiamo cercando di capire una possibile soluzione:

L'utente raggiunge un HTTPRequest valido per la nostra applicazione. L'URL nel browser dell'utente è impostato sul nostro URL dell'applicazione, ad es. %codice%
Ciascuno di questi:
- A: l'attaccante intercetta la richiesta e la inoltra a un sito malevolo anziché alla nostra applicazione. L'URL nel browser dell'utente è impostato sull'URL dell'applicazione, ad es. https//www.abc.com/request ma il contenuto sarà quello del sito dannoso.
- B: l'applicazione elabora la richiesta e invia la risposta tramite Apache. Mentre la risposta è in rotta, un utente malintenzionato intercetta la risposta e sostituisce il contenuto dell'intera risposta con un sito o un messaggio dannoso come "You Are Hacked !!"
In entrambi i casi, la risposta viene visualizzata nel browser dell'utente, con l'URL che punta ancora a https://www.abc.com/request nel browser, ma il contenuto è malevolo. Questo fa credere all'utente che sia ancora nella nostra applicazione.

Potremmo replicare questo scenario attraverso il nostro strumento proxy. Essere https, può essere che l'hacker non può decifrare la risposta, ma può certamente modificare il contenuto della risposta o reindirizzare a qualche sito dannoso. C'è un modo per identificare e impedire il rendering di tali risposte nel browser tramite Apache o intestazioni HTTP personalizzate?

Cosa succede se nello scenario (2A), l'utente viene instradato da un sito HTTPS valido a un sito HTTP dannoso?

http tls man-in-the-middle defense

posta user36009 10.02.2015 - 12:08

fonte

1 risposta

Leggi altre domande sui tag http tls man-in-the-middle defense

Utilizzo dell'email anonima come email ufficiale Autenticazione tra due server interni

score 3 · Accepted Answer

Se la richiesta al tuo dominio è HTTPS (ad esempio https://example.com ) questo è effettivamente immune da un aggressore MITM (a parte i problemi del proxy aziendale). Se un utente malintenzionato reindirizzava example.com all'IP del proprio sito, il proprio sito non avrebbe un certificato attendibile installato per example.com in modo che l'utente riceverebbe gli avvisi del browser e sarebbe strongmente scoraggiato dall'accettare il certificato e dalla navigazione nel sito .

L'unico modo per aggirare questo attacco è quello di ottenere una copia del certificato con la chiave privata, o in qualche modo avere il proprio certificato di fiducia per il dominio che sarebbe molto difficile da fare. E se riescono a farlo rompendo nel tuo server, allora vincono lo stesso. In conclusione, confida nella Infrastruttura a chiave pubblica di X.509 . Leggi lì per ulteriori informazioni su come funziona.