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).
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).