Druckbare Version
Der Contao Theme-Manager bietet nicht nur die Möglichkeit, Themes einfach zu importieren und zu verwalten, sondern stellt bedingt durch den Aufbau eines Theme auch einen möglichen Angriffspunkt für Hacker dar. Beachten Sie daher beim Theme-Import unbedingt die folgenden Sicherheitshinweise.
Ganzen Beitrag zu 'Sicherheitshinweise zu Contao-Themes' lesen
Achtet bitte darauf, dass es hier im Forum Pflicht ist, den Link zu diesem Sicherheitshinweis zu posten, wenn ihr auf einen Theme-Download verweist. :)
Einfach dann den Link hinzufügen:
Wichtiger Sicherheitshinweis zum Import von Contao-Themes
Dies gilt als Antwort auf Leos Wunsch http://www.contao.org/blog-leser/ite...ao-themes.html
Zitat:
Darüber hinaus sind jedoch alle Ideen und Anregungen willkommen, die zur Verbesserung der Sicherheit beim Theme-Import beitragen können.
Ich habe fuer einen lokalen Test eines CTOs heute ein kleines BE Modul geschrieben, welches noch ein ProofOfConcept ist.
Aktuell kann damit ein CTO VOR dem installieren kontrolliert werden, was es macht.
Es listet die Tabellen auf, in denen etwas geaendert werden soll, die Dateiliste.
Es werden die installierten Module kontrolliert, ob irgendwo Dateien (PHP) mittels Inserttag nachgeladen werden (diese koennen auch sicher im SourceCode angezeigt werden) und es gibt Previews der Bilder.
Natuerlich kann man noch mehr einbringen, aber da hoffe ich auf Anregungen durch die Community.
SVN : http://ktrion.de/svn/cto_check
Bugtracker : http://dev.typolight-forge.org/projects/ctocheck/issues
Und als Download : http://dev.typolight-forge.org/proje...files/ctocheck
ACHTUNG : In dem Paket ist auch ein Beispiel CTO dabei (music_academy_2.cto) welches beispielhaft zeigt, was man sich unbemerkt einholen kann. Zum Austesten, das CTO einfach in tl_files kopieren, und importieren. Wenn das DefaultLayout umgestellt wurde, sieht man im Frontend die Datenbank Zugangsdaten.
!!! DIESES CTO NICHT AUF EINEM PRODUKTIVSYSTEM AUSTESTEN !!!
Dies soll nur dazu dienen, das wir ein Tool haben, womit man sich im Vorhinein im Klaren sein kann, was ein ThemePack beinhaltet.
Um ehrlich zu sein: Warum bei jedem Download den Sicherheitshinweis? Wenn der Hinweis vor dem Import von einem Theme kommt, sollte es reichen (Checkbox wo man sagt, das man sich des Risikos bewusst ist).
So etwas lässt sich schon aus Gründen der Manpower gar nicht darstellen. Wir haben über 400 Erweiterungen mit durchschnittlich 6 Releases, also insgesamt um die 2.500 Pakete, die wir allein bei den Third-Party-Extensions durchgehen müssten. Je nachdem wie viele Themes in Zukunft verfügbar sein werden, müssen wir die Zahl der Themes multipliziert mit der jeweiligen Anzahl an Updates hinzurechnen (denn nach jeder Änderung eines Themes muss die .cto-Datei ja wieder neu geprüft werden). Das macht zusammen mehr als wir je schaffen könnten.Zitat:
Zitat von leo.unglaub
Nun, eine Zertifizierung / Gütesiegel als optionaler Hinweis ließe sich doch einrichten, oder? Dabei werden bestimmten Entwicklern (da ließen sich schnell einige vertrauenswürdige Personen finden) die Möglichkeit gegeben, die Extension / das Theme als sauber zu markieren. Erscheint eine neue Version, wird bis zur erneuten Prüfung die Meldung "in Version x zuletzt von y am dd.mm.yyyy gesichtet". Eine Prüfung für alle Extensions ist natürlich nicht möglich, aber somit kann eben teilweise ein Sicherheitsstandard gewährleistet werden, was grade unbedarften Nutzern eine große Hilfestellung ist.
Natürlich sollten die Reviews von mehreren Personen durchgeführt werden. Man könnte dabei eine "three stars" Bewertung zu Grunde nehmen: Nach dem ersten erfolgreichen Review bekommt die Erweiterung einen Stern, nach dem zweiten einen zweiten Stern, und nach dem dritten den letzten Stern (die Namen der Reviewer sollten natürlich immer angezeigt werden).
Ein Review aktualisierter Versionen sollte bei kleinen Updates einfach sein: Man muss ja nur die geänderten Dateien / Zeilen betrachten. Bei Updates von Erweiterungen, die ein Entwickler gesichtet hat, sollte dieser auch eine kleine Meldung bekommen, dass eine neue Version verfügbar ist – so bleibt man als Reviewer auf dem laufenden.
Aber irgendwie hatten wir das Thema schonmal …
Problem an so einer "gesichtet Extension" ist jedoch, dass es suggestiert, dass die Erweiterung sicher ist - und MySQL-Injections etc. kann einem doch mal durch die Lappen gehen beim durchlesen ;). Sterne würde ich an der Stelle des wegen überhaupt nicht verwenden, da es als bessere Erweiterung gilt, als ungesichtete.
Allerdings könnte eine Markierung "kein bösartiger Code gefunden" durchaus gut sein.
Du kannst auch Haken oder nur die Reviewer-Namen anzeigen, es geht hier nur um die dreifache Bestätigung. Damit verringert sich die Wahrscheinlichkeit, dass problematischer Code wie SQL-Injections übersehen werden – eine absolute Sicherheit gibt es natürlich nicht.Zitat:
Zitat von SunBlack
Eine Maximalzahl an Reviews verhindert auch, dass an manchen Extensions zu viel herumgedoktort wird, während andere außer Acht gelassen werden.
Das wichtigste Sicherheitskriterium ist meines Erachtens nach die Quelle. Contao-Partner dürften generell als sichere Quele eingestuft werden. Wenn ein Contao-Partner aber z. B. ein freies Theme zur Verfügung stellt und das unter GPL lizensiert ist, darf das Theme von jedem legal verändert und zum Download angeboten werden. Damit ließe sich auch in ein dreimal "zertifiziertes" Theme schädlicher Code einschleusen.
Vielleicht ließe sich da mit einer Prüfsumme etwas machen, die der "vertrauenswürdige" Entwickler des Themes auf seiner Website für jede seiner Versionen veröffentlicht.
Gruß
Harry
Mit Verlaub, Harry, aber das möchte ich doch so global bezweifeln. Auch da habe ich schon Dinge gesehen, die ich lieber nicht gesehen hätte.Zitat:
Zitat von Harry
Ich kann mir zwar nicht vorstellen, dass ein Contao-Partner / eine Contao-Partnerin irgendetwas fieses absichtsvoll und mit Wissen und Wollen einbaut, weil dann die Reputation so richitg im Eimer wäre, aber auch da kann immer was durchrutschen. Wie zum Beispiel bei einem der ersten Themes, das unbeabsichtigt eine komplette MusicAademy noch mit an Bord hatte. Platz wäre da für noch ganz andere Sahcen gewesen.
Wie bei allen systemnahen Sachen ist es sicher ein Indiz, aber keine Garantie. Selbst den Code lesen und verstehen. Und wenn man etwas nicht versteht: jemanden Fragen, der sich wirklich damit auskennt.
Sicher an sich ist erstmal nix.
Wir bemühen uns, das ist wohl klar. Und ich schreibe das als Contao-Partnerin.
Carolina.
Sehe ich auch so. Aber was man machen könnte (was davon schon gemacht wird, weiß ich gerade nicht):Zitat:
Zitat von lucina
- (Template-)Dateien die importiert werden durch einen Dateiendungs-Filter jagen, so dass nicht php-Dateien, js-Dateien etc. importiert werden kann.
- Stylesheets: Sehe ich gerade keine Angriffsmöglichkeit (ok, man könnte als Hintergrundgrafik verseuchte Grafiken verlinken, aber die kann man schlecht erkennen und Schaden nicht dem CMS, sondern maximal dem Benutzer [und deren Virenscanner wird dem Autor schon darauf stpoßen, dass mit dem Theme was faul ist]).
- Templates: Templatesystem verwenden, dass beim importieren alle Templates einmal parst. Script-Tags etc. könnte man dabei auch filtern und PHP-Angriffe sollten auch nicht möglich sein. Schränkt allerdings die Möglichkeiten der Templates ein - auch wenn ich sagen muss, dass es eigentlich nicht sehr oft ist, dass man außergewöhnliche Befehle verwendet. Damit Themes ohne Aufwand exportiert werden können, müsste man allerdings Templates allgemein bei Contao umstellen.
- Frontend-Module: Werte sollten einfach mal validiert werden ;).
Ansonsten wird nichts importiert, oder?