Filter anstatt Superglobals?
MB
Filter anstatt Superglobals?
MB
Rolf bmoin,
warum soll man Filter-Methoden wie filter_input() anstatt Superglobale-Veriablen wie **$Server verweden? Neue Kovention in PHP 7 Doktrine oder sicherheitstechnisch???
vlg MB
-
Moin,
warum soll man Filter-Methoden wie filter_input() anstatt Superglobale-Veriablen wie **$Server verweden? Neue Kovention in PHP 7 Doktrine oder sicherheitstechnisch???
Wo steht denn, dass man die Filter verwenden „soll“? Aber sie sind mindestens nützlich.
Viele Grüße
Robert-
Moin,
warum soll man Filter-Methoden wie filter_input() anstatt Superglobale-Veriablen wie **$Server verweden? Neue Kovention in PHP 7 Doktrine oder sicherheitstechnisch???
Wo steht denn, dass man die Filter verwenden „soll“? Aber sie sind mindestens nützlich.
NetBeans
vlg MB
-
Moin,
NetBeans
… ist eine Java-IDE. Was hat das mit PHP zu tun?
Viele Grüße
Robert-
Irrtum. Netbeans ist eine IDE, die unter anderem Java kann. PHP aber auch und es liefert dann eine Menge Code-Hinweise. Ich verwende es ebenfalls für PHP und finde es eigentlich ganz gut.
Die Filter-Funktionen erlauben Dir, Daten aus Superglobals zu validieren ohne sie direkt anzufassen. Über die Sanitizer kannst auch gleich rauswerfen, was nicht hineingehört. Wer diese Funktionen erfunden hat, glaubte wohl, dass man so das Risiko von vergifteten Daten mindert. Allerdings hat der Erfinder auch gleich FILTER_UNSAFE_RAW eingebaut, so dass sich mit Vorsatz weiterhin in den Fuß schießen kann.
Den Code-Hinweis in Netbeans kann man auch abschalten. Optionen -> Editor -> Hints -> PHP Auswählen. Unter Hälfte, Superglobals. Setzt wie jede abgeschaltete Warnung Intelligenz beim Anwender voraus :). Wenn du die Superglobals ohne den filter-Asbesthandschuh selbst anfassen willst, musst Du Validierung und Sanitizing natürlich selbst übernehmen.
Gruß
Rolf-
Tach!
Die Filter-Funktionen erlauben Dir, Daten aus Superglobals zu validieren ohne sie direkt anzufassen. Über die Sanitizer kannst auch gleich rauswerfen, was nicht hineingehört. Wer diese Funktionen erfunden hat, glaubte wohl, dass man so das Risiko von vergifteten Daten mindert. Allerdings hat der Erfinder auch gleich FILTER_UNSAFE_RAW eingebaut, so dass sich mit Vorsatz weiterhin in den Fuß schießen kann.
Man muss die Superglobalen weiterhin direkt anfrassen, denn die Funktionen holen sich keine Daten, sondern erwarten sie als Parameter.
Es ist ein Irrtum, wenn man glaubt, dass man Daten allgemein sanieren kann, und dann sind sie sicher. Man hat dann das Prinzip nicht verstanden, warum bestimmte Zeichen in den Daten in bestimmten Situationen zu Unsicherheiten führen können, und in anderen Situationen wieder nicht, dafür aber wieder andere Zeichen. Die Funktionen sind ein Werkzeug, wie jedes andere Werkzeug auch. Man kann damit Dinge herstellen, oder kaputtmachen, je nachdem wie gut man seine Werkzeuge und ihre Einsatzmöglichkeiten kennt.
Die Erfindung der Funktionen wird wohl eher der Wunsch nach einem besseren Ersatz für das weggefallene Magic Quotes gewesen sein. Auch dieses hatte ein Ergebnis von wirksam bis kontraproduktiv.
Empfehlungen von IDEs sind zwar schön und gut und helfen üblicherweise, aber manchmal eben nicht. Blind folgen ist ähnlich sinnvoll wie anderen Ratschlägen, deren Sinn man nicht hinterfragt und verstanden hat.
dedlfix.
-
-
-
-
-
Tach!
warum soll man Filter-Methoden wie filter_input() anstatt Superglobale-Veriablen wie **$Server verweden?
Man sollte sie nutzen, wenn man deren Funktionalität nutzen möchte. Möchte man das nicht, kann man sie ignorieren. Und es geht nicht um ein anstatt, sondern um ein sowohl als auch. Die Filterfunktionen holen sich keine Daten, die muss man denen übergeben, zum Beispiel aus den bekannten superglobalen Variablen.
Laut Doku teilen sich diese Funktionen in validation und sanitization. Validation prüft ob die Inhalte bestimmten Bedingungen entsprechen. Das will und braucht man doch des öfteren je nach Anforderung der Geschäftslogik. Sanitization hingegen muss man nicht um jeden Preis haben, denn das verändert die Eingaben bis hin zu ungewünschten Ergebnisses. Der unbedachte Entwickler wendet Sanitization an der falschen Stelle an: bei den Eingabedaten. Dabei wissen die Eingabedaten noch gar nichts über ihren künftigen Weg und welche Zeichen dort irgendwelche besonderen Bedeutungen haben. Die kontextgerechte Behandlung, kurz bevor die Daten in den anderen Kontext eingefügt werden, stellt hingegen sicher, dass Zeichen nicht verloren gehen und sie stattdessen ordentlich maskiert werden, so dass sie syntaktisch korrekt und damit gefehrlos sind. Es wäre jedenfalls ein Trugschluss, dass man sich mit einmal filtern am Anfang die absolute Sicherheit ins Boot holt. Im Gegenteil, diese ist damit nicht garantiert und stattdessen gibts eine Menge Kollateralschaden.
Beispiel: Wenn man in einem Youtube-Chat eines Live-Videostreams eine URL eingibt, wird die Nachricht mit einem Warnhinweise nicht veröffentlicht. Soweit noch so gut, Spam-Schutz und so, wissenschon. Filtert aber auch jede sinnvolle und ungefährliche URL raus. Unsinn hingegen ist es, dass auch Nachrichten, in denen es nach HTML auch nur riecht, sprich: ein beliebiges Wort enthält, das in <> eingerahmt ist, rausgefiltert werden. Das hätte man man sicherheitstechnisch durch ordentliche Maskierung lösen können.
Neue Kovention in PHP 7 Doktrine oder sicherheitstechnisch???
Ich kenne von Doktrine nur den Namen. Die Funktionen gibts jedenfalls schon lange in der 5er Serie.
dedlfix.