it-swarm.com.de

Warum Chrome blockiert Ajax lokal?

Dup konnte nicht gefunden werden, also lass es mich wissen, wenn es eines gibt

Ich versuche, eine statische einseitige Website zu erstellen (um sie auf Neocities zu hosten). Ich benutze dafür die Funktion load() von jquery. Es funktioniert gut in Firefox (und Edge), aber nicht in Chrome.

Hier ist 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>

und hier ist partial_page.html:

<h1>This is partial page</h1>

Fehlermeldung von Chrome:

Cross Origin-Anforderungen werden nur für Protokollschemata unterstützt: http, data, chrome, chrome-extension, https.

Screenshot (Chrome links, Firefox rechts):

(enter image description here

Fragen:

  1. Löst Chrome) eine Art von Sicherheitslücke, indem es mir nicht erlaubt, das zu tun, was ich versuche, was auf keine andere Weise möglich gewesen wäre, als mich vollständig daran zu hindern, das zu tun, was ich bin versuchen zu tun?
  2. Wenn jemand versuchen würde, eine Sicherheitsanfälligkeit auszunutzen, die Chrome versucht, durch Blockieren meiner Anfrage zu beheben), wie würden sie vorgehen?
  3. Bedeutet das, dass Firefox (und Edge) (mehr) anfällig für XSS oder CORS (oder etwas anderes) sind?
1
wha7ever

CORS wird über HTTP geschichtet ​​also macht es irgendwie keinen Sinn, sich mit CORS außer httphttpschrome und - zu befassen chrome-extension Da die letzten 3 wahrscheinlich (mir fehlt hier das Dokument) auf denselben Regeln wie HTTP beruhen.

Jedes andere Protokollverhalten für CORS ist derzeit nicht definiert. Also Chrome blockiert es.

So beantworten Sie jede Frage einzeln:

1) Nein, sie denken nur, dass, da das CORS nicht für ein anderes Protokoll definiert ist, es am sichersten ist, mit dem Fehler "nicht implementiert" abzustürzen.

2) Da 1) die Antwort Nein lautet, ist diese Frage nicht zutreffend. Aber wenn Chrome die Anfrage loslassen, dann liegt es am unbekannten Protokoll, CORS richtig zu behandeln, was wahrscheinlich nicht richtig gemacht wird

3) Der Unterschied zwischen Firefox und Chrome besteht darin, dass Firefox zuerst prüft, ob die Ursprünge des Anforderungsdokuments und der angeforderten Ressource identisch sind (und wenn ja, lässt es es ansonsten durch - CORS-Prozess folgen ) while Chrome Folgen Sie immer dem CORS-Prozess, bevor Sie die Origin-Übereinstimmung überprüfen.

-Ich weiß nicht, welches Verhalten am besten der Fetch-Spezifikation folgt. - Es scheint, dass beide in Ordnung sind, da ein Teil der Spezifikation sagt

"file" "ftp"

So unglücklich es auch ist, Datei- und FTP-URLs bleiben vorerst als Übung für den Leser.

Geben Sie im Zweifelsfall einen Netzwerkfehler zurück.

Der einzige Schaden, den ich sehen konnte, war, dass Firefox ein Skript vertrauliche Informationen von file:/// Auf Ihrem Bildschirm anzeigen ließ, die ein Schulterspion greifen konnte. Es hat dann nichts mit CORS zu tun.

1
Xenos

Löst Chrome) eine Art von Sicherheitslücke, indem es mir nicht erlaubt, das zu tun, was ich versuche, was auf keine andere Weise möglich gewesen wäre, als mich vollständig daran zu hindern, das zu tun, was ich bin versuchen zu tun?

Ja tut es.

Wenn Webseiten von file:// durften Anfragen an andere Seiten unter file://, sie könnten jede Datei auf Ihrem Computer lesen, einschließlich vertraulicher Dateien wie SSH-Schlüssel, Browser-Cookies und gespeicherter Passwörter sowie persönlicher Dokumente auf bekannten Pfaden.

Wenn Sie dies ändern, kann das Öffnen einer HTML-Datei auf Ihrem Computer - einschließlich gespeicherter Webseiten sowie von HTML-Dokumenten, die als Dokumentations- oder Readme-Dateien verteilt werden - möglicherweise vertrauliche Daten von Ihrem Computer herausfiltern. Browserhersteller haben festgestellt, dass dies ein inakzeptables Risiko ist.

1