nicht angemeldet
Auth ohne Cookies,ohne Basic Auth,ohne hidden fields
Hallo,
wir rätseln schon den ganzen Vormittag über den Trick mit der Authentifizierung bei einem Forum. Cookies im Browser sind abgeschaltet.Im Quelltext stehen keine hidden fields und wir haben uns über ein "normales Formular" angemeldet.
Gibt es eine Authentifizierung ohne Cookies,ohne Basic Auth,ohne hidden fields ?
Wie kann man das realisieren ? Oder haben wir einfach etwas übersehen
Gruß Katja
-
Hi,
Gibt es eine Authentifizierung ohne Cookies,ohne Basic Auth,ohne hidden fields ?
ja, über Sessions mit URL- oder POST-Parameter.
Cheatah
--
X-Will-Answer-Email: No-
Hallo!
Gibt es eine Authentifizierung ohne Cookies,ohne Basic Auth,ohne hidden fields ?
ja, über Sessions mit URL- oder POST-Parameter.
Das sollte man dazu mal lesen:
http://www.php-faq.de/ch/ch-version4_session.html
http://www.php3.de/manual/de/ref.session.phpGrüße
Andreas-
Guten Abend,
ich habe Katja mal über die Schulter geschaut und war selber verblüfft, was es alles gibt. Natürlich habt Ihr uns alle geholfen mit den Tipps. Die hatten wir ja auch die letzte Woche schon alle mit Euch durchgekaut. Aber des Rätsels Lösung lag ganz woanders:
Der MSIE 5.5 hat nicht auf die Einstellung unter Sicherheit/Internet/Cookies reagiert und immer fleißig einen "Sessioncookie" angenommen. Den kann man ja bekanntlich in den Temporary Internet Files nicht sehen. Und da es sich um eine fremde URL handelte, konnten wir ihn auch nicht ohne weiteres am Server abfragen (Müsste doch mit einem gefakten Server eigentlich gehen, oder?)
Nachdem der PC dann irgendwann mal neu gebootet wurde, hat auch die Cookie-Einstellung wieder funktioniert und die Welt war wieder in Ordnung.
Schlussendlich hat der Tag zum Thema "saubere Athentifizierungsstrategie" noch was gebracht. Irgendwann können wir hier bestimmt auch ein bisschen mitreden *gg*
Liebe Grüße aus http://www.braunschweig.de
Tom
-
Hallo!
Der MSIE 5.5 hat nicht auf die Einstellung unter Sicherheit/Internet/Cookies reagiert und immer fleißig einen "Sessioncookie" angenommen. Den kann man ja bekanntlich in den Temporary Internet Files nicht sehen. Und da es sich um eine fremde URL handelte, konnten wir ihn auch nicht ohne weiteres am Server abfragen (Müsste doch mit einem gefakten Server eigentlich gehen, oder?)
Was ist ein "gefakter" Server? Was müßte mit einem "gefakten" Server gehen? Was kannst Du denn an einer Fremden URL nicht abfragen? Ob der Server Cookies schickt? Du kannst _ALLES_ abfragen, was per HTTP geschickt wird, und da all diese Authentifizierungsmechanismen von Internetseiten auf HTTP basieren _müssen_, damit der Browser das auch versteht, kannst Du Dir doch ganz einfach den HTTP-Traffic ansehen! Und das hatten wir ja schonmal, das was dir der Server schickt kannst Du ganz bequem mit http://www.schroepl.net/cgi-bin/http_trace.pl oder telnet mitlesen und wunderschön testen, so z.B.
Ich öffne z.B. http://forum.de.selfhtml.org/my/ ohne auth-Daten mitzusenden
http://www.schroepl.net/cgi-bin/http_trace.pl?url=http%3A%2F%2Fforum.de.selfhtml.org%2Fmy%2F&method=GET&version=HTTP%2F1.0
Da siehst Du den vollständigen Header den der teamone-Server bei einem Request eigentlich an den Browser zurücksendet. In diesem Fall halt einen 401, um den Browser aufzufordern das Auth-Fenster zu öffnen... das kennst Du ja alles. Wenn Du dasselbe aber bei Eurem Server den ich leider nicht kenne, machen würdest, dann würdest Du sehen, das da irgendein Cookie im Header steht => Geheimnis gelüftet, Untersuchungen erfolgreich abgeschlossen.Nachdem der PC dann irgendwann mal neu gebootet wurde, hat auch die Cookie-Einstellung wieder funktioniert und die Welt war wieder in Ordnung.
Ein Link zu besagtem Forum hätte sofort diese Lösung gebracht, und ein eigener Blick in den HTTP-Traffic wäre soger noch schneller gewesen ;-)
Viele Grüße
Andreas-
Hallo Andreas,
1. nur messen heißt wissen
2. wer viel misst misst Mist*ggg*
Aber natürlich hast Du recht. Wir werden das mal einrichten.
Hallo!
Der MSIE 5.5 hat nicht auf die Einstellung unter Sicherheit/Internet/Cookies reagiert und immer fleißig einen "Sessioncookie" angenommen. Den kann man ja bekanntlich in den Temporary Internet Files nicht sehen. Und da es sich um eine fremde URL handelte, konnten wir ihn auch nicht ohne weiteres am Server abfragen (Müsste doch mit einem gefakten Server eigentlich gehen, oder?)
Was ist ein "gefakter" Server? Was müßte mit einem "gefakten" Server gehen?
Ich meine damit einen, dem ich das Post oder Get oder Head schicke, so als wäre es der eigentliche Empfänger, damit der Browser auch alle Cookies mitschickt...
Ich les mir das nun nochmal durch hier und hoffe, dann demnächst sofort selbst zu sehen, wo es kneift.
Viele Grüße aus http://www.braunschweig.de
Tom
-
Hi,
Was ist ein "gefakter" Server? Was müßte mit einem "gefakten" Server gehen?
Ich meine damit einen, dem ich das Post oder Get oder Head schicke, so als wäre es der eigentliche Empfänger, damit der Browser auch alle Cookies mitschickt...es dämmert. Meinst Du im großen und ganzen einen nicht-transparenten Proxy? Also ein Script, welches aufgrund eines "realen" HTTP-Requests durch einen Browser einen selbstgenerierten HTTP-Request an einen Fremdserver abfeuert, welcher dann eigenen Richtlinien unterliegt?
Cheatah
--
X-Will-Answer-Email: No-
Hi,
Was ist ein "gefakter" Server? Was müßte mit einem "gefakten" Server gehen?
Ich meine damit einen, dem ich das Post oder Get oder Head schicke, so als wäre es der eigentliche Empfänger, damit der Browser auch alle Cookies mitschickt...es dämmert. Meinst Du im großen und ganzen einen nicht-transparenten Proxy? Also ein Script, welches aufgrund eines "realen" HTTP-Requests durch einen Browser einen selbstgenerierten HTTP-Request an einen Fremdserver abfeuert, welcher dann eigenen Richtlinien unterliegt?
fast, nur andersherum...
Ich rufe eine Seite von irgendeinem Fremdserver auf. Die Seite wird durch meinen Browser angezeigt und ich schaue nach, an wen denn die Setie wohl gepostet würde, wenn ich aufs Knöpfchen drücke.
Nur will ich die Seite ja gar nicht an den echten Server abschicken, sondern an meinen eigenen, um das Verhalten des echten zu simulieren und die Cookie-Vars und die Authdaten usw. usw. auslesen zu können. Das war nur so eine blöde Idee heute. Es gibt ja bestimmt Tools für den Proxie, die den Traffic-Inhalt mitprotokollieren und nicht nur die Aufrufe oder IPs
An Michaels Server kann ich das Script ja nicht mit der originalen Ziel-URL abfeuern. Aber nur dann gibt der Browser seine "versteckten" Cookies und z.B. die Authdaten frei. Ich habe mir die anderen Browser noch nicht angesehen. Vielleicht können die sowas ja auf Knopfdruck. Leider hat mein Tag nur 12 Stunden. Der Rest geht für lästige Verwaltung und essen, trinken, schlafen, Haushalt drauf. Da war doch noch was? Ach ja, das habe ich schon aufgegeben... Das Selfforum macht doch viel mehr Spaß *gg*
Besonders liebe Grüße aus http://www.braunschweig.de
Tom
-
Proxy klingt nach einer guten Idee. Auf dem verbiegst Du die DNS, es reicht, wenn Du auf dem Proxy die hosts einrichtest...
Mit dem eigenen Rechner geht das nicht: Die Browser merken sich die IP- Adresse, dass ist jedenfalls meine Erfahrung, ich hab eine nette lange hosts- Liste zum Werbung ausblenden, die ich immer mal ausschalten muss um Downloads zu bekommen (Microsoft macht das neuerdings über akamai)
-
Hallo!
Ich rufe eine Seite von irgendeinem Fremdserver auf. Die Seite wird durch meinen Browser angezeigt und ich schaue nach, an wen denn die Setie wohl gepostet würde, wenn ich aufs Knöpfchen drücke.
Wenn Du das wissen willst reicht ein Blick in den Quelltext!
An Michaels Server kann ich das Script ja nicht mit der originalen Ziel-URL abfeuern. Aber nur dann gibt der Browser seine "versteckten" Cookies und z.B. die Authdaten frei.
Aber der Server muß ja am Anfang ein set-cookie schicken, das kannst Du auf alle Fälle schonmal sehen. Wenn Du genau wissen willst was Du an den speziellen Server sendest, dann brauchst Du einen (Netzwerk-)Sniffer(heißen glaub ich so), die Deinen TCP/IP Traffic belauschen und protokollieren. Das habe ich schon mehrfach erfolgreich verwendet, um HTTP zu verstehen. Oder Du machst das manuell mit Telnet, oder mit einem erweiterten "http_trace.pl", wo Du den gesendeten Request noch manipulieren kannst (wäre eh ein nettes Feature ;-)). Ich bin gerade nicht sicher ob man das nicht auch in PHP machen könnte, denn da hat man ja keinen Zugriff auf den direkten HTTP-Request des Browsers, aber eigentlich müßte alles wichtige in den Umgebungsvariablen stehen... mal schauen.
Und ob das mit einem "Fake-Server" funktioniert wage ich zu bezweifeln, denn dein Browser wird den Teufel tun Cookies von dem "echten Server" an einen "Fake-Server" zu senden! Auch wenn das kein Thema mehr ist, wie lautet denn die URL zu dem Forum, dann kann man sich evtl. mal ein Bild machen und sagen wie ich das machen würde!
Grüße
AndreasPS: ich selbst verwende übrigens http://www.sniff-em.com, keine Ahnung ob das gut oder schlecht ist, aber es loggt HTTP, mehr brauche ich nicht!
-
Hi Andreas,
Und ob das mit einem "Fake-Server" funktioniert
wage ich zu bezweifeln, denn dein Browser wird den
Teufel tun Cookies von dem "echten Server" an einen
"Fake-Server" zu senden!Das kommt darauf an, wie der Fake-Server funktioniert.
Was der dafür tun müßte, das wäre, die Cookies so um-
zuschreiben (!), daß
a) sie an ihn wieder zurück gesendet werden und
b) er aus ihnen wieder die Original-Cookies her-
stellen kann.
Außerdem werden dann natürlich sämtliche Cookies von
Seiten, die getraced wurden, an den Proxy gesendet.
Dieser muß also diejenigen herausfinden, die er durch-
reichen soll, wenn er intelligent arbeiten will.Mein Trace-Skript könnte das auch tun, aber es geht
nicht davon aus, daß es für eine komplette Session
verwendet wird. Es macht ja auch keine Sub-Requests
für Bilder, weil es dafür HTML parsen müßte usw.Wenn Du allerdings im Apache via mod_proxy einen frem-
den Server in den URL-Raum Deines Servers einbindest,
dann macht mod_proxy genau das, was ich oben beschrie-
ben habe. Deshalb funktionieren bei dieser Einbindung
auch Anwendungen auf Cookie-Basis, obwohl sie unter
einem "falschen" DNS-Namen angesprochen werden.Ein "reverse proxy" muß eben in _beide_ Richtungen den
kompletten HTTP-Traffic übersetzen, nicht nur in eine.Auch ein Surf-Anonymizer muß auf diese Weise arbeiten,
wenn er Cookies unterstützen will.Viele Grüße
Michael-
Hallo Michael, Halle Andreas,
Und ob das mit einem "Fake-Server" funktioniert
wage ich zu bezweifeln, denn dein Browser wird den
Teufel tun Cookies von dem "echten Server" an einen
"Fake-Server" zu senden!Den hätte ich so eingestellt, dass er den gleichen Namen und die gleiche IP bekommt, wie die Origianl Domain. Dann muss man eben mal umstecken...
Wird nur auf der ARP-Ebene kurz für Verwirrung sorgen. Davon sollte doch aber HTTP nix mitbekommen, oder?Das kommt darauf an, wie der Fake-Server funktioniert.
Was der dafür tun müßte, das wäre, die Cookies so um-
zuschreiben (!), daß
a) sie an ihn wieder zurück gesendet werden und
b) er aus ihnen wieder die Original-Cookies her-
stellen kann.
Außerdem werden dann natürlich sämtliche Cookies von
Seiten, die getraced wurden, an den Proxy gesendet.
Dieser muß also diejenigen herausfinden, die er durch-
reichen soll, wenn er intelligent arbeiten will.Mein Trace-Skript könnte das auch tun, aber es geht
nicht davon aus, daß es für eine komplette Session
verwendet wird. Es macht ja auch keine Sub-Requests
für Bilder, weil es dafür HTML parsen müßte usw.Wenn Du allerdings im Apache via mod_proxy einen frem-
den Server in den URL-Raum Deines Servers einbindest,
dann macht mod_proxy genau das, was ich oben beschrie-
ben habe. Deshalb funktionieren bei dieser Einbindung
auch Anwendungen auf Cookie-Basis, obwohl sie unter
einem "falschen" DNS-Namen angesprochen werden.Ein "reverse proxy" muß eben in _beide_ Richtungen den
kompletten HTTP-Traffic übersetzen, nicht nur in eine.Auch ein Surf-Anonymizer muß auf diese Weise arbeiten,
wenn er Cookies unterstützen will.Wenn Ihr für Dieses Thema nochmal etwas Zeit habt, würde ich die Diskussion gerne fortsetzen. Im Moment drängeln aber viele andere Probleme. Bei dem besagten Forum haben wir durch viel Denken, Whiteboard beschmieren und Zettelspiele die gewünschten Vorgänge analysiert. Es ging um ein intelligentes Anmeldeverfahren.
Übrigens zeigt der Netscape 7 auch die Speicher-Cookies an in seiner Cookieverwaltung. Das hat uns geholfen.
Liebe Grüße aus http://www.braunschweig.de
Tom
-
-
-
-
-
-
-
-
-
Hallo,
Gibt es eine Authentifizierung ohne Cookies,ohne Basic Auth,ohne hidden fields ?
ja, über Sessions mit URL- oder POST-Parameter.
wo sollen denn die Session ID gespeichert sein ?
Wir haben untersucht und nichts gefunden:
- Cookies
- Get Variablen (kein Anhang an der URL vorhanden)
- Post Variablen (hidden fields in Formularen)
- Anmeldeformular ist ein normales Formular, also kein Basic Auth 401
das heisst der Browser muss trotzdem in der Lage sein, einen Authentifzierungscode zwischenzuspeichern
Gruß Katja
-
Hi,
ja, über Sessions mit URL- oder POST-Parameter.
wo sollen denn die Session ID gespeichert sein ?clientseitig in URL- oder POST-Parametern, serverseitig in einem Session-System, welches bei PHP mitgeliefert wird.
Wir haben untersucht und nichts gefunden:
Überprüfe die Konfiguration von PHP, und ob das Session-Management richtig angewendet wird.
Cheatah
--
X-Will-Answer-Email: No -
Hi Katja,
Wir haben untersucht und nichts gefunden:
- Cookies
- Get Variablen (kein Anhang an der URL vorhanden)
Die können (beim Apache mittels mod_rewrite) auch mitten in der URL stehen. ( http://any.url.de/seite1/qwepkdmjn23837ej/index.htm)
- Post Variablen (hidden fields in Formularen)
- Anmeldeformular ist ein normales Formular, also kein Basic Auth 401
das heisst der Browser muss trotzdem in der Lage sein, einen Authentifzierungscode zwischenzuspeichern
Nein, denn mehr Methoden gibt es nicht. Ihr müsst was übersehen haben (Frameset drumrum?) oder die Authentifizierung 'mogelt'. (z.B. IP basiert.)
Gruss,
Carsten-
Hallo Carsten,
vielen Dank, das mod_rewrite ist eine sehr gute Anregung,das hatten wir noch nicht weiter untersucht, jedoch kommt es in diesem Fall nicht vor.
Mit der IP kann nicht gearbeitet werden, weil wir hier z.B. hinter einen Proxie mit NAT sitzen.Nein, denn mehr Methoden gibt es nicht. Ihr müsst was übersehen haben (Frameset drumrum?) oder die Authentifizierung 'mogelt'. (z.B. IP basiert.)
Es _muss_ noch ein Geheimnis geben !
Katja
-
Hallo Katja,
Es _muss_ noch ein Geheimnis geben !
Gibt es nicht. Wie waere es, wenn du mal die URL bekannt gibst?
Gruesse,
CK -
Hallo!
Es _muss_ noch ein Geheimnis geben !
Solche Geheimnisse werden hier: http://www.dclp-faq.de/ch/ch-version4_session.html sehr breitwillig preisgegeben, vielleicht solltet Ihr die Seite einfach mal in Eure "Untersuchungen" miteinbeziehen!
Grüße
Andreas -
Hi Katja,
Mit der IP kann nicht gearbeitet werden, weil wir hier z.B. hinter einen Proxie mit NAT sitzen.
Das verhindert ja nicht, dass die IP zur Identifizierung verwendet werden kann, es gibt erst dann Ärger wenn das mehrere Browser gleichzeitig tun. Ausserdem kann man ja (fast) den gesammten http-request zu einem 'Client-Fingerprint' zusammenfassen und darüber identifizieren.
Richtig funktionieren tut sowas natürlich nicht, kann aber erstmal verblüffend lange so tun als ob.Gruss,
Carsten-
Hi,
Richtig funktionieren tut sowas natürlich nicht, kann aber erstmal verblüffend lange so tun als ob.
*brüll* Dieser Satz ist verdammt vielseitig anwendbar :-)))
You made my day,
Cheatah
--
X-Will-Answer-Email: No
-
-
-