nikosch

Letztgesagtes stimmt allerdings

[MOD: verschoben]

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

agrajag

Dass es mit $_REQUEST in Verbindung mit Cookies Probleme geben kann seh ich ein - da habe ich bisher ehrlich gesagt nie darüber nachgedacht. (Ich verwende $_REQUEST ja auch nicht.)
Und ich finde es jetzt auch nicht unbedingt schön $_GET und $_POST zusammzulegen. Aber wo da das (potentielle) Risiko liegen soll kann ich irgendwie nicht nachvollziehen. Und nur weil einem eine Lösung nicht gefällt, ist sie noch lange nicht "schlampig".
Einen Kontrollverlust seh ich auch nicht und von "irgendeinem" Kanal kann auch nicht die Rede sein. Es sind genau zwei Kanäle GET und POST. Und der Kontrollverlust beschränkt sich darauf, dass ich nicht wissen kann ob eine bestimmte Variable per GET oder per POST übertragen wurde - eine Information auf die man verzichten kann.

(Danke übrigens für den Blog-Link. Ist gerade in meinem Feed-Reader gelandet )

__________________
Today you...Tomorrow me.

cortex

1. unsauber - darum:

http://www.cs.tut.fi/~jkorpela/forms/methods.html

2. wenn ein durcheinanderschmeissen der superglobalen ärger bereiten kann, gehe ich dem ganzen durch eine saubere trennung aus dem weg. das problem mit $_COOKIES war dir ja bis heut vormittag ebenfalls weitestgehend unbekannt. so... what comes next?

PHP macht uns die programmierung an vielen stellen sehr leicht; man sollte sich nicht auf dieser einfachheit ausruhen. das KISS-prinzip sollte an dieser stelle nicht misinterpretiert werden ;- denk mal an sicherheitslöcher wie register globals, über die sich vor jahren kein mensch gedanken gemacht hat. mit register globals zu coden war schon immer schlechter stil und eben dieser schlechte stil wurde irgendwann in zahlreichen exploits ausgenutzt.

grüsse,
cx

agrajag

Nein, das hat damit nichts zu tun. Auch wenn ich $_GET und $_POST in ein $params zusammenwürfele kann ich unterscheiden ob es ein GET oder POST-Request ist.

Bei Rails wird das zum Beispiel so gemacht. Du findet GET und POST Paramter in einem gemeinsamen Hash (params) und kannst über request.post? (wäre in PHP sowas wie $request->isPost()) ermitteln ob es ein POST (GET/PUT/DELETE) ist und nur dann bestimmte Aktionen ausführen (oder das ganze gleich über Routing regeln).

Ja, was kommt als nächstes? Das Problem mit $_COOKIE wird im verlinkten Artikel ja beschrieben. Und genau das besteht bei GET/POST nicht.
Und dieses Problem bzw. diese spezielle Attacke aus dem Artikel war mir unbekannt, weil ich $_REQUEST nicht verwende und mich nie damit beschäftigt habe.


Über register_globals hat man sich auch schon vor Jahren Gedanken gemacht. Und es ist auch einleuchtend warum das eine ganz schlechte Idee ist und wie leicht das zu fehlern führen kann.
Anders als bei dem, was wir gerade besprechen

Deiner Applikation kann es letztlich egal sein ob es GET oder POST-Paramter sind. Du musst höchstens wissen ob die Seite per GET oder POST aufgerufen wurde. Ich sehe einfach keinen wirklichen Punkt, an dem es wichtig ist zu wissen ob ein bestimmer Parameter nun aus $_GET oder aus $_POST kommt. Überprüfen musst du die Daten egal woher sie kommen. CSRF ist bei beiden möglich. Du musst eben nur aufpassen, dass du nicht $_GET['sonswas'] und $_POST['sonswas'] gleichzeitig verwendest. Ein Sicherheitsproblem ist das nicht. Höchstens ein Punkt an dem man sich wundern wird wenn man nicht drauf achtet.

__________________
Today you...Tomorrow me.

nikosch

Warum sollte man das machen?
Nicht ganz richtig. Auch ein POST Form kann GET Daten mitsenden.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

agrajag

Was meinst du jetzt genau? GET und POST zusammenfassen? Keine Ahnung - ich sage ja nicht, dass man es machen sollte. Ich sage nur, dass es kein Sicherheitsrisiko ist.
Oder wolltest du jetzt auf das Routing oder request.post? raus?


Ja, und?
Es ging dabei ja um den Hinweis, dass GET und POST-Requests verschiedene Anwendungen haben (sollten).
Es ist dabei egal ob die Daten als POST-Parameter oder GET-Parameter gesendet wurden. Wichtig ist ob es ein POST oder GET Request ist.

__________________
Today you...Tomorrow me.

cortex

du wiederholst dich. dass du $_GET und $_POST unterscheiden kannst, hat niemand bestritten.

prima - dann ist ja alles in ordnung.

dann frage ich mich, warum du diese ideologisch gefärbte diskussion mit mir führst. es scheint doch einen grund zu geben, warum du selbst $_REQUEST nicht verwendest.

soso. darum schleppen einen haufen anwendungen die geschwüre dieser schlechten idee immer noch mit sich herum, hm?

ich lasse das so stehen. ich habe mich zu dem ganzen geäussert und darüber hinaus keine lust, mich noch ein paar runden mit dir im kreis zu drehen. letztendlich kann jeder so coden, wie er's für richtig erachtet - ideologische grabenkämpfe bringen niemandem etwas, da es DOs und DON'Ts gibt, die sich zwischen 0 und 1 bewegen.

in diesem sinne,
cx

agrajag

Doch, implizit - mit deinem Hinweis, dass GET und POST Requests verschiedene Anwendungen haben.

Ich führe diese Diskussion weil ich nicht verstehe was an GET/POST-Paramter zusammenfassen ein Risiko ist.
Es geht doch auch garnicht darum warum ich es nicht verwende oder warum Rails und andere es verwenden. Es geht darum ob es sicher ist oder nicht. Ich sage ja du sagst nein. Und ich verstehe nicht warum...

Ok. Ich find's schade.

Da sind wir uns wenigstens einig. ...

__________________
Today you...Tomorrow me.