Guten Morgen,
Unser Verlag ist gerade dabei komplett auf Typo3 (momentan V 3.8.1 umstieg auf 4.x.x nicht ausgeschlossen ) nun wünscht die Redaktion das aus Gründen der Verwaltung alle redaktionell relevanten Daten ( sprich auch über kommende Hefte ect.) innerhalb von Typo3 verwaltet und aufbewahrt werden.
Ich habe mich bereits etwas schlaugelesen, darunter auch den recht hilfreichen Artikel von Andreas Riesner und Christoph Etscheidt im T3N Magazin 02/06. Nun findet man auch in der Webrecherche relativ wenig glaubwürdige Dokumentationen über das Thema Typo3 Sicherheit (Wobei "Typo3-Sicherheit in erster Linie wohl unter Webserversicherheit fällt, die schwachstellen kann man soweit ich erfahren habe, größtenteils mit scripten aushebeln) . Die Dokumentation von Typo3.org finde ich in dieser Hinsicht leider etwas Oberflächlich.
Wenn ihr noch einige gute Quellen kennt oder selbst etwas zu diesem Thema beizutragen habt bin ich, im vorhinein schoneinmal, sehr dankbar 😉
Nun.
Der Typo3-Core ist sicher.
Sicherheitslücken finden sich am ehesten in Extensions - und da natürlich in kleinen, wenig benutzten Extensions.
Bei der Verwendung von großen, populären Erweiterungen - z.B. tt_news - sehe ich wenig Gefahrenpotential, da diese auf Sicherheit überprüft sind und z.B. keine hardcoded SQL-Abfragen - womöglich sogar ohne auskommentierte Benutzereingaben - drin sind sondern das ganze über ein Datenbank-Objekt läuft.
Der Vorteil an OpenSource-Software - wenn sie häufig eingesetzt wird - ist dass solche Lücken schnell bekannt UND behoben werden.
Wobei die größte Sicherheitslücke eigentlich bei jedem System die Benutzer selbst darstellen. Admins und einfache Passwörter.
Wer einen Admin-Zugang geknackt hat kann alles mit dem System machen.
Deshalb ist die Funktion der Mail-Benachrichtigung jedes Mal wenn ein User sich mit bestimmten (z.B. meinen Daten) Logindaten einloggt recht hilfreich, wenn auch auf die Dauer sehr nervend.
Mhm, zu einem ähnlichen Schluss bin ich ebenfalls gekommen.
Ein großes Problem bei Typo3 sind in meinen Augen immernoch XSS Attacken und drauf folgende SQL Injections (z.B. über eine Extension die Frontend Content(Benutzereingaben verwendet), wobei wir diese wohl auschließen können indem wir den Zugang auf das Backend auf das Intranet beschränken. Gut, eine emulation ist zwar immernoch möglich aber der Zugriff deutlich schwieriger.
An die Idee mit der benachrichtigung habe ich noch nicht gedacht, danke für den denkanstoß.
Kleiner Nachtrag:
Hier eine, vielleicht für mancheinen, noch interessante Adresse:
http://www.sec-consult.com/ Handelt zwar nicht direkt von / über Typo3, erklärt aber Grundkonzepte die zur Sicherung von Typo3 angewandt werden können.
Ich kann mich auch nicht erinnern, wann das letzte Mal eine kirtische Sicherheitslücke im Core gefunden wurde.
In Extensions ist das aber schon wahrscheinlicher:
http://www.typo3.net/aktuelles/sicherheitsluecke_in_der_extension_dam_downloads/
miwolfram schrieb
Wobei die größte Sicherheitslücke eigentlich bei jedem System die Benutzer selbst darstellen. Admins und einfache Passwörter.
... fullack ! 😉
Da kann man aber mit .htaccess den Zugriff zusätzlich kontrollieren bzw. einschränken ... und wenn das /typo3 Directory auch noch versteckt wird, ist's noch etwas schwerer für potentielle "Einbrecher" ... #paralyzed#
chris3 schrieb
Da kann man aber mit .htaccess den Zugriff zusätzlich kontrollieren bzw. einschränken ...
Wozu??? Da werden ja wieder Username/Passwort verwendet und es kommt wieder das Problem mit den Passwörtern zu tragen.
miwolfram schrieb
chris3 schrieb
Da kann man aber mit .htaccess den Zugriff zusätzlich kontrollieren bzw. einschränken ...
Wozu??? Da werden ja wieder Username/Passwort verwendet und es kommt wieder das Problem mit den Passwörtern zu tragen.
könnte auch auf die IP wirken :p
georg
just2b schrieb
könnte auch auf die IP wirken :p
IP-Beschränkung kann man aber für Typo3-Backend auch festlegen.
Hallo,
wir sind gerade dabei, über Typo3 unseren Unternehmensauftritt zu erstellen.
Leider haben wir ein Sicherheitsloch (?) im Bereich "tt_news" gefunden:
Auszug aus Protokoll:
The following URLs seem to be vulnerable to BLIND SQL injection techniques :
/535.html?cHash=8'+AND+'a'>'b
An attacker may exploit this flaws to bypass authentication or to take the control of the remote database.
Solution : Modify the relevant CGIs so that they properly escape arguments
Risk factor : High
Die aufgerufene Seite stellt die Einzelseite unserer "News" dar. Die Übersichtsseite der "News" hat kein Problem.
Miwolfram schrieb am 09.02.2006, dass "tt_news" keine Sicherheitslöcher haben dürfte. Haben wir bei der Implementierung etwas falsch gemacht?
Das Thema Typo3 ist für uns sehr neu und wir sind gerade erst dabei, uns mit dem System vertraut zu machen (wobei PHP und SQL nicht unsere Thematik ist).
Danke für evtl. Hilfe! :o
Hallo,
schreib rupert (ersteller der tt_news) doch mal an, der ist da eigentlich _sehr_ flott!
lg georg
frank_w schrieb
Leider haben wir ein Sicherheitsloch (?) im Bereich "tt_news" gefunden:
Auszug aus Protokoll:
The following URLs seem to be vulnerable to BLIND SQL injection techniques :
/535.html?cHash=8'+AND+'a'>'b
An attacker may exploit this flaws to bypass authentication or to take the control of the remote database.
Solution : Modify the relevant CGIs so that they properly escape arguments
Risk factor : High
Was ist mit seem to be vulnerable gemeint?
Ist das nun getestet oder nicht?
Dass GET-Parameter gefährlich werden können weiß man - wenn sie bei Verwendung nicht richtig escaped sind.
Ich kann mir jedoch nicht vorstellen dass es Probleme mit dem cHash gibt da dieser ja von vielen Extensions benutzt wird und - glaube ich - nicht direkt von einzelnen Extensions aus der URL abgerufen/benutzt wird.
Vielen Dank für die Antwort/Anmerkung. Hatte auch eine entsprechende E-Mail an Herrn Germann geschrieben und erhielt folgende Antwort:
(...)
Generell ist dazu zu sagen, dass cHash eigentlich gar kein parameter von
tt_news ist, sondern von TYPO3 selber generiert wird um es zu ermöglichen,
dass plugins, die verschiedene Inhalte auf der selben Seiten-ID anzeigen auch
gecached werden können.
siehe: http://typo3.org/development/articles/the-mysteries-of-chash/
da der cHash aus den GETVars auf validität überprüft wird, _bevor_ er an die
DB übergeben wird, kann über diesen Weg eigentlich keine SQL injection
stattfinden. Wenn diese Validitätsprüfung fehlschlägt, wird caching für die
betroffene Seite einfach deaktiviert und der falsche cHash wird verworfen.
(...)
Vielleicht hilft diese Antwort dem ein oder anderen weiter, der ebenfalls dieses Problem gefunden hat.
Vielen Dank für die Infos!
😉