Was heißt hier "intelligent programmieren"? -> GET und POST

[Structed]

In dem Artikel zum auslesen von GET und POST-Umgebungsvariablen mit CGI (siehe Link unten) ist mir die Formulierung schwer aufgestoßen:
Hier heißt es mehrfach, dass man seine Skripte so "intelligent" programmieren könne, dass es egal sei, welche Action-Methode man beim Aufruf eines Fomulars benutzt. Es würde wohl kaum Sinn machen, seine Skripte so zu schreiben. Denn wenn es egal wäre, welche Methode man benutzt, würde es wohl auch nicht zwei so grundverschiedene Methoden geben. Außerdem stellt die Verwendung von GET für manche Anwendungen ein nicht unerhebliches Sicherheitsrisiko dar.

ich halte es also in den meißten Fällen für besonders Unintelliegnt, seine Skripte so zu schreiben. Ich würde mich also sehr über eine Ändreung des Artikels und einn Hinweis auf die Unterschiede der beiden Methoden freuen.

[Horst]

Hallo,

Außerdem stellt die Verwendung von GET für manche Anwendungen ein nicht unerhebliches Sicherheitsrisiko dar.

Wo hast Du denn das her?

Viele Grüße,
Horst

[Siechfred]

In dem Artikel zum auslesen von GET und POST-Umgebungsvariablen mit CGI (siehe Link unten) ist mir die Formulierung schwer aufgestoßen:

Weil Du sie - wie mir scheint - falsch verstanden hast.

Hier heißt es mehrfach, dass man seine Skripte so "intelligent" programmieren könne, dass es egal sei, welche Action-Methode man beim Aufruf eines Fomulars benutzt.

Es heißt:
"Wenn Sie ein vorhandenes CGI-Script einsetzen wollen, müssen Sie wissen, nach welcher der beiden Methoden das betreffende Script die Daten erwartet. Normalerweise ist das vom Autor des CGI-Scripts dokumentiert. Einige Scripts sind auch so intelligent, beide Möglichkeiten abzufragen - in diesem Fall ist es egal, welche Anfragemethode Sie im HTML-Formular wählen. Wenn Sie eigene Scripts schreiben, müssen Sie eine Anfragemethode festlegen oder ebenfalls so intelligent programmieren, dass es egal ist, welche Methode im HTML-Formular angegeben wird."

Es ist ein himmelweiter Unterschied, wie die empfangenen Daten den Scripten vom Server bereitgestellt werden. POST-Daten kommen via STDIN im Script an, GET-Daten via Umgebungsvariablen. Einem "intelligenten" Script ist es egal, ob es POST oder GET bekommt, denn es kann mit beiden umgehen. So ist es zu verstehen, wenngleich man das "intelligent" durchaus falsch verstehen könnte.

Denn wenn es egal wäre, welche Methode man benutzt, würde es wohl auch nicht zwei so grundverschiedene Methoden geben.

Es gibt eine ganze Menge von Anwendungsfällen, wo die Methode tatsächlich völlig egal ist. Ob die Daten an einen Formmailer via GET oder via POST übertragen werden, ist abgesehen von Einschränkungen beim Umfang der übertragenen Daten schnurz.

Außerdem stellt die Verwendung von GET für manche Anwendungen ein nicht unerhebliches Sicherheitsrisiko dar.

Aha, welche(s) denn?

ich halte es also in den meißten Fällen für besonders Unintelliegnt, seine Skripte so zu schreiben. Ich würde mich also sehr über eine Ändreung des Artikels und einn Hinweis auf die Unterschiede der beiden Methoden freuen.

Tut mir Leid, ich kann Deine Kritik nicht nachvollziehen. Entweder ein Script dokumentiert, dass es nur GET oder nur POST annimmt, oder es ist so programmiert, dass es beide Übertragungsmethoden entgegennehmen kann. Ob für letzteres die Vokabel "intelligent" zutreffend ist, mag ich nicht beurteilen :)

Siechfred

[Cheatah]

Hi,

Außerdem stellt die Verwendung von GET für manche Anwendungen ein nicht unerhebliches Sicherheitsrisiko dar.
Aha, welche(s) denn?

ich wollte meine Antwort eigentlich auf ein Wort beschränken, aber das könnte falsch verstanden werden. Daher sage ich einfach, dass ich meine Antwort auf ein Wort beschränke: Passwort.

Cheatah

[Siechfred]

Außerdem stellt die Verwendung von GET für manche Anwendungen ein nicht unerhebliches Sicherheitsrisiko dar.
Aha, welche(s) denn?
ich wollte meine Antwort eigentlich auf ein Wort beschränken, aber das könnte falsch verstanden werden.

Klingt nach "Das Format Ihres Postings scheint unsauber zu sein" ;)

Passwort.

Ein im Body einer HTTP-Anfrage versandtes Passwort ist auch "nur" Plaintext, ebenso wie innerhalb eines Querystrings. Also ist das ungesicherte Versenden eines Passwortes - egal ob POST oder GET - doch immer ein Sicherheitsrisiko, oder bin ich da völlig auf dem Holzweg?

Siechfred

[Harlequin]

Yerf!

Ein im Body einer HTTP-Anfrage versandtes Passwort ist auch "nur" Plaintext, ebenso wie innerhalb eines Querystrings. Also ist das ungesicherte Versenden eines Passwortes - egal ob POST oder GET - doch immer ein Sicherheitsrisiko, oder bin ich da völlig auf dem Holzweg?

Und was ist mit Proxy-/Webserver-Logfiles, der Browserhistory oder gar dem Referrer?

Auch nicht ganz ohne: per copy&paste die URL in einem Forum als Link Posten und dabei übersehen, das man kritische Daten gleich mit veröffentlicht... (kann auch bei einer Session-ID gefährlich werden).

Gruß,

Harlequin

[nam]

Mein Gruss

Wenn ich mich für GET oder oder und POST entscheiden muss, halte ich mich eigentlich streng an die Bedeutung der beiden Wörtchen.
Also GET beschreibt das, was ich vom Server will und POST das, was ich dem Server senden muss, damit ich das auch bekomme. Damit bin ich bis jetzt ganz gut gefahren.

Wenn man dann ein Passwort mit GET versendet, ist das meiner Ansicht etwa so, wie invalider HTML-Code: es geht, aber es ginge schöner und besser.
Wenn man ein Passwort *unverschlüsselt* versendet, egal ob mit GET oder POST, ist es einfach nur dumm.

Nochmal mein Gruss,
nam

[Harlequin]

Yerf!

Wenn man dann ein Passwort mit GET versendet, ist das meiner Ansicht etwa so, wie invalider HTML-Code: es geht, aber es ginge schöner und besser.
Wenn man ein Passwort *unverschlüsselt* versendet, egal ob mit GET oder POST, ist es einfach nur dumm.

Oder billig. Für vieles im Netz wäre SSL wie mit nem Zeitungsverlag nach ner Fliege zu schlagen...

Gruß,

Harlequin

[Horst]

Hallo,

Wenn ich mich für GET oder oder und POST entscheiden muss, halte ich mich eigentlich streng an die Bedeutung der beiden Wörtchen.
Also GET beschreibt das, was ich vom Server will und POST das, was ich dem Server senden muss, damit ich das auch bekomme. Damit bin ich bis jetzt ganz gut gefahren.

Genau diese Philosophie lebe ich auch.

Und: Da ein Klick auf den Reload-Button nach einem POST den Benutzer mit einem Pop-Up-Window irritieren könnte, machen meine Scripts meistens eine Umleitung auf eine Bestätigungsseite "Ihre Eingaben wurden abgeschickt".

Viele Grüße,
Horst Haselhuhn

[Cheatah]

Hi,

Klingt nach "Das Format Ihres Postings scheint unsauber zu sein" ;)

richtig, aber ich hab's vorsichtshalber vorweg genommen ;-)

Ein im Body einer HTTP-Anfrage versandtes Passwort ist auch "nur" Plaintext,

Ja, aber eben nur im Body, nicht im einförmigen Ressourcen-Identifizierer.

Cheatah

[Patrick Andrieu]

Hallo Cheatah!

nicht im einförmigen Ressourcen-Identifizierer.

Meinst Du den Einheitskleidungsherkunftsauffinder?

Viele Grüße aus Frankfurt/Main,
Patrick

[Cheatah]

Hi,

nicht im einförmigen Ressourcen-Identifizierer.
Meinst Du den Einheitskleidungsherkunftsauffinder?

aber nur zusammen mit dem Einheitskleidungsherkunftsbenenner.

Cheatah

[Siechfred]

Ein im Body einer HTTP-Anfrage versandtes Passwort ist auch "nur" Plaintext,
Ja, aber eben nur im Body, nicht im einförmigen Ressourcen-Identifizierer.

Nun, wer an das Passwort will, kommt doch so oder so heran, ob nun POST oder GET? GET ist doch nur ein Risiko, weil der ERI ( ;) ) die Daten transportiert (Schulterblick, Browsercache, Logfiles), während es bei POST zugegebenermaßen schon schwieriger ist, an den Anfragekörper ( ;)) ) heranzukommen. Allerdings halte ich das nicht für ein erhebliches Sicherheitsrisiko von GET, sondern eher für eine allgemeine Besonderheit von HTTP.

Da stellt sich mir die überaus interessante Frage, wann man denn nun GET und wann POST verwenden sollte.

Siechfred

[Jonathan]

Hallo Siechfred,

Da stellt sich mir die überaus interessante Frage, wann man denn nun GET und wann POST verwenden sollte.

Für alle primitiven Anfragen an den Server (ich hätte gerne dieses Bild in einer Bildergalerie angezeigt, ich möchte diesen Artikel sehen usw.) nimmt man GET, sofern man das nicht gleich in der HTTP-Adresse ohne GET unterbringen will. Genauso sollte man get behandeln, es sollte vom Sinn her auf gleiche Rauskommen, ob man /artikel.php?title=start oder /artikel/start abfragt. Eine GET-Abfrage sollte immer ein reproduzierbares ähnliches Ergebnis ausgeben und keine relevanten Aktionen auf dem Server bewirken. Will man dem Server große Mengen Daten mitteilen (die der dann natürlich verarbeiten sollte), oder bei Bestellformularen oder Formularen im Allgemeinen nimmt man natürlich POST, weil man z.B. nicht will, dass ausversehen Aktionen zweimal ausgeführt werden können oder sogar schon direkt durch eine URL-Eingabe erfolgen können.

Zusammenfassend: GET ist eine Anfrage an den Server, die einfach bewirken soll, dass der Sever z.B. ein bestimmten Artikel, ein bestimmtes Bild in einer bestimmten Größe oder etwas ähnliches zurückliefert, ein POST nimmt man immer wenn eine (nicht-triviale) Aktion auf dem Server ausgelöst werden soll.

Jonathan

[Siechfred]

Zusammenfassend: GET ist eine Anfrage an den Server, die einfach bewirken soll, dass der Sever z.B. ein bestimmten Artikel, ein bestimmtes Bild in einer bestimmten Größe oder etwas ähnliches zurückliefert, ein POST nimmt man immer wenn eine (nicht-triviale) Aktion auf dem Server ausgelöst werden soll.

Ich habe mal in RFC 2616 herumgelesen, da wird zu GET auf Abschnitt 15.1.3 verwiesen, der empfiehlt:

Authors of services which use the HTTP protocol SHOULD NOT use GET
   based forms for the submission of sensitive data, because this will
   cause this data to be encoded in the Request-URI. Many existing
   servers, proxies, and user agents will log the request URI in some
   place where it might be visible to third parties. Servers can use
   POST-based form submission instead.

Ich gebe mich geschlagen ;)

Siechfred

[Tom]

0x01 SOH
Hello Jonathan,
0x02 STX

Für alle primitiven Anfragen an den Server (ich hätte gerne dieses Bild in einer Bildergalerie angezeigt, ich möchte diesen Artikel sehen usw.) nimmt man GET,

0x06 ACK

sofern man das nicht gleich in der HTTP-Adresse ohne GET unterbringen will.

0x15 NAK         die "HTTP-Adresse" wird üblicherweise per GET übertragen.
                 Eine HTTP-Adresse ohne GET müsste folglich eine Anfrage per
                 POST, HEAD, PUT, DELETE, ... sein. Da wäre in diesem Fall
                 wohl nur POST sinnvoll.
                 Also trivial ausgedrückt: Die Adresszeile im Browser ist immer GET,
                 egal ob Query-Parameter angehängt werden, oder nicht.

Genauso sollte man get behandeln, es sollte vom Sinn her auf gleiche Rauskommen, ob man /artikel.php?title=start oder /artikel/start abfragt. Eine GET-Abfrage sollte immer ein reproduzierbares ähnliches Ergebnis ausgeben und keine relevanten Aktionen auf dem Server bewirken.

0x06 ACK

Will man dem Server große Mengen Daten mitteilen (die der dann natürlich verarbeiten sollte), oder bei Bestellformularen oder Formularen im Allgemeinen nimmt man natürlich POST, weil man z.B. nicht will, dass ausversehen Aktionen zweimal ausgeführt werden können oder sogar schon direkt durch eine URL-Eingabe erfolgen können.

0x06 ACK

0x0E SO         ... oder diese Daten in der Öffentlichkeit auftauchen.
                Dies wäre auch mal ein geeigneter Ansatzpunkt für unseren Gesetzgeber
0x0F SI

Zusammenfassend: GET ist eine Anfrage an den Server, die einfach bewirken soll, dass der Sever z.B. ein bestimmten Artikel, ein bestimmtes Bild in einer bestimmten Größe oder etwas ähnliches zurückliefert, ein POST nimmt man immer wenn eine (nicht-triviale) Aktion auf dem Server ausgelöst werden soll.

0x06 ACK

0x03 ETX

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Jonathan]

Hallo Tom,

0x15 NAK         die "HTTP-Adresse" wird üblicherweise per GET übertragen.

Jo, so meinte ich das nicht. ich meinte, das GET-parameter einfach ein Teil der normalen "URL" bei GET-Anfragen sind und somit nicht anders behandelt werden müssen. Danke aber für die Korrektur.

Jonathan

[Cheatah]

Hi,

Nun, wer an das Passwort will, kommt doch so oder so heran, ob nun POST oder GET?

das ist kein Grund, damit hausieren zu gehen. Wenn es ohnehin immer möglich ist, in ein Haus einzubrechen, schlussfolgert man ja auch nicht, dass man die Tür gleich offen lassen kann.

Da stellt sich mir die überaus interessante Frage, wann man denn nun GET und wann POST verwenden sollte.

Sicherheit ist kein Ziel, sondern ein Weg. Er muss stetig weiter gegangen werden. Wenn es sicherer ist, Passwörter per POST statt per GET zu transportieren, ist der logische, richtige und wichtige Schritt, eben dies zu tun.

Cheatah

[Siechfred]

Sicherheit ist kein Ziel, sondern ein Weg. Er muss stetig weiter gegangen werden. Wenn es sicherer ist, Passwörter per POST statt per GET zu transportieren, ist der logische, richtige und wichtige Schritt, eben dies zu tun.

Kurz und prägnant. Danke.

Siechfred

[Tom]

Hello,

Da stellt sich mir die überaus interessante Frage, wann man denn nun GET und wann POST verwenden sollte.

Das stellt sich mir als konzeptionelle Frage dar.
Bisher halten sich alle mir bekannten legalen Internetpartner an _ein_ ungeschreibenes Gesetz:

GET-Requests werden gespeichert und ggf. veröffentlicht (siehe Suchmaschinen)
POST-Requests sind temporäre Datenzusammenstellungen ohne den Zweck, diese zur Reproduktion zu speichern, Nutzdaten hiervon natürlich ausgenommen.

Einen GET-request sollte man beliebig oft (oder zumindest öfter als einmal) mit gleichem oder ähnlichem Ergebnis ausführen können, möglichst ohne jede Zugangsbeschränkung

Alle beschränkten, privaten, temporären Abfragen sollten über POST abgewickelt werden.

Ich habe bisher noch keine Suchmaschine gefunden, die Seiten nach Post-Requests durchsucht und diese dann veröffentlicht. Das ist Sache ausschließlich der (illegalen) Datensammler.

Das es möglich ist, Seiten auch nach Post-Requests zu durchsuchen, soll nicht bestritten werden. Es ist aber bisher nicht üblich, sowas zum Zwecke der Verlinkung zu tun.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Daniel Thoma]

Hallo Structed,

Oft ist es ohnehin so, dass der CGI-Programmierer gar nicht mit bekommt, ob die Daten per POST oder GET übertragen wurden, oder maximal auf Umwegen. Bei CGI.pm beispielsweise greift man auf beide Parameter gleich zu.

Es mag Szenarien geben, in denen man das tatsächlich unterscheiden möchte, meistens ist es aber wirklich egal, jedenfalls aus der Sicht des CGI-Programms.
Dass es ungeschickt ist, Passwörter in die URL zu schreiben, ist klar. Das ist aber im Grunde kein Sicherheitsproblem des CGI-Scripts sondern des aufrufenden Formulars.

Grüße

Daniel

[Horst]

Hallo,

Oft ist es ohnehin so, dass der CGI-Programmierer gar nicht mit bekommt, ob die Daten per POST oder GET übertragen wurden

Ohje. Bist Du einer von denen!?

Falls Du diese Frage mit "Ja" beantworten solltest, hier mein Tipp für Dich: Schreibe nie wieder ein CGI-Programm oder -Script.

Viele Grüße,
Hotte

[Hopsel]

Hi Horst!

[...] CGI-Programmierer [...]
Ohje. Bist Du einer von denen!?
Falls Du diese Frage mit "Ja" beantworten solltest, hier mein Tipp für Dich: Schreibe nie wieder ein CGI-Programm oder -Script.

Warum?

Da ich mich gerade mit CGI und C++ befasse:
Welche Alternativen gibt es? (FastCGI kenne ich schon.)
Wo kann ich mehr darüber lesen?
Welche Vorteile haben die Alternativen gegenüber CGI?

MfG H☼psel

[Daniel Thoma]

Hallo Horst,

Bloß weil Du einen irrationalen Standpunkt vertrittst, soll ich nicht mehr CGI-Programme schreiben?
Hm, nein das überzeugt mich nicht ;-)

Grüße

Daniel