Esistono vulnerabilità quando si effettuano richieste HTTP tra domini durante una connessione SSL?

Question

Esistono vulnerabilità quando si effettuano richieste HTTP tra domini durante una connessione SSL?

#1 da (2 voti)

2

Recentemente ho iniziato a utilizzare il plug-in Validation SSL di Calomel per Firefox a testare la sicurezza SSL sui siti che visito. Durante la navigazione nella pagina di accesso di American Express, ho notato che Calomel segnala che la crittografia è "rotta e non protetta".

Ho quindi eseguito un analizzatore HTTP sulle richieste dalla pagina di accesso di Amex HTTPS e ho trovato quanto segue:

POST http://ocsp.verisign.com/
GET  http://ad.doubleclick.net/crossdomain.xml
POST http://evintl-ocsp.verisign.com/
POST http://evsecure-ocsp.verisign.com/

Queste 4 richieste sono, da quello che posso dire, la causa degli avvertimenti SSL che sto vedendo. Le richieste di Verisign sembrano controllare lo stato del certificato emesso e la richiesta interdominio per DoubleClick sta ottenendo le informazioni sui criteri interdominio.

Queste richieste mettono a rischio la connessione SSL essendo su HTTP? Ho notato che nessuno sta inviando alcun cookie AmEx.

Sta verificando lo stato del certificato tramite una sicurezza POST HTTP OCSP non sicura da eseguire durante una connessione SSL?

http tls ocsp

posta Mike G. 24.06.2013 - 21:25

fonte

1 risposta

Leggi altre domande sui tag http tls ocsp

Utilizzo di X-actual-recipient per deviare l'e-mail Oauth2 - nelle tradizionali applicazioni aziendali

score 2 · Accepted Answer

Questa domanda dipende interamente da quale contenuto viene caricato e da quale browser stai utilizzando. (Che sono curiosamente le informazioni che mancano da questo post)

Chrome per impostazione predefinita eviterà le vulnerabilità dei contenuti misti caricando le risorse su HTTPS, se possibile. Firefox introdurrà questa funzionalità di sicurezza a breve. IE non ha molte funzionalità di sicurezza moderne ed è particolarmente vulnerabile alle vulnerabilità dei Contenuti Misti.

Se si carica JavaScript da un'origine HTTP su una pagina HTTPS, l'intera pagina viene compromessa. Un utente malintenzionato potrebbe introdurre un codice JavaScript arbitrario e leggere qualsiasi contenuto all'interno di quella sessione (simile a XSS). Gli oggetti Flash con allowscriptaccess abilitato avranno anche accesso a qualsiasi contenuto all'interno di questa sessione HTTPS. Di norma, i CSS non sono un problema, tuttavia Internet Explorer ti consente di incorporare JavaScript all'interno dei CSS, che consentirebbe a un utente malintenzionato di leggere contenuti arbitrari all'interno della sessione.

Quindi per quanto riguarda le immagini e i video? Beh, potresti andare a qualcuno (i bambini lo fanno ancora bene?) O capovolgere le immagini capovolte , ma è meno preoccupante che leggere i numeri delle carte di credito o ottenere la password di un utente o leggere un cookie con il flag Secure impostato.

Negli URL sopra le richieste OCSP sono di solito in testo normale. Il dirottamento di un file crossdomain.xml non è un problema, specialmente quando il file in questione ha già la regola meno sicura- impostabile:

<allow-access-from secure="false" domain="*"/>