Detaillierte Erklärung der JS-Homologiestrategie und CSRF

Überblick

In diesem Artikel geht es vor allem um drei Schlagworte:

• Same-Origin-Policy (SOP)
• Cross-Site-Request-Forgery (CSRF)
• Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS)

Same-Origin-Policy (SOP)

Homolog

Lassen Sie mich zunächst erklären, was derselbe Ursprung bedeutet: Protokoll, Domänenname und Port sind alle gleich, also derselbe Ursprung.

Limit

Der Grund für die domänenübergreifenden Probleme sind die verschiedenen Einschränkungen von SOP. Aber was genau ist eingeschränkt?

Wenn Sie sagen, dass SOP „Beschränkung des Erwerbs von Ressourcen nicht gleichen Ursprungs“ bedeutet, ist das falsch. Das einfachste Beispiel ist, dass Cross-Domain beim Verweisen auf Ressourcen wie Bilder, CSS-, JS-Dateien usw. zulässig ist.

Wenn Sie sagen, dass SOP „Verbot domänenübergreifender Anforderungen“ bedeutet, ist dies ebenfalls falsch. Tatsächlich verbietet SOP keine domänenübergreifenden Anforderungen, sondern fängt die Antwort auf die Anforderung nach der Anforderung ab. Dies führt dazu, dass die später erwähnte CSRF

Tatsächlich handelt es sich bei SOP nicht um eine einheitliche Definition, sondern es gibt in verschiedenen Situationen unterschiedliche Interpretationen:

• Benannte Bereiche für Cookies, DOM und JavaScript begrenzen
• Beschränken Sie Inhaltsvorgänge auf Iframes, Bilder und andere Ressourcen
• Die Begrenzung von Ajax-Anfragen oder genauer gesagt die Begrenzung der Ausführung von Ajax-Antwortergebnissen ist im Wesentlichen die gleiche wie die vorherige

Hier sind drei Beispiele, die Ihnen in realen Anwendungen begegnen könnten:

• Verwenden Sie Ajax, um andere domänenübergreifende APIs anzufordern. Dies ist die häufigste Situation und der Albtraum von Front-End-Neulingen
• iframe kommuniziert mit der übergeordneten Seite, die Häufigkeit ist relativ gering und die Lösung ist leicht zu verstehen
• Beim Bearbeiten von domänenübergreifenden Bildern (z. B. von <img>) tritt dieses Problem beim Bearbeiten von Bildern auf der Leinwand auf.

Wenn keine SOP vorhanden ist:

• Wenn Sie mehrere Tabs in einem Browser öffnen, werden Ihre Daten weitergegeben.
• Wenn Sie zum Öffnen einer Bankwebsite ein Iframe verwenden, können Sie den Inhalt der Website nach Belieben lesen und den vom Benutzer eingegebenen Inhalt abrufen
• Aggressiveres CSRF

Domänenübergreifendes Umgehen

SOP bringt Sicherheit, bringt aber auch gewisse Probleme mit sich, da manchmal domänenübergreifende Anforderungen bestehen. Aus Platzgründen und aufgrund der Vielzahl einschlägiger Artikel im Internet werde ich hier nicht näher auf die Lösung domänenübergreifender Probleme eingehen, sondern nur einige Stichworte nennen:

Für Ajax

• Verwenden von jsONP
• Backend-CORS-Konfiguration
• Backend-Reverseproxy

Für iframe

• Verwenden Sie location.hash oder window.name, um Informationen zu kommunizieren
• Verwenden von postMessage

Cross-Site-Request-Forgery (CSRF)

Kurzbeschreibung

CSRF (Cross-Site Request Forgery) ist eine gängige Angriffsmethode. Dies bedeutet, dass nach der normalen Anmeldung auf Website A das Cookie normal gespeichert wird. Andere Websites B rufen die Schnittstelle von Website A auf irgendeine Weise auf, um zu funktionieren, und Schnittstelle A holt bei Anforderung automatisch das Cookie.

Wie oben erwähnt, kann SOP Ressourcen über HTML-Tags laden und SOP blockiert keine Schnittstellenanforderungen, sondern fängt Anforderungsergebnisse ab. CSRF nutzt diese beiden Vorteile.

Daher kann SOP nicht als Methode zur Vorbeugung von CSRF verwendet werden.

Bei GET-Anfragen können Sie es direkt in <img> einfügen, um die domänenübergreifende Schnittstelle anzufordern, ohne dass es jemand bemerkt.

Für POST-Anfragen verwenden viele Beispiele die Formularübermittlung:

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
  <input type="hidden" name="acct" value="MARIA" />
  <input Typ="versteckt" Name="Betrag" Wert="100000" />
  <input type="submit" value="Meine Bilder ansehen" />
</form>

Letztendlich liefern diese beiden Methoden keine domänenübergreifenden Berichte, da die Anforderung über HTML gesteuert wird und Sie die Ergebnisse nicht direkt über JS bearbeiten können.

SOP und Ajax

Bei Ajax-Anfragen können Sie nach dem Abrufen der Daten beliebige JS-Operationen ausführen. Obwohl zu diesem Zeitpunkt die Same-Origin-Policy die Antwort verhindert, wird die Anfrage dennoch gestellt. Weil die Antwortabfangung vom Browser und nicht vom Backend-Programm durchgeführt wird. Tatsächlich wurde Ihre Anfrage an den Server gesendet und das Ergebnis zurückgegeben. Aus Sicherheitsgründen lässt der Browser jedoch keine weiteren JS-Vorgänge zu und meldet daher die bekannte Meldung „Durch CORS-Richtlinie blockiert: Auf der angeforderten Ressource ist kein Header „Access-Control-Allow-Origin“ vorhanden.“

Deshalb möchte ich noch einmal betonen, dass die Same-Origin-Policy nicht als Methode zur Verhinderung von CSRF verwendet werden kann.

Es gibt jedoch Ausnahmen, die CSRF verhindern können. Der Browser lässt nicht zu, dass alle Anfragen erfolgreich gesendet werden. Die obige Situation ist auf einfache Anfragen beschränkt. Das relevante Wissen wird im folgenden CORS-Abschnitt ausführlich erläutert.

CSRF-Gegenmaßnahmen

SOP wird von CSRF ausgenutzt, ist es also wirklich nutzlos?

NEIN! Erinnern Sie sich, dass SOP den Benennungsbereich von Cookies begrenzt? Obwohl die Anfrage automatisch Cookies mitbringt, kann der Angreifer den Cookie-Inhalt selbst trotzdem nicht abrufen.

Die Idee im Umgang mit CSRF besteht darin, ein Token in ein Cookie zu schreiben und das Token dann bei einer Anforderung in die Abfrage, den Textkörper oder den Header einzuschließen. Die Anfrage kommt beim Server an und überprüft das Token. Wenn es korrekt ist, muss es sich um eine Anfrage handeln, die von der Domäne gesendet wurde, die das Cookie sehen kann. CSRF kann dies nicht. (Diese Methode wird verwendet, um Front-End und Back-End zu trennen, und das Back-End-Rendering kann direkt in das DOM geschrieben werden.)

Der Beispielcode lautet wie folgt:

var csrftoken = Cookies.get('csrfToken')

Funktion csrfSafeMethod(Methode) {
  // diese HTTP-Methoden erfordern keinen CSRF-Schutz
  return /^(GET|HEAD|OPTIONS|TRACE)$/.test(Methode)
}
$.ajaxSetup({
  beforeSend: Funktion(xhr, Einstellungen) {
    wenn (!csrfSafeMethod(settings.type) && !this.crossDomain) {
      xhr.setRequestHeader('x-csrf-token', csrftoken)
    }
  },
})

Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS)

Cross-Domain ist eine Browserbeschränkung, aber wenn der Server eine CORS-bezogene Konfiguration festlegt, wird Access-Control-Allow-Origin zum Informationsheader hinzugefügt, der an den Server zurückgegeben wird. Wenn der Browser erkennt, dass der Wert dieses Felds mit dem aktuellen Ursprung übereinstimmt, wird die Cross-Domain-Beschränkung aufgehoben.

HTTP/1.1 200 OK

Datum: So, 24. April 2016 12:43:39 GMT

Server: Apache

Zugriffskontrolle-Origin zulassen: http://www.acceptmeplease.com

Keep-Alive: Zeitüberschreitung = 2, max = 100

Verbindung: Keep-Alive

Inhaltstyp: application/xml

Inhaltslänge: 423

Für CORS gibt es zwei Arten von Anfragen.

Einfache Anfrage

• Die Anforderungsmethode ist GET, POST oder HEAD.
• Content-Type ist auf application/x-www-form-urlencoded, multipart/form-data oder text/plain eingestellt.

Alle Anfragen, die die beiden oben genannten Bedingungen erfüllen, sind einfache CORS-Anfragen. Einfache Anfragen werden direkt an den Server gesendet, was zu CSRF führen kann.

Preflight-Anfrage

Für Anfragen, die die Anforderungen einer einfachen Anfrage nicht erfüllen, muss zuerst eine Preflight-Anfrage gesendet werden. Der Browser sendet eine Anfrage mit der OPTION-Methode, um den Server zu fragen, ob die aktuelle Quelle das CORS-Ziel erfüllt, bevor er die eigentliche Anfrage stellt. Die formelle Anfrage wird erst gesendet, nachdem die Überprüfung bestanden wurde.

Beispielsweise ist eine POST-Anfrage, die application/json zum Übergeben von Parametern verwendet, keine einfache Anfrage und wird während der Vorprüfung abgefangen.

Wenn beispielsweise eine PUT-Methodenanforderung verwendet wird, wird auch eine Vorabprüfungsanforderung gesendet.

Die oben erwähnte Ausnahme, die CSRF verhindern kann, bezieht sich auf Vorabprüfungsanforderungen. Selbst wenn die Vorabprüfung der domänenübergreifenden Anforderung erfolgreich ist, kann die eigentliche Anforderung nicht gesendet werden, was sicherstellt, dass CSRF nicht erfolgreich sein kann.

CORS und Cookies

Im Gegensatz zur gleichen Domäne senden domänenübergreifende CORS-Anfragen standardmäßig keine Cookies und HTTP-Authentifizierungsinformationen. Sowohl das Frontend als auch das Backend müssen die Anfrage so einrichten, dass Cookies in die Konfiguration einbezogen werden.

Aus diesem Grund muss axios bei CORS-Anfragen withCredentials: true festlegen.

Unten finden Sie die CORS-Einstellung des node.js-Backend-Koa-Frameworks:

/**
 * CORS-Middleware
 *
 * @param {Objekt} [Optionen]
 * - {String|Function(ctx)} Herkunft „Access-Control-Allow-Origin“, Standard ist Anforderungs-Origin-Header
 * - {String|Array} allowMethods `Access-Control-Allow-Methods`, Standard ist 'GET,HEAD,PUT,POST,DELETE,PATCH'
 * - {String|Array} ExposeHeaders `Access-Control-Expose-Headers`
 * - {String|Array} allowHeaders `Access-Control-Allow-Headers`
 * - {String|Number} maxAge `Access-Control-Max-Age` in Sekunden
 * - {Boolean} Anmeldeinformationen `Access-Control-Allow-Credentials`
 * - {Boolean} keepHeadersOnError Fügt festgelegte Header zu „err.header“ hinzu, wenn ein Fehler auftritt.
 * @return {Funktion} CORS-Middleware
 * @api öffentlich
 */

Oben finden Sie eine ausführliche Erläuterung der JS Same-Origin Policy und CSRF. Weitere Informationen zur JS Same-Origin Policy und CSRF finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!