¿Debería preocuparme que Wayback Machine intente cargar scripts desde fuentes no autenticadas?

2

Utilizo regularmente Wayback Machine para ayudar a encontrar versiones archivadas de páginas web que se han eliminado o que no están disponibles de otra manera.

Al usar el sitio, noté una advertencia peculiar en la barra de direcciones de Google Chrome.

Firefoxmuestraunaadvertenciasimilarparascriptsinseguros.

¿Debería preocuparme que Wayback Machine esté intentando cargar scripts de fuentes no autenticadas?

( Para el registro, ni Microsoft Edge ni Internet Explorer mostraron advertencias )

    
pregunta Steven M. Vascellaro 08.07.2017 - 18:49
fuente

4 respuestas

1

No, no a menos que esté utilizando un navegador que no bloquee las fuentes no autenticadas (es decir, HTTP sin formato) al cargar una fuente autenticada (es decir, HTTPS). La mayoría de los navegadores modernos harán esto.

El error en este caso es:

  

Contenido mixto: la página en ' enlace ' se cargó sobre   HTTPS, pero solicitó un punto final XMLHttpRequest inseguro   ' enlace ...

Como el navegador bloqueó la solicitud, no puede ser interceptado por un intruso o por Man-In-The-Middle en la conexión, por lo tanto, estás a salvo.

Es probable que haya un error de configuración en la Máquina Wayback que envía la solicitud a través de HTTP en lugar de HTTPS.

    
respondido por el SilverlightFox 09.07.2017 - 00:16
fuente
1

Cuando vea estas advertencias, puede usar la página de la herramienta de inspección del navegador web (ctrl-shift-i en Chrome) para analizar el problema.

En Google Chrome, seleccione la pestaña Seguridad en la ventana de Inspección, luego vuelva a cargar, luego vaya a la página de contenido mixto (pestaña Red con un filtro de contenido mixto: algo ", como mixed-content:all ).

La advertencia en la Consola (en la ventana de inspección) es:

  

raven.min.js: sourcemap: 2 Contenido mixto: La página en   ' enlace ' se cargó a través de HTTPS, pero solicitó un   punto extremo inseguro de XMLHttpRequest   ' enlace '. Este contenido también debe servirse a través de HTTPS.

Cuando permito ese contenido activo inseguro, veo dos solicitudes de este tipo, ambas POST HTTP a http://wwwb-sentry.us.archive.org/api/3/store/ , ambas con parámetros de URL y algunos datos POST.

Los datos POST de la primera solicitud son:

  

{"proyecto": "3", "logger": "javascript", "platform": "javascript", "request": {"headers": {"User-Agent": "Mozilla / 5.0   (sniped) "}," url ":" enlace "}," excepción ": {" valores ": [{" tipo " : "ReferenceError", "valor": " archive_analytics   no es   definido "," stacktrace ": {" frames ": [{" filename ":" enlace "," lineno " : 21, "colno": 36, "function": "?", "In_app": true}]}}]}, "culpable": " enlace "," extra ": {" session: duration ": 17}," event_id ":" (snip) "}

Esto parece causado por el hecho de que la página https://web.archive.org/ tiene esa inclusión de script:

<script src="//archive.org/includes/analytics.js?v=30792cb" type="text/javascript"></script>

La falta de esquema de URL en la URL "//archive.org/includes/analytics.js?v=30792cb" significa: use el esquema que se usó para cargar la página web, aquí HTTPS. Entonces, la URL es realmente: enlace que coincide con ||archive.org^*/analytics.js en Lista negra de fácil manejo que pueden ser utilizadas por muchas extensiones de navegador disponibles en muchos navegadores (AdBlock, ABP, UBlock Origin ...).

De hecho, la desactivación de este filtro de privacidad suprimió esa primera solicitud. Todavía hay otra petición:

  

raven.min.js: 2 Contenido mixto: la página en ' enlace '   se cargó a través de HTTPS, pero solicitó un XMLHttpRequest inseguro   punto final   ' enlace '.   Este contenido también debe servirse a través de HTTPS.

con datos POST:

  

{"proyecto": "3", "logger": "javascript", "platform": "javascript", "request": {"headers": {"User-Agent": "Mozilla / 5.0   (sniped) "}," url ":" enlace "}," excepción ": {" valores ": [{" tipo " : "Error", "valor": " solo   una instancia de babel-polyfill es   permitido "," stacktrace ": {" frames ": [{" filename ":" enlace ", "lineno": 1, "colno": 1, "function": "?", "in_app": true}, {"filename": " enlace "," lineno ": 1," colno ": 418, "function": "window.webpackJsonp", "in_app": true}, {"filename": " enlace ", "lineno": 1, "colno": 101, "function": "n", "in_app": true}, {"filename": " enlace "," lineno ": 1," colno ": 1251204, "function": "Object.", "in_app": true}, {"filename": " enlace ", "lineno": 1, "colno": 101, "function": "n", "in_app": true}, {"filename": " enlace ", "lineno": 1, "colno": 248121, "function": "Object.", "in_app": true}, {"filename": " enlace "," lineno ": 1," colno ": 247664 , "function": "Object.", "in_app": true}]}}]}, "culpable": " enlace ", "extra": {"session: duration": 393}, "event_id": "(snip)"}

    
respondido por el curiousguy 09.07.2017 - 00:38
fuente
0

No asumiría que estás "bien" porque usas un navegador u otro ... hay muchas variables en juego aquí (no pretendía hacer ningún juego de palabras).

No estoy seguro de si debería estar preocupado, pero esta es una pregunta muy interesante para mí. Es bueno saber que Firefox advierte sobre esto, a diferencia de los otros navegadores mencionados anteriormente, y hay otros pasos que puede tomar para mitigar este tipo de cosas ...

Puede protegerse no solo de esta vulnerabilidad potencial en particular, sino de muchas otras similares (en la actualidad, los navegadores son a menudo las mejores pasarelas para que el malware encuentre su camino en las computadoras personales) ejecutando un par de extensiones diseñadas para protegerlo de estos tipos de ataques, como NoScript (debe tenerlo en mi opinión), y HTTPS-Everywhere .

NoScript está diseñado específicamente para evitar que la JS maliciosa se ejecute antes de que cause el daño, y HTTPS Everywhere intenta, bueno ... usar HTTPS, si está disponible, en todas partes. Esto puede ayudar a prevenir la inyección de scripts maliciosos por parte de un atacante MITM. Recomiendo altamente estos complementos.

    
respondido por el Chev_603 09.07.2017 - 01:02
fuente
-3

En general, creo que deberías estar bien siempre y cuando te quedes con Chrome y Firefox, ya que ambos bloquean los scripts inseguros.

    
respondido por el sxcurity 08.07.2017 - 23:21
fuente

Lea otras preguntas en las etiquetas