Rischi di utilizzare AJAX su un dominio HTTPS da una pagina pubblicata su HTTP

Question

Rischi di utilizzare AJAX su un dominio HTTPS da una pagina pubblicata su HTTP

#1 da (0 voti)

2

Oggi stavo lavorando al server di staging di un'azienda quando ho notato che stanno ospitando il sottodominio dell'API su una connessione HTTPS mentre stanno servendo il loro dashboard rivolto all'utente su una connessione HTTP. Questo rappresenta un rischio per la sicurezza? So che l'HTTP non fornisce alcuna protezione ai dati trasmessi attraverso la rete, ma non so se ciò influirà su tutte le chiamate HTTPS effettuate dopo che la pagina è stata caricata nel browser di un utente.

Inoltre, alcune note: il dashboard dell'azienda è un'applicazione a singola pagina. Ho ispezionato il traffico di rete in corso quando carichi la pagina e, per quanto posso dire, vengono inviate tutte le richieste AJAX su HTTPS, incluse le richieste di accesso.

Se questo è un rischio per la sicurezza, puoi indicarmi alcuni documenti ufficiali che posso usare per convincere la società che hanno un problema?

http tls

posta Copernicus 30.04.2017 - 04:47

fonte

1 risposta

Leggi altre domande sui tag http tls

Custom keystore / certificato per contenere chiavi asimmetriche (RSA) Ritardo minimo di comunicazione anonima ad alta latenza?

score 0 · Accepted Answer

Hai un dashboard HTTP che carica il contenuto dell'API su HTTPS. Ciò implica che se un aggressore man-in-the-middle osserva qualcuno che richiede il dashboard, può modificare arbitrariamente la risposta e iniettare il proprio contenuto, ad es. in un modo che rivelerà tutte le richieste API successive dalla pagina dashboard modificata all'utente malintenzionato.

Un utente malintenzionato potrebbe ottenere questo risultato iniettando il codice JS che con ogni richiesta API invia anche la risposta a un dominio controllato da un utente malintenzionato o eventualmente riscrivendo le richieste all'API HTTPS su HTTP semplice.

I don't know if this will affect any HTTPS calls that are made after the page has loaded in a user's browser.

Dopo il sito HTTP è stato caricato e solo a condizione che l'utente malintenzionato non possa osservare eventuali richieste HTTP semplici in seguito (ovvero che l'utente non ricarica mai il sito), l'utente malintenzionato non avrebbe la possibilità di origliare su eventuali richieste HTTPS successive all'API o modificare qualsiasi contenuto.

(Ma potrebbero indurre l'utente a ricaricare il dashboard HTTP bloccando le richieste HTTPS - facendo in modo che l'utente pensi che ci sia un bug che potrebbe essere corretto ricaricando il sito.)