¿Por qué Chrome bloquea ajax localmente?

0

No se pudo encontrar un dup, así que avísame si hay uno

Estoy intentando crear un sitio web estático de una página (para alojarlo en neocities). Yo uso la función load() de jquery para eso. Funciona bien en Firefox (y Edge) pero no en Chrome.

Aquí está index.html :

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
</head>
<body>
    <div id="partial-page-load-section"></div>
    <script src="jquery-1.12.4.min.js"></script>
    <script>
        $("#partial-page-load-section").load("partial_page.html");
    </script>
</body>
</html>

y aquí está partial_page.html :

<h1>This is partial page</h1>

Mensaje de error de Chrome:

  

Las solicitudes de origen cruzado solo son compatibles con esquemas de protocolo: http, data, chrome, chrome-extension, https.

Captura de pantalla (Chrome uno a la izquierda, Firefox a la derecha):

Preguntas:

  1. ¿Chrome resuelve algún tipo de vulnerabilidad al no permitirme hacer lo que estoy tratando de hacer que no hubiera sido posible resolver de otra manera que no me impidiera hacer lo que estoy tratando de hacer?
  2. Si alguien intentara explotar la vulnerabilidad que Chrome intenta solucionar mediante el bloqueo de mi solicitud, ¿cómo lo harían?
  3. ¿Eso significa que Firefox (y Edge) son (más) vulnerables a XSS o CORS (o algo más)?
pregunta Alex L 24.07.2018 - 17:42
fuente

2 respuestas

1

CORS está en capas a través de HTTP , por lo que no tiene sentido tratar con CORS además de http https chrome y chrome-extension ya que los últimos 3 probablemente (me falta el documento aquí) confía en las mismas reglas que HTTP.

Cualquier otro comportamiento de protocolo para CORS no está definido por ahora. Así que Chrome lo bloquea.

Para responder a cada pregunta individualmente:

1) No, solo consideran que, dado que CORS no está definido para otro protocolo, lo más seguro es bloquearse con un error que diga "no implementado"

2) Como 1) la respuesta es No, esta pregunta no es aplicable. Pero si Chrome deja pasar la solicitud, entonces depende del protocolo desconocido manejar adecuadamente CORS, lo que probablemente no se hará correctamente

3) La diferencia entre Firefox y Chrome es que Firefox primero comprueba si los orígenes del documento del solicitante y el recurso solicitado son los mismos (y si es así, lo dejaron pasar, de lo contrario, sigue el proceso CORS ) mientras que Chrome siempre sigue el proceso CORS antes de verificar la coincidencia de origen.

-No sé qué comportamiento sigue mejor la Especificación de recuperación . Parece que ambos están bien. ya que parte de la especificación dice

  

"archivo"   "ftp"

     

Por ahora, por desgracia, las URL de archivos y ftp se dejan como un ejercicio para el lector.

     

En caso de duda, devuelva un error de red.

El único daño que pude ver es que Firefox permitiría que una secuencia de comandos muestre información confidencial de file:/// en tu pantalla, que un aspirador de hombro podría agarrar. No está relacionado con CORS entonces.

    
respondido por el Xenos 24.07.2018 - 17:54
fuente
1
  

¿Chrome resuelve algún tipo de vulnerabilidad al no permitirme hacer lo que estoy tratando de hacer que no hubiera sido posible resolver de otra manera que no me impidiera hacer lo que estoy tratando de hacer?

Sí, lo hace.

Si las páginas web cargadas desde file:// pudieran realizar solicitudes a otras páginas bajo file:// , podrían leer cualquier archivo en su computadora , incluidos los archivos confidenciales como claves SSH, cookies del navegador y contraseñas guardadas, y documentos personales en rutas conocidas.

Cambiar esto significaría que la apertura de cualquier archivo HTML en su computadora, incluidas las páginas web guardadas, así como los documentos HTML distribuidos como documentación o archivos Léame, podría potencialmente filtrar datos confidenciales de su computadora. Los fabricantes de navegadores han determinado que este es un riesgo inaceptable.

    
respondido por el duskwuff 25.07.2018 - 05:05
fuente

Lea otras preguntas en las etiquetas