Beantwortet: Fehlkonfiguration PP Proxys / Origin Header unterdrückt

Physalis

Junior Member
Hi,

ich habe heute festgestellt das die PP Proxyserver (Squids) fehlkonfiguriert sind und es in bestimmten Fällen zu Fehlern kommt. Das Problem ist das der "Origin" Header in einem HTTP GET request von den Proxys ausgefiltert wird. Dies ist problematisch, da damit einige cross-origin-resource-sharing Anfragen (CORS) im Browser fehlschalgen. Insbesondere Firefox ist hiervon betroffen.

Kurzer technischer Hintergrund:

Für die XMLHttpRequest Anfragen ("AJAX") in modernen Webseiten mit JavaScript/AJAX die zu einem anderen Server gehen als den original angefragten, setzt der Browser automatisch den "Origin" header mit der Urpsrungsdomain. Beispiel: "Origin: http://perfect-privacy.com". Der Empfangende Server (z.B: example.com) muss den Header "Access-Control-Allow-Origin" setzen - sonst verwirft der Browser die Anfrage. Nun setzen die meisten Server den "Access-Control-Allow-Origin" Header einfach auf "*" um alle Anfragen zu erlauben. Das Problem ist, das der Wildcard "*" gemäß Spec aber nicht erlaubt ist bei Anfragen die Credentials enthalten, z.B. wenn ein Cookie gesetzt ist (siehe hierfür https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Requests_with_credentials). Hier MUSS dann ein konkreter Hostname stehen. Daher senden einzelne Server in diesem Fall den vom Client gesetzten "Origin" Header dort zurück, damit die Anfrage funktioniert (simpler Echo).

Ich habe aber festgestellt, das PP diesen "Origin" Header pauschal herausfiltert. Das führt dazu, dass der Server den Origin nicht auswerten kann und die Anfrage in Firefox (evntl auch anderen Browsern) fehlschlägt.

In der Praxis führt das dazu, dass z.B. Verbindungen zu der neusten Version des socket.io Framework (http://socket.io) fehlschlagen: Websockets unterstüzten die Squids sowieso nicht, aber der Fallback ist XmlHttpRequest Polling. Dieses XHR Polling setzt eben auf den Origin Header in Verbindung mit dem Session Cookie (=Credential). Da der Origin Header von den PP Proxys aber gefiltert wird, schlägt der Request fehl bzw. es wird die Wildcard gesendet was in diesem Fall nicht zulässig ist - daher ist derzeit gar keine Verbindung möglich.

Reproduzieren des Problems:

Ich kann das ganze reproduzieren mit folgendem Setup:

1. Linux/UNIX Server nehmen unter z.B. example.com und dort Netcat auf einen beliebigen Port (z.B. 9999) starten:

nc -l -p 9999

2. Von anderem Linux Rechner folgenden cURL request absenden:

curl http://example.com:9999 -H "Origin: somehost.com" --proxy http://username:password@steinsel.perfect-privacy.com:3128

Ergebniss: Auf dem Server auf dem Netcat läuft sieht man die Header und die Anfrage kommt an, der Origin Header fehlt allerdings. Entfernt man den "--proxy" Paramter und wiederholt den Request, kommt der Requst inkl. Origin Header korrekt an. Daher schließe ich daraus, das die PP Proxys den Header herausfiltern.

Das solch speziellen CORS Requests in der Praxis immer häufiger auftreten (insbesondere bei modernen Websites die Websockts verwenden und XHR Longpolling als Fallback verwenden) dürfte das zunehmend ein Problem werten. Die Konfiguration der Proxies sollte dahingehend angepasst werden, dass der "Origin" Header nicht mehr gefiltert wird.

Natürlich wird die Privatsphäre damit etwas aufgeweicht, allerdings nur wenn JavaScript aktiviert ist. Und den aktuellen Hostname via JavaScript an eine Dritte Stelle zu versenden wäre zur Zeit bereits möglich (der Client könnte im XmlHttpRequest einen eigenen Header X-Custom-Origin erstellen und mit dem Inhalt aus window.location.href befüllen, dieser wird nicht von PP herausgefiltert und gelangt zum Ziel).
 
Solution
Jep, stimmt, die Proxys entfernen den origin header, bzw alle header die sie nicht kennen.

Das ist quasi die alte "http_anonymizer paranoid" option [http://www.squid-cache.org/Doc/config/request_header_access/ ]
Und die Proxys ersetzen den user agent. In dem Thread: https://board.perfect-privacy.com/threads/http-proxy.203/ hab ich mal die config geposted.

Ist die Frage ob wir das so lassen wollen.

Auf der einen Seite hab ich in letzter Zeit das Gefühl als würden die Proxys eh nur von Leuten benutzt die wissen was sie tun, und die vor allem gar keine Browser benutzen sondern irgendwelchen Code und Programm die durch die Proxys gehen. Von denen hab ich z.b. schon öfter gehört das sie von dem user agent rewrite genervt sind...
Jep, stimmt, die Proxys entfernen den origin header, bzw alle header die sie nicht kennen.

Das ist quasi die alte "http_anonymizer paranoid" option [http://www.squid-cache.org/Doc/config/request_header_access/ ]
Und die Proxys ersetzen den user agent. In dem Thread: https://board.perfect-privacy.com/threads/http-proxy.203/ hab ich mal die config geposted.

Ist die Frage ob wir das so lassen wollen.

Auf der einen Seite hab ich in letzter Zeit das Gefühl als würden die Proxys eh nur von Leuten benutzt die wissen was sie tun, und die vor allem gar keine Browser benutzen sondern irgendwelchen Code und Programm die durch die Proxys gehen. Von denen hab ich z.b. schon öfter gehört das sie von dem user agent rewrite genervt sind weils ihnen dazwischenfunkt wenn curl was eigenes senden soll.

Auf der anderen Seite hab ich keine Ahnung wie viele Menschen die Proxys aufm Handy oder so benutzen und davon Profitieren das der Proxy da ein paar Dinge rauswirft.

Können wir da eine Kurze Meinungsumfrage zu machen?

Sollen die Proxys alles blocken und nur ein paar header explizit erlauben?
Oder sollen die Proxys nur ein paar header blocken und sonst alles erlauben?
Oder sollen die Proxys gar nichts blockieren?
Sollen wir weiterhin den Useragent rewriten?

Grüße
Lars
 
Last edited:
Solution
Ich würde das trennen, den User-Agent zu filtern halte ich nicht für schlimm, aber den Origin Header schon aus folgendem Grund:

Der User-Agent ist schon immer ein optionales Feature gewesen, also Browser können, müssen aber laut Spec keinen UA header setzen. Wenn Webseiten dann ohne UA Header Fehler produzieren, ist das weil die Webseiten gegen entsprechende Specs/RFCs verstoßen. Filtert der PP Proxy den Header raus, so ist das zumindest alles im Rahmen von Webstandards.

Beim Origin Header ist die Sache anders gelagert: Ein W3C Standard (http://www.w3.org/TR/cors/) gibt vor, dass die Browser diese setzen MÜSSEN bei den CORS Anfragen. Filtert hier ein PP Proxy diesen Header heraus, wird funktional gegen den Standard verstoßen. Ein Webseitenbetreiber macht also alles richtig und standardkonform, dennoch kommt es zu Fehlern weil in das Protokoll eingegriffen wird.

Ich weiß nicht in wie weit es technisch möglich wäre, aber man kann in Squid begrenzt mit if() Conditionals arbeiten. Wäre es möglich keine Filterung vorzunehmen wenn der Client einen spziellen Header mitschickt? Z.B. "X-Leave-My-Headers-Alone", in diesem Fall würde dann keine Filterung vorgenommen. Den Header kann man via cURL setzen, und auch bei den meisten Browsers dürfte es Extensions geben. So wäre es für Pro-User möglich via Opt-In möglich, und die unbedarften User hätte weiterhin etwas mehr privatsphäre (wobei eine Header Filterung bei einem unverschlüsseltem Proxy sicherlich kein Vollschutz ist). Oder alternativ für jeden Proxy künftig 2 Konfigurationen auf zwei unterschiedlichen Ports, die eine mit voreingestelltem Header Filter und die andere die Plain alles durchreicht - dann hat man jeweils die Wahl.

Ich benutze den Proxy sowieso nur über SSH Tunnel, meist um Corporate-Firewalls von Innen zu umgehen weil ich keine Lust habe das der Corporate-Proxy mein Surfverhalten mitschneidet. Ein Non-Standard-Port für die Proxykonfiguration wäre (wegen des SSH Tunnels zu PP) kein Problem für Pro-User.
 
Nachtrag: Ich habe nochmal über den Origin Header nachgedacht. Diesen zu aktiveren (und nur diesen) birgt IMHO kein wirkliches Risiko bzw. weicht die Privatsphäre nicht wirklich auf. Der Wert des Headers ist im Regelfall die Domain der Seite, die man gerade besucht. Diese Seite triggert einen CORS request. D.h. die Zielseite kennt den Urpsrung (so wie bei einem Referrer). Allerdings ist dort keine Pfadangabe enthalten, sondern NUR der Hostname mit Port.

Bsp: WebsiteA.com enthält JavaScript Code, der ein CORS Request auf WebsiteB.com enthält. Der Header der an WebsiteB geht ist: 'Origin: http://websitea.com:80'. WebsiteB braucht ggf. diese Information (siehe mein ersteller Originalpost), aber die Information enthält sonst keinerlei userbezogene Daten bzw. Daten die die Privatsphäre tangieren. Das WebsiteA überhaupt CORS requests zu WebsiteB veranlasst, weiss die WebsiteB so oder so von den Usern die ohne PP unterwegs sind.

Daher nochmal meine Meinung: Es kann ja alles so bleiben wie es ist beim User-Agent und anderen Headern, aber der Origin Header sollte auf eine Whitelist weil CORS/AJAX immer verbreiteter werden und der Standard das auch so vorgibt.
 
Physialis, mehr Forenmitglieder wie dich braucht die Welt! Höflich, gute Rechtschreibung, kompetent! Offtopicquatsch wie "Keine Ahnung, aber gleich wird sich sicher jemand melden, der Ahnung davon hat!" (ich spreche hier gezielt eine Person an) und mein Post gerade, welches ich mir ausnahmsweise mal erlaube, sollte verpönt sein. Weiter so!
 
Ja sehr schön ok dann machen wir das so:

Ich whiteliste den origin header und lasse den Rest der Squid config wie er ist.

Und dann mach ich wahrscheinlich eine 2. Squid Instanz auf einem andere Port komplett ohne die Filterei für Leute die die Proxys mit curl/code benutzen oder den zusätzlichen Schutz nicht brauchen oder wollen.

Grüße
Lars
 
Back
Top