Druckbare Version
Guten Abend,
hat evtl. jemand einen Artikel / Beitrag warum Contao sich in der Hinsicht auf Sicherheit von anderen Systemen wie etwa Joomla unterscheidet ?
Was macht Contao hier "besser" als z.B Joomla ?
Warum sollte ich auf Contao anstatt auf Joomla setzen.
Schau mal hier, das ist ziemlich aktuell:
https://www.bsi.bund.de/DE/Publikati...tudie_CMS.html
Den Link hatte ich mir damals schonmal ein wenig durchgelesen.
Allerdings ist hierbei Contao leider nicht mit aufgelistet.
Mir fehlt um Moment einfach das besondere, warum man genau auf Contao, anstatt beispielsweise auf Joomla setzen sollte.
Abgesehen nunmal von der Bedienung etc. war mir hier der Sicherheitsaspekt wichtig.
Ich habe bisher noch von keiner gehackten Contao Seite gehört, aber schon zich von Joomla.
Was unterscheidet die Systeme in der Hinsicht. ( Natürlich man muss seine Installationen immer auf dem aktuellsten Stand halten, davon mal abgesehen )
Aber gibt es bestimmte Gründe, warum genau Contao in Sachen Sicherheit besser ist, als Joomla, Wordpress etc. ?
Hallo zusammen
Das würde mich auch interessieren. Wir setzen die meisten Websites mit Contao um aber oft werden wir von Kunden auch gefragt, ob Typo3 von der Sichheit her nicht besser wäre als Contao.
Es wäre toll, wenn man ein paar Facts hätte, wie sicher Contao ist (allg. System-Sicherheit, Passwort-Verschlüsselung, Schutz vor Hacking-Angriffen usw.)
LG
Marco
Hallo,
Ihr könnt auch einfach mal auf folgender Seite jeweils nach den Begriffen "Joomla" und "Contao" suchen: http://www.exploit-db.com/search/
Die Anzahl der Ergebnisse dürfte "alle Fragen" bezüglich "Sicherheit Joomla vs Contao" von selbst beantworten! ;-)
VG
Hallo w3scout
Danke für den Link. Ich bin mir aber nicht sicher, wie aussagekräftig das ist. Ich meine Typo3 ist (leider immer noch) verbreiteter als Contao.
Was ich suche ist ein Fact-Sheet über Contao: "Contao ist sehr sicher weil.... Verschlüsselung XY, moderne Technologie wie XY, Sicherheitsmechanismen wie XY... usw."
Gruss
Marco
Gerade weil Contao noch nicht so verbreitet ist wie Typo 3 ist es u. U. sicherer.
Und wenn man sich die Google Trends anguckt, ist Typo3 sicher nicht mehr der Platzhirsch:
http://www.google.de/trends/explore#...20typo3&cmpt=q
Und nimmst du mal Drupal dazu ist das eh gegessen :)
Es ist - wie meist, eine Frage was man will und was man dazu benötigt.
Contao filtert User Inputs und DB Queries standardmäßig, und die allermeisten Erweiterungen nutzen auch eben diese Schnittstellen, sodass sie dieses Sicherheitsfeature übernehmen. Die Struktur von Contao ist hier also recht intelligent aufgebaut, und die Regeln für Erweiterungs-Autoren sind auch klar (den meisten zumindest).
Die meisten anderen (bekannten) CMS u. ä. tun das nicht, was zum Teil durch ihre Herkunft entstand. Obendrein gibt es keine APIs bzw. Policies für Erweiterungen, sodass diese häufig zum Einfallstor werden. Das Gros der Sicherheitslücken lässt sich auf dieses Problem zurückführen.
Es gibt theoretische und praktische Überlegungen zur Sicherheit gegen externe Angriffe. Dazu ist die tägliche Benutzung und Administration mit den Systemen praxisrelevanter als theoretische Gedanken.
So werden derzeit massiv Typo3-Installationen mit älteren Apache SOLR-Suchengines von Botnetzen angegriffen.
Ziel bei solchen Attacken ist die Übernahme von Serverkapazitäten für weitere Payloads.
Die Verbreitung von Typo3 u.a. CMS ist derzeit halt viel höher und es gibt viele schlecht gewartete Installationen, die sich nicht mal eben notwendigerweise per Knopfdruck mit den neuesten Patches versorgen lassen, weil u.a. eine Extension oder Plugin XY nicht automatisch mitgeupdatet werden will.
Contao ist nicht soweit verbreitet dass es hier kaum automatisierte Scans geben dürfte.
Viel gefährlicher als automatisierte Angriffe gegen professionell gewartete Systeme sind arglose Benutzer und tatenlose Administratoren.
Ich habe vor nicht allzulanger Zeit einen Fall mitbekommen wo eine ganze Abteilung zu einem öffentlich erreichbaren CMS mit sehr sensiblen Daten ihre E-Mail-Adresse als Login und als Passwörter genutzt hat und dazu die Ansprechpartner auf der Homepage standen....Selbstredend standen noch von ehemaligen Mitarbeitern, die schon Jahre weg waren, solche Accounts offen....Keine weiteren Worte nötig.
Man muss den Benutzern auch noch wenigstens Passwörter einer gewissen Mindeststärke aufbürden.
Und wenn dann ein Mitarbeiter im Unfrieden ausscheidet und der Zugang nicht rechtzeitig dichtgemacht wird kann es noch Racheakte geben.
Oder die Leute arbeiten extern von außen und haben sich zuhause beim Runterladen von gecrackten Filmen und Spielen noch Trojaner mit eingefangen die alles mitloggen. Auch wunderbar.
Ansonsten geht nichts über regelmäßige Backup und Versionierung der Backups von Dateibaum und Datenbank über mehrere Monate, falls man sich dann doch mal was eingefangen hat. Dazu offizielle Patches zeitnah einspielen. Bei Einhaltung solcher Best Practices ist man als Firma dann auch schnell aus der Haftung raus, wenn mal was passiert.
Wer mal in seine Webserverlogs geguckt hat wird häufige Scans von irgendwelchen Drohnen sehen,die nach bekannten Schwachstellen wie z.B. PHPmyadmin oder einschlägigen Plugins im CMS suchen.
Auch gibt es immer noch viele Betriebswirtschaftler in Firmen die glauben dass Software als einzige Technologie auf diesem Planeten nicht regelmäßig gewartet werden muss und keine Betriebsaufwände hat, da Software immateriell ist. Dann ist kein Budget oder Personal für Wartung da. Das muss man bei der Beschaffung mit einplanen.
Die Betriebskosten eines lebhaft mit frischen Content bestückten CMS sind um ein Vielfaches höher als die reinen Launch-Kosten ! Vor allem dann wenn noch eine Agentur im Spiel ist die mehr als ein paar Euro Hostinggebühr im Monat bekommt.
Bei Joomla und vor allem Wordpress muss man sich auf die Programmierkünste der Entwickler der ausgewählten Plugins verlassen. Da sind schon einige sehr unbedarfte Newbies dabei.
Contao, Drupal und Typo3 haben die Sicherheit prinzipiell im Kern mit dabei. Da muss dann erstmal alles da durch und wird gefiltert.
Dennoch kann man auch hier an der internen API vorbeiprogrammieren, wenn man etwa direkt SQL-Queries mit GET- oder POST-Parametern ausführt statt sie vom Database-Layer filtern zu lassen.