Safari sendet Passwort im Referrer an fremde Seiten

[André]

Folgendes Phänomen habe ich kürzlich entdeckt: wird eine Seite in einem passwortgeschützten Verzeichnis mit einer URL aufgerufen, die den Usernamen und das Passwort bereits enthält - Schema:

http://username:[e-mail]/verzeichnis/datei.php4

zegt der Safari als einziger getesteter Browser das Passwort im Klartext in der Adresszeile des Browsers an. Beim Weitersurfen wird das Passwort dort von Seite zu Seite im Klartext mitgeschleppt. Eine dieser Seiten ist eine Vorschau, die ein kleines Menü mit Links zu den gängigen Online-Validatoren enthält, u.a. diesen:

http://www.validome.org/referer

Klickt man diesen Link an, holt sich Validome die URL der zu prüfenden Seite aus der Referrer-Angabe des Browsers. So, und jetzt kommt's: Die Ergebnisseite von Validome zeigt die URL der geprüften Vorschauseite an und zwar *mit* Passwort und Benutzername. Safari übergibt diese Daten also irgendwie an die aufgerufene Validome-Webseite - ich weiß nur nicht, wie.

document.referrer (Javascript) enthält das Passwort nicht, lediglich in document.URL ist es enthalten. In irgendwelchen PHP-Variablen ($_SERVER) habe ich gar nichts gefunden.

Frage: Gibt es irgendeine Möglichkeit, via PHP festzustellen, ob die URL der aktuellen Seite eine Username/Passwort-Phrase enthält? (Ich habe zwar eine JavaScript-Funktion, aber die funktioniert natürlich nur bei eingeschaltetem JavaScript).

André

[wahsaga]

hi,

Folgendes Phänomen habe ich kürzlich entdeckt: wird eine Seite in einem passwortgeschützten Verzeichnis mit einer URL aufgerufen, die den Usernamen und das Passwort bereits enthält - Schema:
http://username:[e-mail]/verzeichnis/datei.php4

"Ja, wer macht denn sowas?" [1]

zegt der Safari als einziger getesteter Browser das Passwort im Klartext in der Adresszeile des Browsers an. Beim Weitersurfen wird das Passwort dort von Seite zu Seite im Klartext mitgeschleppt.

Ein Grund mehr, auf sowas zu verzichten.
In einem IE auf aktuellen Patch-Level dürfte es übrigens gar nicht mehr funktionieren.

Klickt man diesen Link an, holt sich Validome die URL der zu prüfenden Seite aus der Referrer-Angabe des Browsers. So, und jetzt kommt's: Die Ergebnisseite von Validome zeigt die URL der geprüften Vorschauseite an und zwar *mit* Passwort und Benutzername. Safari übergibt diese Daten also irgendwie an die aufgerufene Validome-Webseite - ich weiß nur nicht, wie.

Na wie wohl - als HTTP_REFERER in den HTTP Request Headern.

document.referrer (Javascript) enthält das Passwort nicht, lediglich in document.URL ist es enthalten.

Was er als Referrer übermittelt, muss ja nichts mit dem zu tun haben, was er in Javascript zur Verfügung stellt.

In irgendwelchen PHP-Variablen ($_SERVER) habe ich gar nichts gefunden.

Auch nicht im HTTP_REFERER einer weiteren Seite, die du von der "geschützten" aus aufrufst?

Frage: Gibt es irgendeine Möglichkeit, via PHP festzustellen, ob die URL der aktuellen Seite eine Username/Passwort-Phrase enthält? (Ich habe zwar eine JavaScript-Funktion, aber die funktioniert natürlich nur bei eingeschaltetem JavaScript).

Frage: Was willst du _eigentlich_ erreichen, sprich warum siehst du dich überhaupt veranlasst, die Authentifizierungsdaten auf einem derart unsicheren Wege zu übergeben?

gruß,
wahsaga

[1] Zweiter Teil des Witzes, der mit "Herr Doktor, Herr Doktor - ich habe einen Knoten in der Brust!" beginnt.

[André]

zeigt der Safari als einziger getesteter Browser das Passwort im Klartext
Ein Grund mehr, auf sowas zu verzichten.

Ja, aber eine Sicherheitslücke ist eine Sicherheitslücke ist eine Sicherheitslücke. Durch Verzicht ist noch keine Sicherheitslücke verschwunden.

In einem IE auf aktuellen Patch-Level dürfte es übrigens gar nicht mehr funktionieren.

Korrekt. Firefox und Opera geben an dieser Stelle einen unmissverständlichen Warnhinweis aus, ignoriert man diesen, übergeben diese Browser das Passwort trotzdem nicht an Validome.

In irgendwelchen PHP-Variablen ($_SERVER) habe ich gar nichts gefunden.
Auch nicht im HTTP_REFERER

Nein.

Frage: Was willst du _eigentlich_ erreichen, sprich warum siehst du dich überhaupt veranlasst, die Authentifizierungsdaten auf einem derart unsicheren Wege zu übergeben?

Weil nach Murphy's Gesetz alles, was schiefgehen kann, auch schiefgehen wird. Ich will verhindern, dass im Falle dieses Falles ein Benutzer die o.g. Sicherheitslücke unbewusst aufreißt. Wenn Safari solche Aktionen nicht abfängt, dann muss es eben die im passwortgeschützten Verzeichnis befindliche Website tun. Aber irgendjemand *muss* es tun, alles andere zu diskutieren ist müßig.

André

[wahsaga]

hi,

Ja, aber eine Sicherheitslücke ist eine Sicherheitslücke ist eine Sicherheitslücke. Durch Verzicht ist noch keine Sicherheitslücke verschwunden.

Zugangsdaten im URL zu übergeben, ist für HTTP überhaupt nicht definiert.
Zu erwarten, dass sich alle potentiellen Clients gleich verhalten in Bezug auf etwas, das gar nicht definiert ist, ist irrational.

Weil nach Murphy's Gesetz alles, was schiefgehen kann, auch schiefgehen wird. Ich will verhindern, dass im Falle dieses Falles ein Benutzer die o.g. Sicherheitslücke unbewusst aufreißt.

Dann erziehe deine Benutzer.
Oder sorge dafür, dass sie, so sie denn nicht hören wollen, nur Schaden in einem eigenen Account anrichten können.

Wenn Safari solche Aktionen nicht abfängt, dann muss es eben die im passwortgeschützten Verzeichnis befindliche Website tun. Aber irgendjemand *muss* es tun, alles andere zu diskutieren ist müßig.

Also *muss* auch irgendjemand ständig aufpassen, dass der Benutzer sein Passwort nicht aufschreibt und den Zettel irgendwo liegen lässt - alles andere zu diskutieren ist müßig.

gruß,
wahsaga

[Der Martin]

Hallo,

Ein Grund mehr, auf sowas zu verzichten.
In einem IE auf aktuellen Patch-Level dürfte es übrigens gar nicht mehr funktionieren.

wenn man es ihm ausdrücklich erlaubt, funktioniert es zum Glück wieder - jedenfalls so wie in allen vorherigen Versionen: Dass man Benutzernamen und Passwort in der Adresszeile mit eingeben kann, und der IE das auseinanderdröselt und die richtigen HTTP-Header für ein HTTP-AUTH daraus macht. Ob er das auch tut, wenn solche Angaben in einem Link auftauchen, habe ich noch nicht ausprobiert. In einem Bookmark geht's jedenfalls.

warum siehst du dich überhaupt veranlasst, die Authentifizierungsdaten auf einem derart unsicheren Wege zu übergeben?

Wenn's um die Eingabe in der Adresszeile geht: Bequemlichkeit. Auch in einem IE-Bookmark kann ich die Zugangsdaten dann hinterlegen und damit Seiten, die HTTP-AUTH erfordern, direkt aus den Bookmarks aufrufen.
Wenn's um die Übergabe per Link geht: Bei vielen mit HTTP-AUTH ausgestatteten Seiten dienen die Daten nur zur Erkennung des Users, ohne dass dabei irgendeine Art der Zugangskontrolle *nötig* wäre. Gerade so wie hier im Forum, wo ja die für die /my/-Ansicht nötigen Zugangsdaten auch keine bedeutenden Daten schützen - demzufolge wäre es auch nicht weiter tragisch, wenn jemand anders sie in die Finger kriegt. Und das gilt für sehr viele Sites, die entweder aus Paranoia oder aus Technophilie ein Passwort anfordern.

Ciao,
 Martin

[André]

Dass man Benutzernamen und Passwort in der Adresszeile mit eingeben kann, und der IE das auseinanderdröselt und die richtigen HTTP-Header für ein HTTP-AUTH daraus macht.

Genau darum gehts: ein Browser muss die URL korrekt aufdröseln, schließlich handelt es sich bei der besagten Passwortübergabe-Methode um *offiziellen Standard*, der nachwievor gültig ist! Ein Browser muss das wissen, ansonsten hat er eine Sicherheitslücke. So einfach ist das.

Und das gilt für sehr viele Sites, die entweder aus Paranoia oder aus Technophilie ein Passwort anfordern.

Es geht um ein CMS, welches passwortgeschützt sein muss, damit nicht Fremde in der damit erzeugten Website herumschmieren können. Es gibt seit langem Würmer, die das Internet gezielt nach ungeschützten Seiten abscannen - sie rufen einfach Verzeichnisse wie z.B. "php_myadmin" auf und gucken, ob sie dort reinkommen.

André

[wahsaga]

hi,

Genau darum gehts: ein Browser muss die URL korrekt aufdröseln, schließlich handelt es sich bei der besagten Passwortübergabe-Methode um *offiziellen Standard*, der nachwievor gültig ist!

Diese Methode war für HTTP-URLs m.W. nie definiert.
Für FTP-Adressen u.ä. schon.

Ein Browser muss das wissen, ansonsten hat er eine Sicherheitslücke. So einfach ist das.

Ach, so einfach ist das.

Es geht um ein CMS, welches passwortgeschützt sein muss, damit nicht Fremde in der damit erzeugten Website herumschmieren können. Es gibt seit langem Würmer, die das Internet gezielt nach ungeschützten Seiten abscannen - sie rufen einfach Verzeichnisse wie z.B. "php_myadmin" auf und gucken, ob sie dort reinkommen.

Zwischen ungeschützt aufrufbaren Inhalten/Scripten, und Nutzerdummheit in Form von Weitergabe von Zugangsdaten in Links ist es noch ein himmelweiter Unterschied.

gruß,
wahsaga

[André]

Diese Methode war für HTTP-URLs m.W. nie definiert.
Für FTP-Adressen u.ä. schon.

Haste nicht ganz unrecht. Hab eben nochmal recherchiert. RFC 2396 beschreibt dieses URI-Schema allgemein (Username:Passwort erlaubt), RFC 1738 hebt dieses speziell für http:// wieder auf.

Aber wie dem auch sei, das ändert nichts daran, dass ein Browser nicht mit Passwortdaten in der Gegend herumschmeißen darf. Bei ftp://-URL, in denen Passwörter ja erlaubt sind, darf er das schließlich auch nicht.

Wie gesagt, es ist müßig, darüber zu philosophieren, und sich um eine Lösung herumzudrücken, weil man sich dafür nicht verantwortlich fühlt. Wenn ich mich für meine Arbeit nicht verantwortlich fühle, brauche ich mich über das Fehlverhalten von Kunden/Anwendern erst recht nicht aufzuregen. So einfach ist das.

In diesem Sinne: ich suche einen sicheren Erkennungsmechanismus (PHP), mit dem solche Eventualitäten abgefangen werden können.

André

P.S.: Wen's interessiert: die JavaScript-Methode sieht so aus:

if (document.URL.indexOf("@")!=-1)
window.location.replace(window.location.protocol+"//"+document.URL.substr(document.URL.indexOf("@")+1));

[wahsaga]

hi,

Wie gesagt, es ist müßig, darüber zu philosophieren, und sich um eine Lösung herumzudrücken, weil man sich dafür nicht verantwortlich fühlt. Wenn ich mich für meine Arbeit nicht verantwortlich fühle, brauche ich mich über das Fehlverhalten von Kunden/Anwendern erst recht nicht aufzuregen. So einfach ist das.

Gehört es zu deiner Arbeitsphilosophie, für alles die Verantwortung zur übernehmen, was auf der Welt schlecht läuft?

In diesem Sinne: ich suche einen sicheren Erkennungsmechanismus (PHP), mit dem solche Eventualitäten abgefangen werden können.

Ich denke nicht, dass es einen solchen geben kann.

Ich wüsste nicht, was an dem, was der Browser dem Server schickt, wenn er einen solchen URL akzeptiert und korrekt umsetzt, sich von dem unterscheiden sollte, was beim "normalen" Ablauf von HTTP Auth stattfindet.

Gut, wenn der Browser Nutzername und Passwort gleich zur Verfügung hat, wartet er vielleicht gar nicht auf die Anforderung vom Server, diese Daten zu übermitteln (401) - das könnte man ggf. checken (wenn auch nur bedingt in PHP).
Aber dieses Szenario kann ja möglicherweise auch unter anderen Umständen auftreten.

gruß,
wahsaga

[André]

Gehört es zu deiner Arbeitsphilosophie, für alles die Verantwortung zur übernehmen, was auf der Welt schlecht läuft?

Nein, nur für die Teile der "Welt", die ich persönlich "geschaffen" habe. Und das erwähnte CMS gehört dazu. Da ich nicht kontrollieren kann, was ein Browser (insbesondere Browser, die erst in Zukunft auf uns zukommen) im Referrer-String so alles ausplaudert, könnte ich z.B. den Validator-Link so ändern, dass die URL der zu prüfenden Seite als GET-Parameter und nicht als Referrer an den Validator übergeben wird. Das ändert allerdings leider nichts daran, dass die aufgerufene Seite den Referrer *zusätzlich* trotzdem noch auslesen kann, womit nichts gewonnen ist.

Das Problem ist also ein grundsätzliches. Nicht ohne Grund war z.B. das Auslesen der Browser-History via JavaScript (Objekt "history") noch nie möglich. Ein neuer Browser, der diese Regel nicht einhält, ist ein Sicherheitsrisiko, welches wir vorher nicht hatten. Da alle - auch ältere - Browser mit einem Passwort in der URL bisher korrekt umgehen konnten, ist der Safari in diesem Punkt ein Sicherheitsrisiko, welches wir vorher nicht hatten. Ich mein', wir wollen die Zahl der Sicherheitslöcher doch verringern und uns nicht immer wieder neue Sch**** an den Hals holen.

Ich wüsste nicht, was an dem, was der Browser dem Server schickt, wenn er einen solchen URL akzeptiert und korrekt umsetzt, sich von dem unterscheiden sollte, was beim "normalen" Ablauf von HTTP Auth stattfindet.

Wenn der Browser Passwort und Benutzername aus der URL ausschneiden und in HTTP-Header überführen würde, dann wüsste ich auch keinen Unterschied.

André

[wahsaga]

hi,

Wenn der Browser Passwort und Benutzername aus der URL ausschneiden und in HTTP-Header überführen würde, dann wüsste ich auch keinen Unterschied.

Tut er, muss er.

Kein Server dürfte etwas mit
http://user:[e-mail]/
anfangen können.

Der Browser macht also sowas wie
GET / HTTP/1.1
Host: example.com
daraus, und übergibt auch noch user und password so wie für HTTP Auth definiert.

Der Server dürfte m.E. absolut nicht mitbekommen, dass auf dem Client die die Zugangsdaten in der Adresszeile standen.

Da fällt mir jetzt gerade beim Schreiben noch eine potentielle Möglichkeit der Überprüfung ein:

Den Referrer übermittelt der Client bei der nächsten Anfrage an den Server.
Also wäre das allerhöchstens der Punkt, an dem du ansetzen könntest - sorge dafür, dass ein weiterer Request stattfindet. Wenn du dann einen Referrer übermittelt bekommst, der die Zugangsdaten enthält - ja, dann darfst du meinetwegen den Client verfluchen, und dir dann überlegen, wie du darauf reagieren willst.

Nur: Redirect als Reaktion darauf dürfte m.E. nicht möglich sein.
Machst du für das Haupt-Dokument einen Redirect, bspw. von
http://user:[e-mail]/index.php
auf
http://user:[e-mail]/index.php?checkreferrer=true

• dann dürfte der Client keinen Referrer übermitteln, bzw. wenn dann den, von dem aus ursprünglich auf
  http://user:[e-mail]/index.php
  verwiesen wurde.

Also bleibt nur, aus dem Hauptdokument eine weitere Ressource anzufordern - bspw. ein Bild. Dabei müsste der Referrer übertragen werden.
Nur nützt dir hier ein Redirect nichts - weil du damit nur die Adresse für die in diesem Request angefragte Ressource ändern kannst, also die des Bildes.

Könnte man ggf. über eine Vorschaltseite und Sessions lösen.
User _muss_ über Vorschalt-/Einstiegsseite gehen, dabei wird ein Wert in der Session hinterlegt.
Werden dann von der Vorschaltseite aus die Unterseiten aufgerufen, wird auf den Wert in der Session geprüft - fehlt er, kommt der Nutzer nicht rein. Ist er vorhanden, wird auf "bösen" Referrer geprüft - auch hier Abbruch.
Nur schränkt eine solche Vorschaltseite den Komfort natürlich auch wieder ziemlich ein - Schluss mit Quereinstieg über Bookmarks etc.

gruß,
wahsaga

[André]

Kein Server dürfte etwas mit
http://user:[e-mail]/
anfangen können.

Der Browser macht also sowas wie
GET / HTTP/1.1
Host: example.com
daraus, und übergibt auch noch user und password so wie für HTTP Auth definiert.

Der Server dürfte m.E. absolut nicht mitbekommen, dass auf dem Client die die Zugangsdaten in der Adresszeile standen.

Genau so sehe ich das auch. Aus diesem Grunde enthält auch keine der $_SERVER-Variablen das Passwort - auch HTTP_REFERER nicht.

Den Referrer übermittelt der Client bei der nächsten Anfrage an den Server.
Also wäre das allerhöchstens der Punkt, an dem du ansetzen könntest - sorge dafür, dass ein weiterer Request stattfindet. Wenn du dann einen Referrer übermittelt bekommst, der die Zugangsdaten enthält - ja, dann darfst du meinetwegen den Client verfluchen, und dir dann überlegen, wie du darauf reagieren willst.

Wie gesagt, $_SERVER['HTTP_REFERER'] ist *immer* sauber, ebenso document.referrer. Ich frage mich deshalb, wie die Validatorseite überhaupt in der Lage war, an einen Referrer-String zu gelangen, der das Passwort noch enthält. Also muss es doch irgendwie möglich sein, via JavaScript, PHP oder irgendwelche Apache-Tricks an diese Daten zu gelangen. Aber wie?

André

[wahsaga]

hi,

Wie gesagt, $_SERVER['HTTP_REFERER'] ist *immer* sauber,

Bitte was?
Ich dachte, genau das wäre es, was du dem Safari vorzuwerfen hast - dass der Referrer eben _nicht_ "sauber" ist, sondern Username/Passwort noch drinstehen ...?

Ich frage mich deshalb, wie die Validatorseite überhaupt in der Lage war, an einen Referrer-String zu gelangen, der das Passwort noch enthält.

Entweder der Client hat sie übergeben - oder sie hat die Daten gar nicht bekommen.

Also muss es doch irgendwie möglich sein, via JavaScript, PHP oder irgendwelche Apache-Tricks an diese Daten zu gelangen. Aber wie?

Der einzige, der dem Validator irgendwas gesendet hat, ist der Browser - und zwar lediglich eine Anfrage, die neben der neuen Adresse noch den URL der Seite, auf der sich der Link, der zur aktuellen Anfrage geführt hat befand, als Referrer enthielt.
Und das hat er auf HTTP-Ebene gemacht - also kann da mit an Sicherheit grenzender Wahrscheinlichkeit auch kein Javascript oder PHP im Spiel gewesen sein.

Dass die Safari/WebKit-Entwickler da einen derartigen Bock geschossen haben, kann ich mir nicht vorstellen - ich tippe, nimm's mir nicht übel, nach wie vor auf eine Fehlinterpretation deinerseits.

Sicher, dass der Validator das passwortgeschützte Dokument validiert hat - und nicht etwa die Fehlerseite, die bei nicht gewährtem Zugriff zurückgeliefert wird? (Obwohl man ihm das, so sie denn mit einem korrekten HTTp Status-Code ausgeliefert wurde, extra sagen muss.)

Ist das Verhalten der Kombination Safari/Validator diesbezüglich reproduzierbar?

Schaffst du es, das Verhalten mit einem eigenen Testcase zu reproduzieren? (Passwortgeschütze Seite, mit Username/Passwort im URL aufgerufen, verlinkt auf eine nicht geschützte Seite, die den Inhalt von $_SERVER ausgibt ...)

gruß,
wahsaga

[André]

Wie gesagt, $_SERVER['HTTP_REFERER'] ist *immer* sauber,
Bitte was?

Heul, ja, das ist doch der Wahnsinn. Enthielte $_SERVER['HTTP_REFERER'] username:passwort, könnte ich dem Spuk beim zweiten Seitenaufruf innerhalb des CMS ein Ende machen und dieser Thread hätte nie stattgefunden.

Ich dachte, genau das wäre es, was du dem Safari vorzuwerfen hast - dass der Referrer eben _nicht_ "sauber" ist, sondern Username/Passwort noch drinstehen ...?

Das eine hat mit dem anderen nicht unbedingt etwas zu tun: Die Variable $_SERVER['HTTP_REFERER'] enthält das, was der Web-Server dort hineingetan hat - möglicherweise schneidet er username:passwort vorher heraus, wenn der Browser selbiges in der Referrer-URL enthält.

Der einzige, der dem Validator irgendwas gesendet hat, ist der Browser - und zwar lediglich eine Anfrage, die neben der neuen Adresse noch den URL der Seite, auf der sich der Link, der zur aktuellen Anfrage geführt hat befand, als Referrer enthielt.
Und das hat er auf HTTP-Ebene gemacht - also kann da mit an Sicherheit grenzender Wahrscheinlichkeit auch kein Javascript oder PHP im Spiel gewesen sein.

Ich habe gestern das Ganze mit abgeschaltetem und angeschaltetem JavaScript getestet, es sieht tatsächlich so aus, als ob JavaScript *nicht* im Spiel ist - das Phänomen trat also in beiden Fällen auf. Allerdings nicht jedesmal, mal zeigte die Ergebnisseite des Validators die URL mit username:passwort mal ohne.

Sicher, dass der Validator das passwortgeschützte Dokument validiert hat

Ja.

Ist das Verhalten der Kombination Safari/Validator diesbezüglich reproduzierbar?

Ja, ich werde versuchen, eine Versuchsanordnung aufzubauen und den Link hier zu posten.

André

[Cybaer]

Hi,

Die Variable $_SERVER['HTTP_REFERER'] enthält das, was der Web-Server dort hineingetan hat - möglicherweise schneidet er username:passwort vorher heraus, wenn der Browser selbiges in der Referrer-URL enthält.

Dann schau doch mal in $_SERVER['HTTP_UNCUT_REFERER']!

Kleiner Scherz - niemand schneidet beim Referrer irgendwas. Außer vielleicht dein geheimer "Spezial-Proxy" ... =;-)

Gruß, Cybaer

[Skeeve]

Moin!

Meine Versuchsanordnung:
In Safaris Adresszeile eingegeben "http://hans:[e-mail]/de/"
In Ethereal capture gestartet
In Safaris Adresszeile Enter gedrückt
(nach Seitenaufbau) Ethreals capture gestoppt.

Dies sind die Informationen, die an gmx gesendet wurden:

GET /de/ HTTP/1.1
Accept: */*
Accept-Language: de-de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/418.8 (KHTML, like Gecko) Safari/419.3
Connection: keep-alive
Host: www.gmx.net

Da steht kein Username und kein Passwort.
-- Skeeve

[wahsaga]

hi,

Dies sind die Informationen, die an gmx gesendet wurden: [...]
Da steht kein Username und kein Passwort.

Nee, aber da steht auch nicht mal ein Referrer - weil der Versuchsaufbau mit

In Safaris Adresszeile eingegeben

schon von Beginn an für das hier vorliegende Szenario untauglich war.

gruß,
wahsaga

[Skeeve]

Moin!

Jetzt ist einer da. Dazu habe ich eine seite auf meinem lokalen Webserver abegelegt und diese mit Usernamen und Passwort in der URL geladen. Anschließend den link zu GMX, den ich auf die Seite gesetzt habe angeklickt. etherreal meint, daß dies hier übertragen wurde:

GET /de/ HTTP/1.1
Accept: */*
Accept-Language: de-de
Accept-Encoding: gzip, deflate
Cookie: gmxsid=babhdcg.1161252893.2302.dl5bxxefv9.73R; gii=DE
Referer: http://localhost:8080/wings/NewHTML.html
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/418.8 (KHTML, like Gecko) Safari/419.3
Connection: keep-alive
Host: www.gmx.net

Danach bin ich mit "back" zurück und habe erneut auf den Link  geklickt....

Siehe da:

GET /de/ HTTP/1.1
Accept: */*
Accept-Language: de-de
Accept-Encoding: gzip, deflate
Cookie: gmxsid=babhdfd.1161261894.12237.epmgfywnyv.77E; gii=DE
Referer: http://hans:wurst@localhost:8080/wings/NewHTML.html
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/418.8 (KHTML, like Gecko) Safari/419.3
If-Modified-Since: Thu, 19 Oct 2006 12:48:43 GMT
Connection: keep-alive
Host: www.gmx.net

Username und passwort sind vorhanden. Wenn das nicht einen Bug Entry bei Apple wert ist!?
-- Skeeve

[André]

Danach bin ich mit "back" zurück und habe erneut auf den Link  geklickt....

Siehe da:

Referer: http://hans:wurst@localhost:8080/wings/NewHTML.html

Also doch. Na immerhin ist der Fehler damit reproduziert.

Wenn das nicht einen Bug Entry bei Apple wert ist!?

Na, ich denke schon. Sicherheitsprobleme müssen aus der Welt, und seien sie noch so klein. Wo kann man das bei Apple melden?

André

[Skeeve]

Moin!

Na, ich denke schon. Sicherheitsprobleme müssen aus der Welt, und seien sie noch so klein. Wo kann man das bei Apple melden?

https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb

-- Skeeve

[André]

https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb

Die Seite will 'ne Apple ID und ein Passwort, fragt sich nur welches. Außerdem kann ich kein Englisch, schmoll.

André

[André]

Habe den Fehler eben über die Safari-Menüfunktion "Fehler an Apple melden ..." gemeldet.

André

[André]

So, ich hab das ganze Konstrukt nochmal nachgebaut und habe es jetzt durchschaut:

Wird die Validatorseite *erstmalig* aufgerufen, ist der Referrer sauber. Geht man nun mit dem "Back"-Button zurück zur aufrufenden (zu prüfenden) Seite und klickt dort den Validator-Link *erneut* an, *dann* enthält sowohl $HTTP_REFERER als auch document.referrer den Benutzernamen und das Passwort!

Safari 2.0.4 (419.3) kommt also durch das Anklicken des Back-Buttons irgendwie durcheinander. Klickt man danach den Reload-Button an, ist der Referrer beim nächsten Aufruf einer externen Seite erstmal wieder sauber - ab dem nächsten und jedem weiteren Aufruf irgendeiner verlinkten Seite (Validator oder nicht) "vergisst" Safari, Benutzernamen und Passwort aus der URL zu entfernen.

Ich hab genau dasselbe auch mit Firefox (Mac) getestet, bei dem bleibt der Referrer in *jedem* Falle sauber. Es ist also eindeutig ein Fehler des Safari - beim ersten Aufruf macht er's richtig (weiß also prinzipiell, was "sich gehört"), beim zweiten und allen weiteren vermasselt er es.

André

[Cybaer]

Hi,

Aber wie dem auch sei, das ändert nichts daran, dass ein Browser nicht mit Passwortdaten in der Gegend herumschmeißen darf.

Dann gib sie halt nicht so ein! (Shit in, Shit out ;->)

Dieses Verhalten (das Beibehalten von user:password im URL) war früher übrigens usus! So waren die "berühmten" @Domains bei Massenprovidern möglich (hier wurden diese Infos nicht für HTTP-Auth, sondern zwecks Weiterleitung auf Pseudo-Subdomains verwendet).

In diesem Sinne: ich suche einen sicheren Erkennungsmechanismus (PHP), mit dem solche Eventualitäten abgefangen werden können.

parse_url() teilt einen URL in seine Bestandteile auf - auch user:password, die in PHP in URLs generell erlaubt sind.

Gruß, Cybaer

[André]

Aber wie dem auch sei, das ändert nichts daran, dass ein Browser nicht mit Passwortdaten in der Gegend herumschmeißen darf.

Dann gib sie halt nicht so ein! (Shit in, Shit out ;->)

Puh, sachma, spreche ich chinesisch rückwärts? Ich will Shit nicht *eingeben*, sondern - falls ein Anwender es tut - ihn *abfangen*. Ganz genauso wie jedes andere halbwegs normale Programm Fehleingaben des Anwenders abfängt und angemessen darauf reagiert.

parse_url() teilt einen URL in seine Bestandteile auf - auch user:password, die in PHP in URLs generell erlaubt sind.

parse_url() erwartet die URL als Parameter. Wie ich hier nun schon zum x-ten Male schrieb, liefert *keine* der $_SERVER-Variablen die URL mit user:pass@ zurück, sodass es auch nichts zu parsen gibt.

André

[Cybaer]

Hi,

Puh, sachma, spreche ich chinesisch rückwärts? Ich will Shit nicht *eingeben*, sondern - falls ein Anwender es tut - ihn *abfangen*.

Für den gilt das Prinzip auch - ist ein allgemeingültiges Prinzip! :)

parse_url() erwartet die URL als Parameter. Wie ich hier nun schon zum x-ten Male schrieb, liefert *keine* der $_SERVER-Variablen die URL mit user:pass@ zurück, sodass es auch nichts zu parsen gibt.

Tip: Wenn Du den URL gar nicht unter PHP hast, brauchst Du auch nicht nach einer PHP-Funktion suchen. ;->

Gruß, Cy-"Hach, was sind wir heute morgen wieder lustig"-baer ;)

[wahsaga]

hi,

Wenn's um die Eingabe in der Adresszeile geht: Bequemlichkeit. Auch in einem IE-Bookmark kann ich die Zugangsdaten dann hinterlegen und damit Seiten, die HTTP-AUTH erfordern, direkt aus den Bookmarks aufrufen.

Auch der IE kann Zugangsdaten speichern.

Wenn's um die Übergabe per Link geht: Bei vielen mit HTTP-AUTH ausgestatteten Seiten dienen die Daten nur zur Erkennung des Users, ohne dass dabei irgendeine Art der Zugangskontrolle *nötig* wäre.

Da kann man auch GET-Parameter nutzen.

Gerade so wie hier im Forum, wo ja die für die /my/-Ansicht nötigen Zugangsdaten auch keine bedeutenden Daten schützen - demzufolge wäre es auch nicht weiter tragisch, wenn jemand anders sie in die Finger kriegt.

Das magst du so sehen, andere vielleicht nicht.

Und das gilt für sehr viele Sites, die entweder aus Paranoia oder aus Technophilie ein Passwort anfordern.

Oder aus anderen, guten Gründen.

gruß,
wahsaga

[Der Martin]

Hallo,

Auch der IE kann Zugangsdaten speichern.

natürlich. Aber wenn ich den dazu vorgesehenen Mechanismus nutze, sind die Daten irgendwo in den Tiefen der Registry gespeichert - also schlecht zugänglich. Speichere ich sie dagegen mit der URL im Bookmark, kann ich meine Bookmarks komfortabel von einem Rechner auf einen anderen übertragen und bin fein raus.

Wenn's um die Übergabe per Link geht: Bei vielen mit HTTP-AUTH ausgestatteten Seiten dienen die Daten nur zur Erkennung des Users, ohne dass dabei irgendeine Art der Zugangskontrolle *nötig* wäre.
Da kann man auch GET-Parameter nutzen.

Richtig. Machen aber viele Anbieter nicht (das Forum doch auch nicht).

Gerade so wie hier im Forum, wo ja die für die /my/-Ansicht nötigen Zugangsdaten auch keine bedeutenden Daten schützen - demzufolge wäre es auch nicht weiter tragisch, wenn jemand anders sie in die Finger kriegt.
Das magst du so sehen, andere vielleicht nicht.

Okay, das sei denen überlassen, wie konsequent sie ihre Zugangsdaten schützen. Ich bin jedenfalls der Überzeugung, dass es bei vielen Web-Services mit der Zugangskontrolle echt übertrieben wird. Eine Gertenlaube, in der eine rostige Schubkarre und zwei Spaten stehen, kann man auch mit einem hochmodernen Schloss mit Fingerprintscanner und Zahlenkombination abschließen. Aber ein einfacher Schieberiegel reicht auch.
Das sollte jetzt nicht heißen, dass ich den Anwendungsfall des OP für eine Bagatelle halte - den kannte ich ja noch gar nicht konkret, als ich mein erstes Posting in diesem Thread schrieb.

Und das gilt für sehr viele Sites, die entweder aus Paranoia oder aus Technophilie ein Passwort anfordern.
Oder aus anderen, guten Gründen.

Der gute Grund sollte aber immer in einem vernünftigen Verhältnis zu dem stehen, was diese Website anbietet. Drei Billig-Kugelschreiber in einen Safe einzuschließen ist einfach übertrieben.

So long,
 Martin

[Skeeve]

Moin!

So, und jetzt kommt's: Die Ergebnisseite von Validome zeigt die URL der geprüften Vorschauseite an und zwar *mit* Passwort und Benutzername. Safari übergibt diese Daten also irgendwie an die aufgerufene Validome-Webseite - ich weiß nur nicht, wie.

Sicher? Hast Du in den Seiten Source geschaut und steht das Passwort da drin, oder ist das nur ein relativer link der durch den Browser vervolständigt wird. Zeig uns doch mal Beispieldaten.

-- Skeeve