Hallo zusammen,
kennt jemand eine Statistik zur Infektion diverser CMS?
Oder die Häufigkeit pro 1000 Installationen?
Ich soll nun auch Wordpress anbieten, habe aber kein gutes Gefühl dabei.
Viele Grüße
Thoni
Druckbare Version
Hallo zusammen,
kennt jemand eine Statistik zur Infektion diverser CMS?
Oder die Häufigkeit pro 1000 Installationen?
Ich soll nun auch Wordpress anbieten, habe aber kein gutes Gefühl dabei.
Viele Grüße
Thoni
Hm,Zitat:
Zitat von Thoni
wenn Du das alleine entscheiden kannst, mach es doch einfach nicht.
Ich selbst bin auch von WP abgekommen weil mir unter Anderem der Updateaufwand zu groß war (unabhängig von dem was der Rest vom WP-System kann).
Gruß
tschero
Irgendwo habe ich schon eine CVE Vergleichliste (Anzahl) mal gesehen. Weiß nur nicht mehr ob hier oder Twitter oder in einem Vortrag... Mal sehen ob mir das noch mal unterkommt.
Aber das Worpress (meistens durch irgendwelche Plugins) wesentlich mehr Einträge hat als Contao, das ist schon mal sicher.
Grob kann man ja selber suchen:
Wordpress: http://cve.mitre.org/cgi-bin/cvekey....word=Wordpress
Contao: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Contao
Beispielsweise:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=contao
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla
https://cve.mitre.org/cgi-bin/cvekey...word=wordpress
... und so weiter.
Zum Gefährdungsvektor kommt sicherlich auch die Anzahl der Installationen hinzu. Je verbreiteter, desto mehr Versuche, desto lohnender automatisierte Angriffe, desto mehr gefundene Probleme. Man kann sicher nicht sagen, das ein bestimmtes System besonders sicher oder besonders unsicher ist. Systeme, in die man einfach mal eine Extension oder ein Plugin hineinklatschen kann, ohne das man sich grossartig mit den Themen Sicherheit und Aufbau des Cores auseinandergesetzt hat, sind da natürlich anfälliger.
Vielen Dank für die Infos.
Gibt es auch schon Datenschutz-Folgenabschätzungen der einzelnen Systeme?
Ich denke nicht, dass es das global für ein System gibt, denn eine Datenschutz-Folgeabschätzung (bzw. der Bedarf, eine durchzuführen) hängt doch sehr von den Verhältnissen ab, unter denen ein CMS eingesetzt wird, wie es konfiguriert wird, etc. Grob gesagt: immer dann, wenn es ein hohes Risiko für die Rechte und Freiheiten einer natürlichen Person gibt.
Schau mal bitte hier: https://dsgvo-gesetz.de/art-35-dsgvo/
Dort sind Faktoren genannt, die IMHO eher auf der Ebene der Art der Daten, die im CMS verarbeitet werden liegen und wie sie verarbeitet werden. Alle diese Faktoren sind hochgradig davon abhängig, wie und zu welchem Zweck ich ein CMS konfiguriere, was ich einbinde und was nicht. Den relativ klaren Sonderfall eines bei Automattic gehosteten Wordpress, das auf US-amerikanischen Servern liegt, lasse ich mal aussen vor.
Eine Datenschutzfolgeabschätzung kann beispielsweise dann notwendig sein, wenn es um Gesundheitsdaten, Daten Minderjähriger und so weiter geht (und ist auch dort nicht automatisch notwendig - kleinere Arztpraxen fallen da unter Umständen heraus).
Möglicherweise findest Du auch unter https://www.datenschutzbeauftragter-...nabschaetzung/ ein paar weitere Informationen.
EDIT: Hier gibt es noch eine Checkliste: https://www.datenschutz.org/folgenab...ung-checkliste
Die BSI (Bundesamt für Sicherheit in der Informationstechnik) hat da mal ne Studie veröffentlicht. Ist lange her und Contao war damals nicht dabei, aber die allgemeinen Konzepte sind erläutert. Zudem heißt es auch drin, dass es sich von Version zu Version und Installation zu Installation ändern. Absolute Wahrheiten führen zu Paradoxen, wie es bei Camus hieß.
https://www.bsi.bund.de/SharedDocs/D...cationFile&v=2
Die letzte Sicherheitslücke von 2017 bei Contao lautet ja wie folgt:Zitat:
Zitat von lucina
Contao before 3.5.28 and 4.x before 4.4.1 allows remote attackers to include and execute arbitrary local PHP files via a crafted parameter in a URL, aka Directory Traversal.
Was würde das in der Praxis bedeuten?
Das würde bedeuten, dass ein angemeldeter Backenduser an die URL in der Browserzeile eigene Parameter anhängen kann, mit denen dann *vorhandene* PHP-Dateien gefüttert werden, um irgendwelchen Unfug anzustellen. Man könnte damit beispielsweise Änderungen an Variablen untersemmeln, um Dinge aufzurufen, die sich bereits auf dem Server befinden, an die man aber normalerweise nicht rankommen soll. Auch das PHP-Binary könnte man beispielsweise mit Befehlen füttern. Wie sich das auswirken kann hängt IMO davon ab, wie der Webserver konfiguriert ist.
Möglicherweise ist das auch interessant im Zusammenspiel mit Erweiterungen, die weitreichende Systemrechte haben. Einen kompletten Datenbankdump möchte man sicher auch nicht an jemanden verlieren, der normalerweise nur Nachrichten bearbeiten darf, oder?
Das bedingt in jedem Fall eine gewisse kriminelle Energie von jemandem, der einen Backend-Account hat. Insofern ist der Vertrauensschaden ja schon vorher vorhanden ... ;-)
Mal konkret auf den Punkt "was soll ich soll anbieten".
Ohne die ganzen Beweismittel, janz prinzípiel.
Wordpress und seine Extensions (ohne die meist zuwenig geht) ist per se und schon seit "immer" eine Sicherheitslücke.
Wenn einer meiner "werdenden Kunden" meine Information, Erfahrung, Wissen und zudem leicht zu erfahrende Goggleinfo, gerne auch nach Diskussion und Beratung, nicht akzeptiert, dann:
L. M. A.
So und sofort und nix anderes.
Weil so ein Besserwisser mir in Zukunft immer Ärger machen wird, egal wie gut ich meine Arbeit mache.
Und darauf kann ich verzichten, selbst wenn ich Bettel gehen müsste.
Gruß dtptiger
Wer noch Gegenargumente sucht (WP): https://heise.de/-4271674
Jahresbericht: Rund dreimal so viele Sicherheitslücken in WordPress wie im Vorjahr.
Davon 2% in Wordpress, 98% in den Plugins.
"Nur" 2% von 542 Sicherheitslücken in Wordpress, das wären dann so ca 11 Stück. Herzlichen Glückwunsch!
Ja, WP ist gar nicht so schlecht. Aber solange es auch WP nicht gelingt, Menschen zu erklären, was sie wie selbst machen können, um Funktionen einzubauen, sondern sie für alles und jedes ein Plugin reinklicken, wird es in der Gesamtbilanz immer unschön aussehen.
Eigentlich ist das ja nicht so schwer. Aber PHP schreiben, um einen anderen Footer zu bekommen, ist ja für viele Nutzer*innen schon zu viel.
Naja, ich meinte eher, das ich 11 sicherheitskritische Lücken in einem Jahr nicht für wenig halte. Der Fairness halber müsste man allerdings auch mal im Detail schauen, was das für Lücken waren.
Und ganz ehrlich: Es kommt immer darauf an, wie mit den Lücken umgegangen wird.Zitat:
Zitat von tab
Da finde ich es mit Contao und dem Manager aktuell sehr sehr angenehm, da ein update Einspielen extrem einfach geworden ist. Und dann wird im Contao Umfeld auch noch sehr zügig und besonnen auf Sicherheitslücken reagiert.
Das dumme bei WP ist einfach: Dort ist weniger Zeit vorhanden einen Patch einzuspielen, wenn eine Sicherheitslücke bekannt geworden ist, da die Angriffe umso schneller gemacht werden bei einem so verbreiteten System...
Viele Grüße
Zudem sind halt bei Wordpress eine Menge, hmm, sagen wir mal unbedarfter Administratoren unterwegs. Hauptsache die Seite läuft ...
11 ist okay für die Verbreitung von Wordpress. Contao hat bestimmt zig Sicherheitslücken die bisher einfach noch keinem aufgefallen sind.
Das ist normal, Software enthält Sicherheitslücken. PHP selbst hatte letztes Jahr deren 21 (https://www.cvedetails.com/product/1...l?vendor_id=74).
Es ist heuchlerisch dem Kunden Contao zu verkaufen, weil es "besonders wenig Sicherheitslücken enthält". Es klingt gut und es funktioniert wohl im Verkauf, aber es entspricht nicht der Wahrheit.
Wichtig ist - wie bereits erwähnt wurde - wie mit denen umgegangen wird. Hält man sich an Responsible Disclosure? Holt man sich CVE-Nummern? Fixt man innert nützlicher Frist? Solche Sachen sind wichtig, nicht die Anzahl der Lücken.
Gibt es denn Richtlinien ab wann eine derart aufwändige Datenschutz-Maßnahme zu erfolgen hat? Ich meine, besteht diese Pflicht z.b. auch bei einem Portal, das ich eben schnell aufsetze für private Zwecke oder gilt es nur für gewerbliche Webseiten?Zitat:
Zitat von lucina