Wie kann ich das überschreiben der Origin-header in Chrome, wenn eine Verbindung zu einem WebSocket?

Ich versuche eine Verbindung zu einem externen web-socket-server, welcher nicht laufen durch mich. Ich möchte schließen, um es von einem localhost javascript-Datei, also den origin-header hat den Wert null.

Ich verstehe, dass dies eine Maßnahme gegen cross-site-forgery. Allerdings, da bin ich auf localhost, ich sollte in der Lage sein, um fake diese, indem man Chrome an, senden Sie eine benutzerdefinierte Origin-header.

Ist es möglich? (wenn ich brauche eine extension, die ist in Ordnung)

Wenn nicht, was ist meine beste option zur Erreichung der oben genannten? Danke.

InformationsquelleAutor David Frank | 2015-05-17
  1. 12

    Web-Seiten können nicht ändern den Origin-header, aber Erweiterungen ändern können in den Kopfzeilen der Anfrage über die chrome.webRequest API. Aber ws:// und wss:// werden nicht unterstützt von dieser API, so dass diese nicht helfen, es sei denn, der server unterstützt auch andere Mittel der Kommunikation über http(s) (z.B. long-polling).

    Gibt es noch eine Lösung wenn: laden Sie Einfach eine (bekannte) Webseite an der gewünschten Ursprung in einem iframe (z.B. https://example.com/favicon.ico oder https://example.com/robots.txt) und eine Inhalt Skript zum öffnen des WebSocket-von dort aus.

    • Danke für diesen Tipp, ich werde versuchen es am Wochenende und kommen zurück.
    InformationsquelleAutor Rob W
  2. 5

    Den Origin - header ist ein Header, die automatisch festgelegt werden, indem der user-agent (als Teil der browser-Implementierung) und kann nicht verändert werden programmgesteuert oder durch Erweiterungen. Dies macht Sinn, da web-service-Anbieter können nicht zulassen, zufällige verbindungen von localhosts.

    Können Sie eine Verbindung zu einem externen WebSocket-nur wenn Ihr es von einem host ausdrücklich akzeptiert, indem Sie die web-service-provider. Viele Titel kann man nicht trauen (weil Sie überschrieben werden können), aber dies ist nicht der Fall mit Origin denn Sie bietet Sicherheit nicht nur für die Nutzer, aber auch für Dienstleister gegen unerwünschte verbindungen.

    • Es ist etwas, was ich nicht verstehe. Wie kann der service stellen Sie sicher, dass ich keinen fake Herkunft? Warum kann ich in Chrome den Quellcode und ändern Sie die einschränkende Teil oder bauen eigene browser, der hat keine solche Beschränkung? Ich denke, es ist ein design-Prinzip, das nicht lass es mich tun, aber was ist es?
    • Ok, ich habe in der RFC, und er sagt: "Die Absicht ist nicht zu verhindern, dass nicht-Browser von verbindungen, sondern vielmehr, um sicherzustellen, dass trusted Browser unter der Kontrolle von potenziell schädlichen JavaScript-Code kann nicht fake eine WebSocket-handshake." Auf dieser Basis ich denke, der origin-header ist nur Mittel, um zu verhindern, dass eine bösartige website eine Verbindung zu einem Drittanbieter-web-Steckdose von einem browser des Benutzers, ohne dass Sie es zu wissen.
    • Der service provider in diesem Fall nur überprüft die Origin-header und dem er vertraut, um kompromisslose. Natürlich, in der Theorie könnte man manipulieren der browser-code oder erstellen Sie ein tool für benutzerdefinierte HTTP-Anfragen, aber dies ist nicht trivial und wird nicht empfohlen. Ja, der Origin-header soll zunächst auf die Benutzersicherheit. Es ist mehr oder weniger das gleiche wie mit Crawlen von Webseiten, die explizit verbieten dies in einem robots.txt Datei (niemand kann garantieren, es wird geehrt).
    • Der Dienst kann nicht stellen Sie sicher, dass Sie ein legit Origin, aber es ist sicher, dass ANDERE Benutzer sind nicht betrogen worden, indem Sie Ihre website an Dritte, Bedarf der richtigen Herkunft.
    • Ja, Sie können erstellen Sie einen browser, der dies tut, aber wie Sie die Kraft anderen Menschen zu, verwenden Sie Ihre browser geändert? Wenn Sie sind die einzige, die mit Ihrem unsicheren browser Sie sind nur sich selbst verletzen. Wir Vertrauen Apple/Google/Mozilla, um uns mit Browsern, die verhindern, dass das ändern der Origin-header.
    InformationsquelleAutor adriann
  3. 1

    Soweit ich weiß, das wird nicht möglich sein, es würde zu brechen, die Sicherheit Schutz gegen CSRF-Angriffe in Chrom.

    Wenn Sie in der Lage waren zu tun, dass das ganze Konzept des XHR-würde auseinander fallen.

    Hier ist eine Erweiterung, die Sie verwenden können, um zu manipulieren header-on-the-fly, aber so weit ich habe nicht in der Lage gewesen, um es zu manipulieren, socket Header.

    Aussehen hier wenn Sie möchten, um mehr darüber zu Lesen.

    Aber das bedeutet nicht aufhören Sie von der Umsetzung Ihrer eigenen client (anstelle von chrome), wo Sie buchstäblich senden was auch immer-Headern, die Sie wollen, nicht sicher, ob dies Ihnen hilft, sorry.

    • Sicherheit Schutz gegen CSRF-Angriffe sind in der Regel zum Schutz der Benutzer. In diesem Fall jedoch meine Absicht (Nutzer) ist für das hinzufügen von Ausnahmen zu chrome zu Schwächen, dieser Schutz. Da chrome und erstellt und sendet die http-Anfrage, in der Theorie sollte ich in der Lage zu überschreiben Header (vielleicht mit einer Erweiterung).
    • Ich füge eine Erweiterung, die ich gefunden, dass ermöglicht die header-änderungen. Ich war in der Lage, ändern Sie die Kopfzeilen, aber noch nicht bei der Verwendung von sockets für einige Grund.
    InformationsquelleAutor tato
  4. 0

    Es hängt davon ab, wie Sie wollen verwenden Sie Ihren chrome-browser. Da Sie erwähnen, localhost, ich nehme an, Sie entwickeln und für eine Art der Schaben. Ich schlage vor, dass Sie erkunden Chrome DevTools-Protokoll die render (fast) jede Art von Schutz nutzlos, weil Sie von einem echten browser. CORS, Herkunft, Plätzchen oder beliebige header-Wert unter Kontrolle zu sein, und Sie können senden Sie eine benutzerdefinierte Kopfzeile für xhr/websocket request(s). Wenn Sie wollen, um zu manipulieren in einem fortgeschrittenen Art und Weise können Sie Netzwerk.continueInterceptedRequest. Könnten Sie nur wollen, starten Sie chrome über Parameter wie "--disable-web-security, --disable-xss-auditor, --disable-client-side-phishing-Erkennung, --allow-insecure-localhost" mehr über diese Optionen zu peter.sh. Aber die Letzte option, ein plugin benötigen, um vorzutäuschen, um die origin-header, so empfehle ich die erste option.

    InformationsquelleAutor Gillsoft AB
Schreibe einen Kommentar