nicht angemeldet
401-Response nach jedem Request, auch nach Authentifzierung?
Hallo!
Ich habe mir gerade mal eine Webalizer-Statistik eines neuen Projektes angesehen, und da habe ich festgestellt, dass ungewähnlich viele 401-Header gesendet werden, fast genausoviele wie 200er! Dann habe ích mir das ganze mal mit ethereal angesehen, und das komische, mein Browser(Mozilla 1.5a) sendet bei jedem neuen Requst keine Auth-Daten mit, dann kommt jedesmal ein 401-Response und erst dann sendet er automatisch die Daten mit. Man merkt davon nichts, aber eigentlich hatte ich gedacht dass das gerade so nicht ablaufen soll, sondern dass der Browser allen Requests die in oder unter dem Verzeichnes von dem aus der erste 401-Response gesendet wurde, die HTTP-Auth Daten mitschicken soll. Also habe ich mal im entsprechenden RFC(http://www.ietf.org/rfc/rfc2617.txt) nachgesehen:
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Gut, da steht "SHOULD" und "MAY", aber die Sache ist ja die, dass Mozilla durchaus die Daten ohne neue Passwort-Eingabe sendet, aber eben nicht automatisch sondern erst nachdem er es erstmal ohne versucht hat. Der IE beispielsweise macht das nicht!
Ist das wohl gewollt oder mache ich irgendwo was falsch?
Viele Grüße
Andreas
-
Hi Andreas,
Ist das wohl gewollt oder mache ich irgendwo was falsch?
aus Performance-Sicht teile ich Deine Sichtweise.
Man müßte vielleicht mal die Mozilla-Group fragen, ob das ein bug ist oder ob es security-Aspekte gibt, die gegen das präventive Senden der Credentials sprechen könnten.
SHOULD ist in RFC2616 normalerweise eine ziemlich starke Aufforderung; leider finde ich gerade die Stelle nicht, die ich in Erinnerung habe und die aussagt, wie der Grad der "compliancy" von der Unterstützung sämtlicher SHOULD (bzw. der Dokumentation absichtlicher Nicht-Unterstützung) abhängt ...
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi,
Man müßte vielleicht mal die Mozilla-Group fragen, ob das ein bug ist oder ob es security-Aspekte gibt, die gegen das präventive Senden der Credentials sprechen könnten.
ja.
SHOULD ist in RFC2616 normalerweise eine ziemlich starke Aufforderung; leider finde ich gerade die Stelle nicht, die ich in Erinnerung habe und die aussagt, wie der Grad der "compliancy" von der Unterstützung sämtlicher SHOULD (bzw. der Dokumentation absichtlicher Nicht-Unterstützung) abhängt ...
http://www.ietf.org/rfc/rfc2119.txt
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo Cheatah,
ich meinte eher eine Stelle wie
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.2
(die ja den RFC 2119 auch referenziert), die aber nur zwischen "unconditionally" und "conditionally" unterscheidet ... und ich dachte, da gäbe es noch eine weitere Abstufung.Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi,
ich meinte eher eine Stelle wie
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.2
(die ja den RFC 2119 auch referenziert), die aber nur zwischen "unconditionally" und "conditionally" unterscheidet ... und ich dachte, da gäbe es noch eine weitere Abstufung.ach so. Nein, da ist mir leider nichts bekannt, sorry.
Cheatah
--
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes
-
-
-
Hi Michael!
aus Performance-Sicht teile ich Deine Sichtweise.
Das Problem ist ja, das nicht nur mehr Requests anfallen, mehr Traffic... sondern dass jedesmal explizit einmal um sonst auf die Antwort gewartet werden muss.
Man müßte vielleicht mal die Mozilla-Group fragen, ob das ein bug ist oder ob es security-Aspekte gibt, die gegen das präventive Senden der Credentials sprechen könnten.
Ich vermute fast dass die sich was dabei gedacht haben, da sie ja implementiert haben dass keine neue Nachfrage kommt. Es könnte den Grund haben, dass man evtl. nicht nur Verzeichnisse, sondern auch Dateien schützen kann. Nur habe ich diese Möglichkeit nirgendwo finden können, aber auch keine Stelle wo dem explizit widersprochen wurde, IMHO wurde auch von "Recource" gesprochen, das könnte ja auch eine Datei sein. Jedenfalls geht das im Apachen nur Verzeichnisweise.
Ein anderer interessanter Punkt:
Ich war immer davon ausgegangen dass man die Authentifzierung nur für _einen_ Server einsetzen kann. Heißt also dass es im HTTP-Protokoll keine Möglichkeit gibt, dass ich mich einmal auf forum.de.selfhtml.org/my/ einlogge, und ohne erneute Passworteingabe mich unter cforum.teamone.de/forum/my/ authentifzieren kann. Aber jetzt steht im oben genannten RFC folgender Satz:
Unless otherwise defined by the authentication scheme, a single
protection space cannot extend outside the scope of its server.Heißt dass jetzt im Umkehrschluss, dass man über das "authentication scheme" einem Client auch sagen kann dass er die Auth-Daten ebenfalls zu einem anderen Server senden soll? Also dass es doch die Möglichkeit gibt sich mit nur einem Login-Vorgang unter 2 Subdomains zu authentifizieren? Oder habe ich das falsch verstanden?
Viele Grüße
Andreas-
Hallo Andreas,
Heißt dass jetzt im Umkehrschluss, dass man über das "authentication scheme" einem Client auch sagen kann dass er die Auth-Daten ebenfalls zu einem anderen Server senden soll?
Ja.
Also dass es doch die Möglichkeit gibt sich mit nur einem Login-Vorgang unter 2 Subdomains zu authentifizieren?
Ja. Überlege Dir, wie ein solcher Standard aussehen könnte und schicke Deinen Vorschlag der IETF. Vielleicht wird es ja ein RFC.
Allerdings: nachdem der IE noch nicht mal Digest Authentication richtig unterstützt, glaube ich nicht, dass sich Dein Vorschlag durchsetzen wird. (selbst wenn es mal ein RFC _würde_) Im Moment kann man außerhalb kontrollierter Umgebungen nur Basic Authentication fahren.
Viele Grüße,
Christian--
Glaube niemals dem Gelabber der Forums-Antworten. Das sind doch Minderheiten-Diskriminierer, Sexisten, Psychisch Kranke und Depressive.
Ja auch Rassisten und ähnliche Sozialrowdies befinden sich da drunter. - </archiv/2003/8/54855/#m305505>-
Hi Christian,
Allerdings: nachdem der IE noch nicht mal Digest Authentication richtig unterstützt,
oh - was genau kann er denn nicht?
Ich habe hier ein Test-Verzeichnis mit "AuthType Digest" geschützt, und die einzigen Browser, die dabei versagen, sind Netscapes unterhalb von Mozilla 0.9.7. - selbst M$IE 5.0 macht, was ich ich von ihm erwarte. (Opera funktioniert ab etwa 4.0, glaube ich mich zu erinnern.)
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Moin,
oh - was genau kann er denn nicht?
Zum Beispiel Digest Access Authentication nach RFC 2069, also ohne qop, was in RFC 2617 audrücklich aus Abwärtskompatibilitätsgründen noch zugelassen wird. Auf den Apache bezogen bedeutet das dass man zwingend mod_auth_digest statt mod_digest benutzen muß. Wenn man das nicht tut sendet der IE zweimal(!) einen Request ohne Authorisierungsinformationen, bekommt beide male einen 401 und zeigt dann die Standard-Nichtssagende-Fehlerseite an auf der er versucht seine Unfähigkeit auf ein Server- oder Netzproblem zu schieben.
Ausserdem können die Entwickler nicht lesen und selbst die RFC 2617-Unterstützung ist defekt: Es muß nämlich der URI so wie er in der Request-Zeile erscheint im Response-Hash verwendet und - weil Proxies ihn unter Umständen verändern dürfen - eine Kopie davon in den uri-Wert des WWW-Authenticate-Headers kopiert werden. Der IE kopiert aber nicht den ganzen URI sondern nur den Teil bis vor den Query-Part. Ein funktionierender Server (wie der Apache) lehnt den Request dann natürlich ab. Selbst wenn man den Server kaputt machen würde damit er den Request akzeptiert, würde das eine Sicherheitslücke bedeuten, da (konstruiertes Beispiel) /cgi-bin/admin.pl?action=show sicherlich etwas anderes bedeutet als /cgi-bin/admin.pl?action=deleteeverything, der IE aber für beides den selben Response-Wert berechnet.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
-
-
-
-
-
Hallo,
das umgekehrte Problem wurde vor ein paar Tagen in dciws in bhaam1$100e97$1@ID-113901.news.uni-berlin.de angesprochen.
Angeblich sendet der Internet Explorer 6 und Opera 6 Benutzernamen und Passwort auch an andere Domains. Mit Opera 6.05 und Internet Explorer 5 konnte ich es allerdings nicht nachvollziehen.
Hat das schonmal jemand (evtl. auch mit einem anderen Browser) festgestellt? IMO wäre das eine große Sicherheitslücke, schließlich hat der Betreiber der verlinkten Seite dann Benutzernamen, Passwort und aus dem Referrer die URL.
Möglicherweise ist die Beobachtung von Markus in dciws auch falsch; per Mail hat er mir geschrieben, dass er zwei gleiche Dateien (phpinfo.php) für den Test verwendete (und die ihm Benutzernamen und Passwort anzeigten). Möglicherweise war eine Seite ja noch im Cache oder einem Proxy.
Gruß,
Christian-
Hallo Christian,
Hat das schonmal jemand (evtl. auch mit einem anderen Browser) festgestellt?
Nein. Ich kann jetzt im Moment zwar nicht mit dem IE testen, allerdings würde mich es _selbst_ beim IE _sehr_ wundern, wenn dem so wäre.
Möglicherweise ist die Beobachtung von Markus in dciws auch falsch;
Entweder das, oder er hat (unwissentlich) durch die Art des Experimentierens das Ergebnis beeinflusst. Ich kann es hier bei mir (mit Ethereal nachgemessen) weder bei Lynx 2.8.4rel.1, Netscape 4.77, Opera 6.12, Opera 7.11, Mozilla 1.3.1 noch bei Konqueror 3.1.2 nachvollziehen und beim IE kann ich es mir wie gesagt eigentlich auch nicht vorstellen. (auch wenn ich dem IE HTTP-mäßig sonst so einiges zutraue)
Viele Grüße,
Christian--
Glaube niemals dem Gelabber der Forums-Antworten. Das sind doch Minderheiten-Diskriminierer, Sexisten, Psychisch Kranke und Depressive.
Ja auch Rassisten und ähnliche Sozialrowdies befinden sich da drunter. - </archiv/2003/8/54855/#m305505>-
Hallo Christian,
Entweder das, oder er hat (unwissentlich) durch die Art des Experimentierens das Ergebnis beeinflusst. Ich kann es hier bei mir (mit Ethereal nachgemessen) weder bei Lynx 2.8.4rel.1, Netscape 4.77, Opera 6.12, Opera 7.11, Mozilla 1.3.1 noch bei Konqueror 3.1.2 nachvollziehen und beim IE kann ich es mir wie gesagt eigentlich auch nicht vorstellen. (auch wenn ich dem IE HTTP-mäßig sonst so einiges zutraue)
Danke für den Test. Ich gehe auch davon aus, dass das eigentlich nicht sein dürfte und es selbst der IE nicht macht.
Gruß,
Christian
-
-
Hi Christian,
Angeblich sendet der Internet Explorer 6 und Opera 6 Benutzernamen und Passwort auch an andere Domains.
wann? Wenn diese eine Authentication verlangen, oder etwa immer?
Letzteres könntest Du mit http://forum.de.selfhtml.org/cgi-bin/http_trace.pl überprüfen, nachdem Du Dich auf einem anderen Server erfolgreich authentifiziert hast.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hallo Michael,
Angeblich sendet der Internet Explorer 6 und Opera 6 Benutzernamen und Passwort auch an andere Domains.
wann? Wenn diese eine Authentication verlangen, oder etwa immer?
wie gesagt, ich habe nur eine andere Nachricht wiedergegeben, aber so wie ich es verstanden habe: immer.
Letzteres könntest Du mit http://forum.de.selfhtml.org/cgi-bin/http_trace.pl überprüfen, nachdem Du Dich auf einem anderen Server erfolgreich authentifiziert hast.
Ich habe es schon mit Hilfe Apache's access.log getestet, aber es wurde kein Benutzername oder Passwort übertragen.
Gruß,
Christian
-
-