it-swarm.com.de

Was würde passieren, wenn eine zufällige Webseite eine Ajax-Anfrage für http://127.0.0.1/private.txt stellen würde?

Ich verwende einen Nur-Localhost-Webserver (den in PHP integrierten) für alle meine Admin-Panels und so weiter auf meinem Computer. Ich mache mir Sorgen, dass, wenn eine zufällige Webseite ein JavaScript-Snippet enthält, das einen Ajax-Aufruf an http://127.0.0.1/private.txt ausführt, und ich diese Webseite besuche, mein Browser dadurch beschädigt wird (Firefox) ruft alle Daten ab, die von dieser URL zurückgegeben werden, und kann sie verwenden, um sie beispielsweise in einer anderen Ajax-Anfrage an den eigenen Server zurückzusenden.

Nehmen wir an, dass http://127.0.0.1/private.txt mein gesamtes Tagebuch seit 1958 zurückgibt. Oder etwas ähnlich Sensibles. Ich möchte definitiv nicht, dass es mit etwas anderem als meinem Firefox-Browser interagiert, aber soweit ich das beurteilen kann, könnte dies ein massives Datenschutz-/Sicherheitsproblem sein. Ich hoffe, ich irre mich in meiner Annahme, dass diese Anfrage erlaubt wäre. Ich hoffe, dass es eine Art "domänenübergreifende Richtlinie" gibt, die es blockiert oder so. Zumal es von 127.0.0.1 ist, was eine Art Sonderfall sein sollte.

Was würde es davon abhalten? Was fehlt mir in meiner Argumentation?

9
ParanoidAndroid

Lesen

Ursprungsübergreifende Ressourcenfreigabe CORS und die gleiche Ursprungsrichtlinie SOP sind Ihre Freunde hier . Da das betreffende Javascript nicht von http://127.0.0.1, es läuft gegen die SOP und Standardregeln für CORS in Browsern verhindern, dass das Javascript liest die Antwort. Das deckt Ihre unmittelbare Frage ab - Sie sind standardmäßig geschützt.

Schreiben

Dieser "lesende" Teil ist jedoch der Schlüssel. Der Browser wird unter allen Umständen die Anfrage an den Server senden. Das einzige, was CORS tut, ist zu blockieren, dass JavaScript die Antwort empfängt. Daher hindert CORS einen Angreifer daran, Daten von einem anderen Ort zu lesen, hindert ihn jedoch nicht daran, Daten an einen anderen Ort zu senden.

Wenn Ihre Anwendung aufgrund des Empfangs einer Anfrage wichtige Statusänderungen vornimmt, kann dies zu Problemen führen. CSRF-Token schützen Sie hilfreich vor solchen Angriffen. Um klar zu sein, ist JavaScript nicht einmal erforderlich, damit ein Angreifer eine Anforderung an eine andere Stelle senden kann ( h/t mti2935 ). Ein auf einer von Ihnen besuchten Seite eingebettetes Tag img kann eine Anforderung GET an einen beliebigen Server auslösen Angreifer können besonders leicht unerwünschte Aktionen auslösen, wenn Ihr Server aufgrund einer Anforderung GET Aktionen ausführt.

Wenn Ihre Anwendung Statusänderungen ohne CSRF-Schutz vornimmt und der Angreifer den Endpunkt kennt, sind Sie möglicherweise in Schwierigkeiten. Für ein reales Beispiel wurden unsichere und häufig verwendete Router auf diese Weise ausgenutzt. Betrachten Sie diese hypothetische URL in der Webanwendung, die von einem Heimrouter gehostet wird:

http://admin:[email protected]/enable_remote_admin_access

Es ermöglicht den Remote-Administratorzugriff (auch bekannt als Anpassung der Konfiguration, damit sich Benutzer über das Internet beim Administratorbereich des Routers anmelden können), verfügt über eine bekannte URL, erfordert eine grundlegende Authentifizierung und der Router wird mit einem bekannten Standardbenutzernamen und -kennwort geliefert (admin: admin). Infolgedessen erstellt ein Angreifer eine Webseite, auf der eine einfache GET- Anforderung an die oben genannte URL gesendet wird. Der Angreifer erhält keine Antwort vom Router (aufgrund von CORS), aber der Router empfängt die Anforderung weiterhin und ist jetzt bereit, Administratorverbindungen aus dem Internet zu akzeptieren, wenn er anfällig ist. Das böswillige Skript ruft dann mit der IP-Adresse des Opfers nach Hause und ein anderes schnelles Skript überprüft die IP-Adresse, um festzustellen, ob jetzt ein Router verfügbar ist. Wenn ja, hat der Angreifer stillschweigend die volle Kontrolle über das Heimnetzwerk des Opfers erlangt, einfach weil er die falsche Seite besucht und einen gemeinsamen, anfälligen Router verwendet hat.

Arithmetik

Natürlich ist es viel schwieriger, eine benutzerdefinierte Anwendung wie diese zu nutzen, da es sich um einen blinden Angriff handelt. Ohne Informationen darüber, was sie angreifen, ist es fast unmöglich, Erfolg zu haben. Infolgedessen ist das praktische Risiko wahrscheinlich gering, da die Angriffsfläche so klein ist. Dennoch sind hier einige Vorsichtsmaßnahmen zu beachten:

  1. Bei einem gezielten Angriff sind alle Wetten ungültig. Wenn der Angreifer weiß, dass Sie lokal Software mit einer Sicherheitsanfälligkeit ausführen, müssen Sie nur den falschen Link aufrufen.
  2. Die CORS-Konfiguration ist wichtig. Wenn Ihre lokale App eine übermäßig zulässige CORS-Konfiguration verwendet, kann ein Angreifer die Ergebnisse lesen und Ihre Anwendung "durchsuchen".
  3. Abhängig von der Konfiguration des Netzwerks sind möglicherweise einige grundlegende Port-Scans möglich.
  4. DNS-Neubindung ( h/t EdC ) kann es einem Angreifer ermöglichen, die SOP und CORS) zu umgehen. Es kann Hindernisse für einen solchen Angriff geben Ein entschlossener Angreifer kann jedoch seine Erfolgschancen verbessern, indem er sie verwendet.
11
Conor Mancone