Hallo!
Ich habe bei meinem Browser eingestellt, dass, sobald er geschlossen wird, alle Sitzungsdaten (Cache, History, Kekse etc) gelöscht werden. Jetzt ist es allerdings ziemlich müßig sich immerwieder im Forum anzumelden und offen lassen will ich den Browser auch nicht die ganze Zeit.
Ist es eventuell möglich, dass man sich z.B. mit folgendem Aufruf automatisch anmelden kann [source]http://www.delphi-forum.de/login.php?user="Alstar"?password="(cipheredpassword)"[/source]?

Bis dann,
Alstar

Parameterübergabe per GET birgt Gefahren.

Und welche? Es ist mir schon klar, dass diese Daten mitgelesen werden können, aber dewegen möchte ich ja nur die Prüfsumme des Passwortes übergeben.

Alstar

Es birgt nicht nur die Gefahr des Mitlesens (die übrigens bei POST auch besteht) sondern sie ermöglicht die leichte Manipulation von Werteübergaben. Manuelle Erzeugung von POST-Werten ist erheblich schwerer.
Das Mitlesen könnte man einfach durch Einsatz von SSL umgehen.

mkinzler hat folgendes geschrieben:

[...] sondern sie ermöglicht die leichte Manipulation von Werteübergaben. [...]

Was meinst Du damit? Das Dritte die Werte leichter manipulieren könnten? Welche Gefahren würden für das Anmelden bestehen?

Alstar

es ist erheblich einfacher ein &name=... an eine URL anzuhängen als einen POST-Array zu manipulieren.

Was genau wäre das Problem?

Alstar

Das man deinen Acc leichter hacken kann?!

Anschaulich erklärt auf:
de.wikipedia.org/wik....A4nderung_von_Daten

Ich wusste, da war doch was
Ne mal ehrlich. Das kann man auch, wenn man die "normale" Loginanfrage abfängt, oder?

Alstar

Hab meinen Post nochmal editiert und den Artikel von Wikipedia angehängt. Dort ist anschaulich erklärt, wie per GET (aber auch per POST*) die Datenbank verändert werden kann.

*Geht auch bei einem normalen Login, hier kann aber ganz anders auf Hacking überprüft werden.

mkinzler hat folgendes geschrieben:

Manuelle Erzeugung von POST-Werten ist erheblich schwerer.

Unsinn, POST ist nicht sonderlich komplexer oder anders als GET wenn man ein Angreifer ist. POST stellt allenfalls für ein Scriptkiddie eine Hürde dar, das Google nicht richtig bedienen kann.
Wenn der Sicherheitsseite her betrachtet gibt es nur einen einzigen Unterschied: GET taucht in jedem Log auf, bei Proxies und bei Servern. Somit könnte jeder, der Zugriff zu passenden Logs hat, gültige Username/Password-Kombinationen herausfinden und sich über die einloggen.
POST sollte beim Login aus dem Grund verwendet werden, weil es der Standard ausdrücklich empfiehlt. Alstar sollte vielleicht seinen Browser reparieren, wenn dieser die Cookies jedes Mal vergisst.

mkinzler hat folgendes geschrieben:

Das Mitlesen könnte man einfach durch Einsatz von SSL umgehen.

Das wird hier nicht gemacht, ist also weder ein Argument für das eine, noch das andere.

Wow. So viele Halb- bis Unwahrheiten in einem Thread Oo. GET gibts nicht. GET ist ein ganz normaler HTTP Request, PHP hat das Array für den geparsten query string einfach GET genannt. Im Grunde ist nach dem Fragezeichen in der URL das gleiche zu sehen wie das, was dein Webserver im POST Modus an den Webserver überträgt. Der einzige Grund der gegen GET spricht ist, dass die URL (mit usernamen und passwort) im Logfile des Webservers und zwischengeschalteter Proxies auftaucht.
Auszusniffen ist GET und POST genau gleich schwer.

Wenn man das wirklich machen wolle müsste man vom Server auf irgendeine Weise einen salt anfordern, mit diesen lokal den Passwort Hash nochmal hashen und wieder zurückschicken. Der Server nutzt den salt um das am Server nochmal zu machen und logged den User im Erfolgsfall ein. Danach trägt er den Salt in eine Blacklist ein, dass er nicht mehr verwendet wird.

Aber das ist ein unnötiger Aufwand und kann erst recht nicht gebookmarkt werden. Da nimmt man dann gleich SSL

Zitat:

Auszusniffen ist GET und POST genau gleich schwer.

Wurde auch nicht behauptet.

Zitat:

Das wird hier nicht gemacht, ist also weder ein Argument für das eine, noch das andere.

Deshalb hab ich geschrieben das man die durch SSL verhindern kann.

blackbirdXXX hat folgendes geschrieben:

GET gibts nicht.

So?

blackbirdXXX hat folgendes geschrieben:

GET ist ein ganz normaler HTTP Request

Das ist POST auch. Also gibt es GET doch? Ich dachte "GET gibts nicht." GET ist ein definierter Mechanismus, auch um Parameter an den Server zu übermitteln, allerdings für Daten, die am Status der Session nichts ändern und auch sonst keinen Einfluss auf irgendetwas haben. Die Verwendung von GET als Parameter für die Topic-ID ist beispielsweise vollkommen in Ordnung und "intended use".

blackbirdXXX hat folgendes geschrieben:

Wenn man das wirklich machen wolle müsste man vom Server auf irgendeine Weise einen salt anfordern, mit diesen lokal den Passwort Hash nochmal hashen und wieder zurückschicken.

Warum das? Das würde verhindern, daß ich den Link in meine Bookmarks legen kann, wie du schon erkannt hast, aber eine Attacke würde es trotzdem nicht verhindern. Ein Angriff würde allerdings auch nicht durch POST- oder Cookie-Übertragung erschwert oder gar verhindert werden.

Aber gut, daß du meinen Beitrag nach knapp 'ner Stunde nochmal wiederholt hast, man kann nicht oft genug sagen, daß Anmeldeverfahren wie das auf dieser Seite verwendete nicht sicher sind und man sich nicht darauf verlassen sollte, daß das eigene Passwort unter keinen Umständen in fremde Hände gelangen kann.

tommie-lie hat folgendes geschrieben:

blackbirdXXX hat folgendes geschrieben: GET gibts nicht. So? blackbirdXXX hat folgendes geschrieben: GET ist ein ganz normaler HTTP Request Das ist POST auch. Also gibt es GET doch? Ich dachte "GET gibts nicht." GET ist ein definierter Mechanismus, auch um Parameter an den Server zu übermitteln, allerdings für Daten, die am Status der Session nichts ändern und auch sonst keinen Einfluss auf irgendetwas haben. Die Verwendung von GET als Parameter für die Topic-ID ist beispielsweise vollkommen in Ordnung und "intended use".

Das meinte ich auch. GET und POST (genauso wie HEAD, PUT, DELETE) sind Methoden zur Kommunikation mit dem Webserver. Wobei aber nur PUT und POST dafür ausgelegt sind Daten auf dern Server zu übermitteln.
Ich reagiere nur etwas allergisch darauf, wenn manche Leute alles mit GET übertragen wollen...

tommie-lie hat folgendes geschrieben:

Aber gut, daß du meinen Beitrag nach knapp 'ner Stunde nochmal wiederholt hast, man kann nicht oft genug sagen, daß Anmeldeverfahren wie das auf dieser Seite verwendete nicht sicher sind und man sich nicht darauf verlassen sollte, daß das eigene Passwort unter keinen Umständen in fremde Hände gelangen kann.

Sorry, Ich hab erst gar nicht so weit gelesen, ich hab nach den ersten sechs Posts übersprungen

//EDIT:

tommie-lie hat folgendes geschrieben:

Warum das? Das würde verhindern, daß ich den Link in meine Bookmarks legen kann, wie du schon erkannt hast, aber eine Attacke würde es trotzdem nicht verhindern. Ein Angriff würde allerdings auch nicht durch POST- oder Cookie-Übertragung erschwert oder gar verhindert werden.

Erschwert würde es auf alle Fälle sein. Weil die Logindaten nach der ersten Verwendung ungültig werden müsste derjenige, der die Kommunikation belauscht das vom Server ausgestellte Cookie angegen nehmen und mir eine Fehlerseite unterjubeln. Sofern der Server dann nicht die IP kontrolliert ist er als ich eingeloggt. An mein Passwort kommt er allerdings so nicht und für spätere Loginversuche kann ers auch nicht nutzen weil der salt dann in einer Blacklist ist und vom Server nicht mehr akzeptiert werden würde.

blackbirdXXX hat folgendes geschrieben:

Das meinte ich auch. GET und POST (genauso wie HEAD, PUT, DELETE) sind Methoden zur Kommunikation mit dem Webserver. Wobei aber nur PUT und POST dafür ausgelegt sind Daten auf dern Server zu übermitteln.

PUT (und DELETE) einklich auch
Aber GET und POST besorgen auch den Content wieder.

blackbirdXXX hat folgendes geschrieben:

Erschwert würde es auf alle Fälle sein. Weil die Logindaten nach der ersten Verwendung ungültig werden müsste derjenige, der die Kommunikation belauscht das vom Server ausgestellte Cookie angegen nehmen und mir eine Fehlerseite unterjubeln.

Oder er müsste einfach schneller sein, was nicht so das Problem ist.
Nach dem (automatisch, da schneller) erfolgten Login ändert der Angreifer das Passwort und kann sich in Zukunft seine Hashs für den GET-Parameter selber zusammensetzen und hat gleich noch das Opfer ausgesperrt.
[Edit]Und da PHP nicht thread-safe ist und zwischen den Anfragen nur wenige millisekunden vergehen dürften, könnten sogar beide Logins erfolgreich sein und das Opfer nicht sofort etwas merken, sondern erst beim nächsten Login.[/Edit]

blackbirdXXX hat folgendes geschrieben:

Sofern der Server dann nicht die IP kontrolliert ist er als ich eingeloggt.

IP-Spoofing ist nicht wirklich eine Herausforderung, denke ich

Rein technisch wäre es sicherlich recht einfach, die Login-Page für GET zu erweitern, ich bin aber, wie auch viele andere hier im Thread dagegen, weil es zu viele Sicherheitsrisiken birgt.

Ferner hab ich grad mal was ausprobiert (WebDev --> Forms --> POST2GET) und kann sagen: Das Forum nimmt solche Logins NICHT an, was ich auch gut so finde. (Man bekommt ne Fehlermeldunge, dass man nen falschen Usernamen angegeben hat ... gut, sollte man ggf. so abfangen: Bei leerem Username gelangt man direkt zur Login-Page zurück ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.