SecurityPackage

[kummer]

ich bin's gleich nochmal. etwas ist noch wichtig. und zwar: einer kombination von parametertyp und parametername darf nur ein einziger regex-typ zugewiesen werden. das führt natürlich dazu, dass eigentlich der parametername (mindestens innerhalb eines types, also get oder post) ganz und gar eindeutig sein muss. vorteilhafterweise wird das so gelöst, dass jedes modul (oder sogar jeder container) ein präfix verwendet. dann ist der parametername absolut eindeutig und wir haben damit auch gleich das problem gelöst, dass sich mehrere module in die quere kommen, wenn sie gleiche parameternamen verwenden.

das führt mich zum nächsten. damit wir das können, brauchen wir zunächst einen eindeutigen präfix für den container. der steht ja bereits dynamsich zur verfügung. aber auch das modul benötigt einen eindeutigen präfix, der dem modulentwickler bekannt sein muss. ich würde deshalb vorschlagen, dass man module anmelden kann (ein service, der einem beim aufruf eine eindeutige präfix gibt aufgrund einer sequenz). die securityPackage-klasse sollte es dann erlauben, den resultierenden parameterbezeichner (der im formular dann verwendet werden kann) zu erzeugen aufgrund der modulpräfix sowie der containerid. umgekehrt müsste das package dann auch erlauben, aufgrund des parameternamens den wert zurück zu erhalten.

ich wäre bereit, einen solchen service auf der seite editio.ch zu etablieren. man könnte dann sein modul anmelden mit folgenden angaben:

(1) name, vorname, firma (optional)
(2) email, web (optional)
(3) modulname
(4) modulbeschreibung (optional)

man würde dann eine präfix zugewiesen erhalten, die man mit dem service-package zusammen für absolute eindeutigkeit der parametername (zusammen mit der container-id) verwenden kann.

die daten würden dann allen interessierten zur verfügung stehen und ich könnte 4fb auch einen db-dump periodisch zur verfügung stellen.

alles was es dazu braucht ist ein ja von 4fb und der service würde ende februar stehen.

gruss,
andreas

[emergence]

hmm...
also ich steh auf unkompliziert... und das ist leider genau das gegenteil...

variante 3... ist meines erachtens unwartbar...
variante 2... da müsste man mit platzhaltern arbeiten die definieren was erlaubt wäre und wie zu prüfen...
variante 1... halte ich für am sinnvollsten...

ad

...ganz in das filesystem verlegen

da ist mir nicht ganz klar warum das für dich ein problem darstellt...

[kummer]

...ganz in das filesystem verlegen

da ist mir nicht ganz klar warum das für dich ein problem darstellt...

immer, wenn der server in das filesystem schreiben muss, müssen die berechtigungen ausgeweitet werden. es wäre meiner meinung nach besser, man müsste keine verzeichnise berechtigen. und die evaluation von code aus der db mit eval() ist als nicht wirklich sicher anzusehen. aber das ganze sind auch eher überlegungen und anregungen für eine langfristige ausrichtung.

[kummer]

variante 2... da müsste man mit platzhaltern arbeiten die definieren was erlaubt wäre und wie zu prüfen...

das ist allerdings schon geklärt. die parameter würden nicht direkt aus dem code gelesen, sondern aus einem kommentarbereich, wo die entsprechenden informationen angegeben sind.

[HerrB]

Für mich zeigt der Hinweis auf die Modul-Präfixe und regexpe, die den Modul-Code durchgehen, dass eine globale Lösung nur schwer umzusetzen ist.

Ich möchte bei der Erstellung von Modulen nicht von der Funktionsfähigkeit einer Webseite abhängig sein (siehe faq.contenido.org); auch nicht, wenn es eigentlich "nur" zu veröffentlichende Module betreffen würde (da ich mir für interne selbst was ausdenken könnte).

Wie wäre es mit einer Zweiteilung? Die Contenido-Parameter werden anhand einer Konfigurationsdatei über die Klasse gefiltert und erst gar nicht "durch die Tür gelassen". Der Konfigurationsdatei kann man manuell weitere Einträge hinzufügen oder sowas wie check.contenido.txt + check.local.txt + check.plugin.txt im jeweiligen Plugin-Ordner verwenden.

Modulen stellt man eine Check-Klasse oder -Funktion zur Verfügung, die die Überprüfung von Parametern stark vereinfacht (und der Modulentwickler hat die Verantwortung, sie einzusetzen und korrekt zu konfigurieren). Ich gebe zu, dass die einfache Verwendung einer regexp-Funktion von PHP dafür schon ausreichend wäre - es mangelt da wohl eher an Beispielen bzw. schönen regulären Ausdrücken oder Training.

Dass "falsche" Modulparameter damit erst im Modul aufgehalten werden und damit die Datenbank/der Webserver belastet wird, sehe ich weniger schwerwiegend, da ich die gleiche Wirkung auch mit korrekten Daten erzeugen kann...

Just my 2 cents.

Gruß
HerrB

P.S.: Vielleicht ist das schon berücksichtigt: Wenn Strings über die Klasse überprüft werden sollen, müsste die globals_off.inc.php auch eingebunden werden und die Strings ggf. nach strip_slashes geprüft werden.

[kummer]

Wie wäre es mit einer Zweiteilung? Die Contenido-Parameter werden anhand einer Konfigurationsdatei über die Klasse gefiltert und erst gar nicht "durch die Tür gelassen". Der Konfigurationsdatei kann man manuell weitere Einträge hinzufügen oder sowas wie check.contenido.txt + check.local.txt + check.plugin.txt im jeweiligen Plugin-Ordner verwenden.

sicherheit wird man nicht bei gleichem komfort erhalten. mehr sicherheit = weniger komfort. das gilt insbesondere für modulentwickler. es ist nun allerdings nicht so, dass die stringente prüfung von parametern etwas wäre, dass dann nur in contenido genutzt werden könnte. das ist im gegenteil etwas, das immer gemacht werden sollte. aber leider ist das nicht immer der fall. genau deshalb haben wir sicheheitsprobleme gehabt in der vergangenheit.

dass man nun zunächst nur die parameter anschaut, die von contenido genutzt werden und alle übrigen durchlässt, bringt in bezug auf die sicherheit keinerlei gewinn. wenn wir etwas erreichen wollen, dann dürfen wir keine parameter durchlassen, die nicht vorgesehen sind. wie beschrieben gibt es dazu mehrere wege. im wesentlichen gibt es die möglichkeit, die von einem modul benötigten parameter in einer konfigurationsdatei zu ergänzen (das ist der einfachste und am schnellsten umsetzbare weg). oder man lässt die konfiguration dieser werte direkt im modul zu, isoliert diese und fügt sie der konfiguration hinzu. das ist in der umsetzung etwas schwieriger, wäre aber auch möglich und ist langfristig - nach meiner einschätzung mindestens - der von den anwendern am besten akzeptierte ansatz.

wenn wir die prüfung den modulen selber überlassen, haben wir bereits wieder jeden sicherheitsgewinn verloren. dann reicht es nämlich aus, ein schlecht programmiertes modul zu verwenden und man hat ein sicherheitsproblem. und wer weiss den schon, ob er nicht so ein modul verwendet.

der von mir angesprochene präfix hat im übrigen nicht nur mit der sicherheitsfrage zu tun. das ist ein problem, das jetzt schon auftritt und dazu führt, dass gewisse module nicht im gleichen template eingesetzt werden können, da sie dieselben parameter verwenden. das ist störend und zwar unabhängig von der sicherheit. es wäre einfach günstig, diesen aspekt auch gleich zu berücksichtigen. es ist zurzeit nämlich so, dass z.b. ein modul den get-paramter 'page' verwendet und hier werte als zeichenfolge erwartet (z.b. artikelname). ein zweites modul verwendet ebenfalls 'page' als parameter, erwartet allerdings einen integer. in einem solchen fall wird das eine odere andere modul nicht laufen, da der parameter nur einmal vernünftig geprüft werden kann.

die maskierung der parameter mit der container-id und einem modulpräfix führt tatsächlich zu einer vereinfachung. mehre module können den gleichen parameter verwenden (z.b. page). beide module können mehrmals im template eingesetzt werden und trotzdem stören sich die parameter nicht, wenn mir präfixes gearbeitet wird. aus dem parameter page wird dann im container 14 beim modul mit der präfix 123 folgendes:

Code: Alles auswählen

123_14_page

wird das modul im gleichen template ein zweites mal eingesetzt, z.b. im container 21 lautet dann der parameter wie folgt:

Code: Alles auswählen

123_21_page

ein solches verhalten liesse sich bereits mit der containerid erhalten (die ja bereits zur verfügung stehen würde). für die parameterüberprüfung als sicheheitselement müsste es allerdings möglich sein, dass zwei module den parameter 'page' verwenden können. mit einer modulpräfix wäre das möglich.

ich halte es nicht für eine massgeblich verschlechterung, wenn die parameternamensvergabe sowie die parameterrückgabe durch den auftruf einer klasse erfolgen würde. wenn ich also z.b. den paramter 'page' habe und ich gerne wissen möchte, wie das formularfeld nun heissen muss, würde ich z.b. folgenden aufruf machen:

Code: Alles auswählen

$security->getParameter('page');

und würde dann einen absolut eindeutigen parameternamen erhalten. um auf den entsprechenden wert zugreifen zu können, würde man dann analog z.b. folgenden aufruf vornehmen:

Code: Alles auswählen

$security->getValue('page');

da ein modul ja durch contenido eine id zugewiesen erhält, lässt sich das auch ohne einen extra-service realisieren. beide werte (modulid und containerid) stehen als globale varialben innerhalb des modules zur verfügung und können vom securityPackage gelesen werden. die hier beschriebenen methoden getParameter und getValue liessen sich also problemlos realisieren und würden auf einen schlag zwei probleme lösen.

ich bin auch der meinung, man sollte keine eierlegende wollmichsau machen. deshalb gibt es für mich primär einen minimalansatz, den man umgehend realisieren sollte und einen umfassenden und komfortablen ansatz für vielleicht die übernächste version. aber wenn es als zumutung empfunden wird, im modul die paramter sowie den gültigkeitsbereich eines parameters zu bezeichnen, dann wird ein modul nicht sicher sein. aber dann soll es eben auch nicht ausführbar sein. contenido ist nur so sicher, wie das unsicherste modul, das in contenido läuft.

ich sehe das ganz hier auch einfach bloss als vorschlag. das securityPackage, das ich zum download anbiete kann als minimalansatz mit wenig komfort dienen und löst das problem weitgehend. bei einer integration in contenido wäre ich - wie holger vorgeschlagen hat - auch weiter gegangen.

gruss,
andreas

[HerrB]

lässt die konfiguration dieser werte direkt im modul zu, isoliert diese und fügt sie der konfiguration hinzu

Ist aus meiner Sicht die beste Lösung (inkl. Schreiben der Konfigurationsdatei online + Download). Ich halte das Schreiben der Datei aus Contenido heraus für vertretbar und wer es noch sicherer mag, schützt die Datei und nutzt den Download.

wenn wir die prüfung den modulen selber überlassen, haben wir bereits wieder jeden sicherheitsgewinn verloren. dann reicht es nämlich aus, ein schlecht programmiertes modul zu verwenden und man hat ein sicherheitsproblem.

Als Modul-Entwickler muss ich für ein "gut programmiertes" Modul u.a. zwei Dinge beachten:
- die festgelegte Parametervalidierung muss korrekt sein
- die weitere Nutzung der übergebenen Daten muss korrekt und im Hinblick auf Sicherheit erfolgen

Für beides muss ich Ahnung haben, wie man möglichst sicher programmiert. D.h. so oder so ist der Modul-Entwickler in der Pflicht (Beispiel: Der Einsteiger wird für String-Übergaben eine regexp wählen, die möglichst wenig limitiert und bei Pfadübergaben gar nicht wissen, dass die Zulassung von ".." und "x00" keine gute Idee ist; die aktuelle E-Mail-RegExp lässt z.B. \n und ; zu...).

Contenido kann unterstützen, aber es kann nicht verhindern, dass der Modul-Entwickler ungünstig programmiert.

Aber macht mal, es wird bestimmt eine gute Lösung dabei rauskommen.

Die Verwendung der Container-ID bei den Parametern halte ich generell für eine gute Idee (geht aber IMHO nur optional, da die Übergabe der Daten an einen anderen Artikel mit einem anderen Modul erfolgen kann; mir fällt gerade auf, dass die Container-ID bei einer Registrierung für die Prüfung noch einen Haken haben kann: Der Redakteur, der die Berechtigung zur Erstellung von Layouts hat, müsste die Registrierung durchführen können).

Muss sowieso meine veröffentlichen Module mal überarbeiten, da kann ich ja mal die Container-ID einarbeiten ...

Gruß
HerrB

[holger.librenz_4fb]

Hi.

Also einen ersten Versuch der Integration von kummers Security Package habe ich schon einmal ins CVS eingecheckt. Ist allerdings noch nicht wirklich der hunderprozentig letzte Schliff dran gemacht. Wollte aber wenigstens schon einmal etwas zum Herumnörgeln rausgeben

Die Sache mit den Parametern: Mir gefällt die Idee mit dem Anmelden. Das wäre zwar eine Änderung für eine zukünftige Contenido-Version, aber was haltet ihr von grundsätzlich folgendem Vorgehen:
<Gedankenoutput>
Im Modul müssen über eine von Contenido zur Verfügung gestellten Funktion / Methode alle Parameter, egal ob POST oder GET, angemeldet werden. Nachdem die Seite abgesendet und von Contenido verarbeitet wird, prüft Contenido die angemeldeten Parameter, normalisiert sie ggf. und verwirft danach alle Einträge in den Superglobalen _GET und _POST (_REQUEST muss natürlich auch entsprechend geleert werden). Die gesäuberten Werte stehen dann über eine weitere Methode zur Verfügung. So haben weder falsche Werte noch ungewollt durchgekommene "Fremdparameter" eine Chance Anwendung zu finden.
Eine Alternative bzw. Ergänzung wäre noch Module, die direkte Zugriffe auf _GET und _POST beinhalten, einfach als "defekt" zu markieren und von der Ausführung auszusperren. So können wir auch den merk-befreitesten Entwickler davon abbringen auf diese Werte direkt zuzugreifen.
</Gedankenoutput>

Das ist erst einmal wirklich nur ein reines Gedankenspiel, aber was haltet Ihr davon?

Zum Thema eval(): Und sehet da, ich habe die 10 Gebote. Das 11. Gebot lautet: "eval is evil!".... Das Problem ist allerdings, wie sollte es sonst abgebildet werden? Das Vorhalten des Modul-Codes in der DB hat ja auch noch andere Nachteile (Stichwort: Codeversionierung, da nix File auch nix direkt in CVS / SVN / whatever)... Aber das es eben "so einfach" geht, für die Ausgabe Code vorzuhalten, der schlichtweg PHP ist, ist ja auch IMHO eines der nettesten Features in Contenido...

So long.
Holger

[HerrB]

1) Modul a auf Seite 1 übergibt an Modul b auf Seite 2 Daten: a muss wissen, wie Parameter für b heißen müssen
-> Verwendung der Container-ID in der Parameter-Bezeichnung nicht möglich
-> Registrierung bei Style -> Module möglich
2) Modul a wird auf Seite 1 mehrfach eingesetzt, z.B. mehrere Artikellisten mit Blätterfunktion -> Damit man nur ein Modul braucht, wäre die Verwendung der Container-ID superpraktisch; alternativ kann man in der Konfiguration pro Verwendung einen eigenen Präfix bestimmen (nette Idee, fällt mir gerade ein)
-> Registrierung bei Kategorie/Artikel-Konfiguration erforderlich
3) Modul a stellt Formular mit dynamisch erzeugten Inhalten zur Verfügung - deren verfügbare Felder von anderen Angaben abhängig sind, z.B. ein Shop-System, Kalender, Community-Funktionen
-> Registrierung nicht möglich
4) Editieren über separate Backend-Edit-front_content.php wird wieder zurückgebaut (wie mehrfach gewünscht).
-> Kein Editieren mehr möglich, da praktisch alle (teilweise dynamisch) erzeugten Backend-Variablen registriert werden müssten.
-> Kein Rückbau möglich
5) Editieren eines Artikels über das Frontend (mit geeigneter Programmierung)
-> Ähnlich 3) und 4)
-> Kein Editieren eines Artikels über das Frontend oder Schutzfunktion deaktivieren
6) ...

Gruß
HerrB

[achiboy]

Das ist eine echt tolle Sache.

Eine Frage hätte ich da noch... Gehe ich richtig in der Annahme, dass diese Lösung mit $GET-Variablen als Array nicht funktioniert? Ein möglicher Link würde ja z.B. so aussehen
front_content.php?id%5B%5D=5&id%5B%5D=3&idcatart=99&lang=1&client=1

[holger.librenz_4fb]

Hallo achiboy.

Das ist richtig, das die Nutzung mit Arrays momentan nicht berücksichtigt wird. Allerdings wäre ich dafür eine solche Lösung auch bei GET Parametern weiterhin bewußt nicht zu unterstützen. Meines Erachtens machen Array Strukturen nur Sinn bei POST Requests. Das ist allerdings erst einmal nur meine Meinung - lass mich da mit entsprechenden Argumenten auch gern umstimmen

So long
Holger

[achiboy]

hm, dankschön - hast mich gerade auf eine tolle Idee gebracht.

[kummer]

die unterschiede bei der art der übetragung zwischen get und post sind marginal. im prinzip besteht kaum ein unterschied; es ist also mehr eine frage des designs von contenido, welche art für welche fälle unterstützt wird.

ich würde allerdings - wie holger - dafür plädieren, die übertragung mit get für diejenigen fälle zu verwenden, wo es für einen bookmark erforderlich ist (hier liegt nämlich der grösste und bedeutendste unterschied zwischen get und post). und dort machen arrays nun in der tat wenig sinn.

aber nebenbei bemerkt, lässt sich das paket natürlich dahingend ausbauen, dass auch arrays unterstützt werden. das ist im prinzip kein grosses problem.

[matt.loker]

Eine Frage zwischendurch,
dieses Sicherheitspaket ist nicht für Contenido mit ModRewrite kann das sein? Ich wollte es gerade einbauen und habe ziemlich viele Fehlerausgaben bekommen.

Grüße
matt

[DoroM]

Stimmt das?
Gibt es für die mr-Versionen denn auch eine Möglichkeit?


DoroM