[MrNiceGuy]

Moin, moin,

na, mal schauen, ob das hier richtig ist (im Forum) ;)

Also: Ich bin gerade dabei mich neu zu orientieren, was meine Programmierweise angeht. Habe ich mich vor Kurzem noch immer dazu durchgerungen, alles selber zu machen, damit ich immer weiß, welches Script an welcher Stelle was tut und ich 100% weiß, was ich wo wie ändern muss, um xy zu erreichen, so bin ich mitlerweile etwas "ruhiger" geworden und möchte gerne ein oder mehrere Frameworks benutzen.
Dementsprechend ist das erst FW, das ich mir angeschaut habe das Zend-FW. Ansich eine tolle Sache und es gibt für viele Dinge bereits eine Erweiterung, die mir bis dato noch Kopfzerbrechen bereitet haben (z.B. ein vernünftiger SMTP-Mailer). Allerdings sind mir beim Überfliegen mancher Klassen ein paar Dinge aufgefallen und zu einer Stelle habe ich nun ganz besonders eine Frage an die Leute, die schon länger mit dem Zend-FW arbeiten:
Wenn ich sehe, dass GET-Variablen mittels:

PHP-Code:

if (isset($_GET['var'])) $this->var = $_GET['var']; 


ungefiltert übernommen werden, wird mir Angst und Bange. Die Frage ist nun nur - und so weit bin ich leider aufgrund der Verzweigung der Klassen noch nicht gekommen - ob das Zend-FW diese Variablen wirklich ungefiltert übernimmt oder ob diese an einer anderen Stelle gefiltert werden!? Oder sind die Scripte so programmiert, dass eine Filterung nicht notwendig ist, da bei "Schadcode" nichts passieren kann (z.B. durch Verwendung von Switch-Anweisungen, bei denen manipulierte Eingaben zum "default" geleitet werden)?

Ich bin nämlich nicht gewillt eine derartige Software zu verwenden, die eventuell Sicherheitslücken aufweisen könnte...

Oder sind derartige Code-Zeilen lediglich in den Demos an der Tagesordnung?

MfG
Lutz

[$traight-$hoota]

Gleich mal ne Gegenfrage: Wo hast du diesen Codeschnipsel gefunden? In nem Beispiel?
Dann dient es wohl vermutlich dazu, das ganze nicht zu kompliziert zu machen, da ein Beispielskript eh nicht produktiv eingesetzt werden wird. Und Einsteiger wissen damit vielleicht eher bescheid, was da passiert, als wenn da noch was gefiltert wird.
Das wäre so meine Überlegung dazu, gut finde ich es aber auch nicht wirklich, sowas in nem Beispiel zu verwenden.

Im eigentlichen Framework kommt sowas allerdings nicht vor, da kannst du beruhigt sein

[MrNiceGuy]

Gut, es war glaube ich auch eine der Demo-Dateien, aber bevor ich hier zig tausend Code-Zeilen durchstöbern muss wollte ich einfach mal nachfragen.

Ansich wirkt das Zend-Framework sehr ordentlich, allerdings fehlen mir für bestimmte Dinge noch Beispiele. Wenn ich z.B. den SMTP-Mailer nutzen möchte, weiß ich momentan noch nicht, wo ich die eMail, die verschickt werden soll, reinpacken soll und es fängt schon bei solchen Kleinigkeiten an, unübersichtlich zu werden. Aber ich schaue mir mal den Guide auf der Zend-Seite an.

Aber mal eine andere Frage: Was für Frameworks sind sonst noch empfehlenswert?

[dr.e.]

Im eigentlichen Framework kommt sowas allerdings nicht vor, da kannst du beruhigt sein

Was an dieser Stelle aber nicht für die Qualität der Beispiele spricht. Es gibt genug Copy&Paste-Künstler, die durch derartige Konstrukte den Code unsicher machen.

Im APF gehe ich seit der Version 1.5 den Weg, dass ich einen allgemeingültigen Input-Filter beim Erzeugen des Page- oder FrontControllers ausführe, der zunächst einmal den kompletten Input filtert. Das bringt bereits eine gewissen "Grundsicherheit", um die sich der Entwickler nicht kümmern muss. Bei Formularen oder anderen Stellen kann dann nochmal ein spezieller Filter verwendet werden, um die Eingaben abzusichern.

Ab dem 1.9er Branch kann der Entwickler nun auch die allgemeingültigen Eingabe-Filter beeinflussen / erweitern / ... um das Thema Eingabe-Sicherheit noch zu verstärken. Falls es dich interessiert, kannst du ja mal unter http://de.adventure-php-framework.org/Seite/087-Filter vorbeischaun.

An sich müsste man mit dem ZF jedoch ebenso die PreDispatch-Hooks dafür nutzen können um einen allgemeingültigen Input-Filter Anwendung finden zu lassen...

[$traight-$hoota]

Wie klar war mir das nur, dass in diesem Thread wieder die unübertrefflichen Vorzüge des APF gelobt werden würden...

Zitat von dr.e.

Was an dieser Stelle aber nicht für die Qualität der Beispiele spricht. Es gibt genug Copy&Paste-Künstler, die durch derartige Konstrukte den Code unsicher machen.

Das stimmt. Wer solchen Code einfach 1 zu 1 übernimmt hat es aber auch nicht anders verdient
Codebeispiele dürfen nicht mit dem eigentlichen Framework in Verbindung gebracht werden, nur weil sie dessen Verwendung demonstrieren. Ein solches Beispiel kann halt prinzipiell jeder schreiben, egal wie viel Ahnung er von der Sache hat.

[pago]

Zitat von dr.e.

[...]
Im APF gehe ich seit der Version 1.5 den Weg, dass ich einen allgemeingültigen Input-Filter beim Erzeugen des Page- oder FrontControllers ausführe, der zunächst einmal den kompletten Input filtert. Das bringt bereits eine gewissen "Grundsicherheit", um die sich der Entwickler nicht kümmern muss.
[...]

Nur kurz: Kann ich mir das so vorstellen wie die Magic Quotes nur das du den Fehler halt in leicht schlimmerer Form wiederholst?

Zum Thema selbst: Die Frage ist ja, was mit dem Input getan wird. Wenn er nicht ausgegeben wird und nicht in die Datenbank geschrieben wird, sondern nur zur Auswahl einer Aktion oder sowas verwendet wird, dann ist der potenzielle Schaden eher niedrig. Man muss natürlich trotzdem aufpassen, wie man ihn nutzt, aber wenn der Wert in ner Switch- oder If-Abfrage verwendet wird, ist ein Schaden eigentlich auszuschließen.

Ich hab an anderer Stelle schonmal auf PHP-IDS verwiesen, mache das aber hier nochmal, weil mir das nach ner wirklich schicken Idee aussieht, um die Grundsicherheit seiner Anwendung zu erhöhen.

[dr.e.]

Zitat von $traight-$hoota

Wie klar war mir das nur, dass in diesem Thread wieder die unübertrefflichen Vorzüge des APF gelobt werden würden...

Es ging nur darum aufzuzeigen, wie ich mich (beim APF) um dieses Thema kümmere. Aber mein Ruf scheint mir vorauszueilen.

Zitat von $traight-$hoota

Wer solchen Code einfach 1 zu 1 übernimmt hat es aber auch nicht anders verdient
Codebeispiele dürfen nicht mit dem eigentlichen Framework in Verbindung gebracht werden, nur weil sie dessen Verwendung demonstrieren. Ein solches Beispiel kann halt prinzipiell jeder schreiben, egal wie viel Ahnung er von der Sache hat.

Das ist genau das, was ich meine. Es gibt einfach genug Leute, die es schick finden, ein Framework zu nutzen und sich mit c&p den Code aus Beispielen und ihren bisherigen Dateien zusammen kopieren. Ich erlebe das täglich in diversen Foren. Deshalb sollten Beispiele schon einen gewissen Anspruch an vernünftigem und sicheren Code haben. Aber ich will jetzt auch keine Grundsatzdiskussion vom Zaun brechen. :)

Zitat von pago

Nur kurz: Kann ich mir das so vorstellen wie die Magic Quotes nur das du den Fehler halt in leicht schlimmerer Form wiederholst?

Nein, ich versuche das magic_quotes_gpc-Thema auszumerzen.

Zitat von pago

Zum Thema selbst: Die Frage ist ja, was mit dem Input getan wird. Wenn er nicht ausgegeben wird und nicht in die Datenbank geschrieben wird, sondern nur zur Auswahl einer Aktion oder sowas verwendet wird, dann ist der potenzielle Schaden eher niedrig. Man muss natürlich trotzdem aufpassen, wie man ihn nutzt, aber wenn der Wert in ner Switch- oder If-Abfrage verwendet wird, ist ein Schaden eigentlich auszuschließen.

Stimme ich zu 90% zu. Selbst wenn Eingaben nicht in die Datenbank geschrieben oder als Entscheidung für eine Aktion verwendet werden, kann es trotzdem passieren, dass du XSS-Lücken generierst. In Verbindung mit sensiblen Daten ist das ziemlich unspannend.

Zitat von pago

Ich hab an anderer Stelle schonmal auf PHP-IDS verwiesen, mache das aber hier nochmal, weil mir das nach ner wirklich schicken Idee aussieht, um die Grundsicherheit seiner Anwendung zu erhöhen.

Klingt gut, werde mich mal beschäftigen.

[Ben]

Zitat von $traight-$hoota

Wie klar war mir das nur, dass in diesem Thread wieder die unübertrefflichen Vorzüge des APF gelobt werden würden...

Schein ich also doch nicht der Einzige zu sein, dem das auf den Sack geht.


@Lutz:
Soweit ich weiß sind die Demos häufig bewusst sehr "locker" gehalten.
Bzgl. Beispiele und Co. kannst du vielleicht auch mal hier nachschauen: zfforum.de

Vielleicht findet sich da jemand, der dir da eher auf die Sprünge helfen kann.