Freitag, 20. Mai 2016

Security & TYPO3

Wie sicher ist TYPO3?

TYPO3 & Sicherheit

Vor dem Einsatz eines CMS wie TYPO3 stellen sich für jeden Interessierten natürlich einige Fragen:

  • Wie sicher ist das System?  
  • Da sich diese Anforderungen immer wieder ändern:  Was wird und kann getan werden um diese Sicherheit auch langfristig zu gewährleisten?
  • Was macht gerade TYPO3 zu dem CMS das ich einsetzen sollte?
  • Wer ist für die Absicherung verantwortlich?

Diesen Fragen werden wir in diesem Artikel nachgehen und zeigen warum TYPO3 eines der sichersten CMS Systemen geworden ist.

Die Sicherheit des TYPO3 Core

Das TYPO3 Security Team

Auf der Seite von TYPO3 Entwickler kümmert sich das TYPO3 Security Team um eine klare Vorgehensweise zur Prüfung und der Kommunikation von möglichen Sicherheitslücken von Typo3 Core und TYPO3 Extensions. Stellt das Security Team eine Sicherheitslücke fest, so arbeitet es eng mit den Core Entwicklern an der Analyse des Problems. Zusammen entwickeln beide Teams eine Lösung, die sorgfältig getestet und einem Review Prozess unterzogen wird. Sind diese Schritte abgeschlossen wird zeitgleich ein Security Bulletin mit Hinweis auf die Sicherheitslücke und ein TYPO3 Update zum beheben des Problems veröffentlicht.

Die Sicherheitshinweise oder Security Bulletins werden auf Webseite von typo3.org veröffentlicht, doch empfiehlt sich für Administratoren und TYPO3-Integratoren ein Abonnement des "TYPO3 Announce" Newsletters. Dieser enthält alle Informationen zu TYPO3 Versionen, Feature- sowie Security-Updates und Security-relevante Informationen für Third-Party-Software wie z.B. Apache, Nginx, MYSQL oder PHP.

Wie wird die Sicherheit von Extensions gewährleistet?

Das Vorgehen bei Sicherheitslücken bei Extensions ist ähnlich: wird eine Sicherheitslücke bekannt, prüft das Security Team die Extension, kontaktiert den Entwickler und bittet diesen um eine Behebung des Problems. Sobald dieser die Extension entsprechend angepasst hat, untersucht das Security Team die Extension in einem Review Prozess und bereitet dann den zeitgleichen Release einer neuen Version der Extension und einer Security Meldung vor. Erfolgt keine Änderung, weil z.B. die Extension nicht mehr betreut wird, so wird eine Meldung vorbereitet, in der die Deinstallation der Extension empfohlen wird.

Für eigene entwickelte Extensions die auf einem zuverlässigen stabilen Stand ("stable") sind, kann beim Security Team angefragt werden, ob diese Extension einem Review-Prozess unterworfen wird. Die Extension wird dann geprüft und bei Erfolg im Extension Manager von TYPO3 mit dem Status REVIEWED versehen.  

Der TYPO3 Core bietet Entwicklern zudem ein ganzheitliches Framework, das mit dem Paradigma „Convention over Configuration“ auch Vorgaben für Sicherheits-Aspekte festlegt und bei der Entwciklung so für eine klare Struktur im Code und Konfiguration sorgt.

LTS - Der Lebenszyklus einer Applikation

Für TYPO3 existiert ein klar definierter Lifecycle. Über diesen wird festgelegt für welche Versionen ein Sicherheits- oder Feature-Update zur Verfügung gestellt wird. Relevant ist hier immer die letzte veröffentlichte TYPO3 Version. Von dieser lässt sich ableiten, welche weiteren TYPO3 Versionen weiterhin Security-Updates erhalten.

Die Versionsnummer teilt sich in 3 Bereich auf: in Major- , Minor- und Revision-Nummer. Bei der Versionsnummer 6.2.15 wäre 6 die Major-, 2 die Minor- und die 15 die Revision-Nummer. Abgesehen von der LTS Version (dazu gleich mehr) werden ausgehend von der aktuellen Version immer die letzten 2 zuvor veröffentlichten Minor-Versionen noch mit Securityfixen und Support unterstützt. In unserem Beispiel wären die unterstützen Minor-Versionen also 6.1.x und 6.2.x. (Revisionsnummer hier = x da diese Zahl variieren kann).

Für LTS (Long Term Support) Versionen wie z.B. 6.2.x LTS oder 7.6.x LTS  garantieren die TYPO3 Core Entwickler ab dem Zeitpunkt der Veröffentlichung für mindestens 3 Jahre Support und Bereitstellung von Feature- und Security-Fixes. Dies bietet eine Planungssicherheit für den Einsatz von TYPO3 während der stetigen Weiterentwicklung des Core.

Sicherheit bei der eigenen TYPO3 Installation

Das entlässt bei Einsatz von TYPO3 aber Administrator, Integratoren, Entwickler und Redakteure nicht aus Ihrer Verantwortung. Sie müssen sich aktiv an der Absicherung des CMS beteiligen. 

Zusammengefasst sind bei der eignene Installation folgende Akteure bei TYPO3 für die Sicherheit mitverantwortlich:

  • Server Administrator
  • Integratoren
  • Entwickler
  • Redakteure

Passwörter

Idealerweise ist ein Passwort mindestens 9 Zeichen lang und besteht aus einer Mischung aus Groß-, Kleinbuchstaben, Zahlen und Sonderzeichen.

Die eingesetzten Passwörter sollten sich nicht anhand von Kenntnisse über den Benutzer oder aus einem Lexikon ableiten lassen. 

Identische Passwörter für unterschiedliche Bereiche wie z.B. im Install-Tool (dem konfigurations-Tool von TYPO3), dem eigentlichen TYPO3-Backend, bei der Anmeldung eines Frontend-User, oder Serverservice wie MYSQL, PHP, MAIL u.s.w. sind kritisch, da hier nur ein Element in der Kette durchbrochen werden muss um Zugang zu allen anderen zu erhalten.

Weitere Sicherheit erhält man, wenn diese Passwörter in regelmäßigen Abständen geändert werden und nicht mehr benötigte Benutzer umgehend deaktiviert werden.

Klares Rollenmodell

Innerhalb von TYPO3 sollten durch Definition von Benutzergruppen Benutzer festgelegt werden, für die klar und restriktiv festgelegt ist, welche Elemente und Bereiche von TYPO3 sie bearbeiten dürfen.

Die Rolle eines eingesetzten Benutzer ist relevant: Administrative Rechte sollten nicht für Aufgaben vergeben werden, wo ein eingeschränkter Benutzer ausreicht.

In der Praxis wird erstaunlich oft z.B. der Root-Benutzer für die Verbindung zur Datenbank benutzt - erhält jemand Zugriff auf die Zugangsdaten ist die Manipulation aller Datenbanken auf einem Server dann mit Leichtigkeit möglich.

Wird das gleiche Passort auch noch in mehreren Bereichen genutzt, gehört der Server schnell vollständig dem Angreifer. Das gleiche gilt auch für das Backend von TYPO3 - der Admin User der initial angelegt wurde, sollte nicht zur Pflege eines Live-Systems genutzt werden. Ist für Adminstratoren, Developer oder Integratoren der Zugriff auf den Server via ssh notwendig - so sollten auch hier klare Zugriffsrollen vorgegeben werden.

Sicherheit bei der Entwicklung

Developer müssen auch bei der Entwicklung mindestens ein separates Staging System einsetzen, um zu verhindern das durch die Entwicklung ggf. die Stabilität der Live-Seite gefährdet ist.  (Bewährt hat sich bei uns der Einsatz von  Development-, Staging- und dem Live-System).  Erst nach Fertigstellung, Prüfung und Freigabe durch den Kunden wird der Code dann letztlich auf das Live-System eingespielt.

Entwickler sollten ihren Code und ihre Konfigurations-Inhalte am besten in eigene Extensions kapseln, da diese Dateien dort am besten geschützt werden können. Positiver Nebeneffekt: der Code ist damit  gut pflegbar und Änderungen lassen sich unkompliziert deployen.

Der Einsatz von PHP-Scripten und Speicherung von Konfigurations Files im Fileadmin Ordner (dem Speicherplatz für Benutzerdaten aus dem Backend wie Bilder, Pdfs, Videos) vermieden werden, da diese dort nicht ausreichend z.B. durch einen htaccess Zugriffsschutz abgesichert werden können.

Programmierer bekommen von TYPO3 ein Framework geliefert um neben den übliche Maßnahmen zur Bereinigung der empfangenen Formular- bzw. Benutzer-Daten für PHP alle übermittelten Daten zu prüfen. Dies ist einerseits im Frontend möglich als auch durch die entsprechende Konfiguration der Backend-Formulare. Hält man sich an den von TYPO3 vorgegeben Konventionen zu Umsetzung von Extensions, so werden viele Probleme von Anfang an vermieden. Änderungen am Core selbst sollte man aufgrund möglicher Updates des Cores vermeiden. 

Ermittelt man während der Entwicklung eine Sicherheitslücke am TYPO3 Core oder an einer Extension von Dritten, so sollte man diese umgehend nur an das Security Team von TYPO3 kommunizieren (via Email an security@typo3.org). Dies dient auch der eigenen Sicherheit, denn wird die Lücke bekannt bevor ein Fix erstellt wurde, so sind die eigene Instanz wie auch andere die diesen Core oder Extension einsetzen, gefährdet. Das Security Team analysiert dann die Information stuft diese entsprechend ein und klärt wie bereits zuvor erläutert die Problematik mit den Core-Entwicklern und kümmert sich um die entsprechende Kommunikation.

Sicherheit für Integratoren

Für Integratoren gilt genauso wie auch für Entwickler die Regelung, dass Parameter die übernommen werden, grundsätzlich kontrolliert werden müssen.
Die Konfiguration wie z.B. ausgelagerte TypoScript Templates in externe Dateien sollte nicht für Au­ßen­ste­hen­de zugänglich sein.  Hier empfiehlt sich auch eine enge Kommunikation mit der Systemadministration.

Clickjacking lässt sich durch eine korrekte Konfiguration vermeiden. Clickjacking versucht durch eingeschleusten Code, dem Benutzer vorzugaukeln, das es bei einem angezeigten Link um einen offiziellen Link des Seitenanbieters handelt.   Hierbei wird, z. B. mit Hilfe eines HTML iframes, auf die Seite eines Dritten verwiesen. TYPO3 kann hier z.B. durch 

config.additionalHeaders = X-Frame-Options: SAMEORIGIN

definieren für welche Domains  iframes überhaupt erlaubt sind. 

Im Backend können Content Elemente in denen sich durch Redakteure HTML Daten unkontrolliert anlegen lassen ebenfallse zu einem Sicherheitsrisiko werden - durch eine entsprechende Konfiguration in der Page TypoSscript- oder USER TypoScript Konfiguration können hier Elemente nur mit notwendigen Feldern angezeigt werden und der Richtext Editor auf die notwendigen Funktionen reduziert und angepasst werden.  

TYPO3 bringt von Hause aus einige Konfigurationsmöglichkeiten im Install-Tool mit mit dem weitere sicherheitsrelevante Aspekte konfiguriert werden können:

  • cookieHttpOnly - diese Option ist per default an - Auf Cookies kann dann nicht via Script Sprachen wie Javascript zugegriffen werden.
  • cookieSecure - sollte in Kombination mit lockSSL genutzt werden. Damit wird geregelt ob ein Cookie nur über eine sichere HTTPS Verbindung gesendet wird.
  • displayErrors - Option ob PHP Fehler angezeigt werden sollen oder nicht. Für Liveserver sollten diese deaktiviert werden. Je weniger Informationen ein Angreifer hat um so besser.
  • devIPmask - kommaseparierte Liste von IP-Adressen für die Debuginformationen im Frontend angezeigt werden, sofern die Debug-Munktionen von TYPO3 genutzt werden.
  • enabledBeUserIPLock - Vorgabe von fixen IP-Adressen oder IP-Bereichen von denen aus der Login von Backend-User zulässig ist.
  • fileDenyPattern - reguläre Expression die bestimmt, welche File-Endungen sind im Kontext von TYPo3 erlaubt sind und hochgeladen werden können.
  • lockIP - eine erzeugte Session wird an die IP Adresse eines eingeloggten Users gebunden.
  • lockSSL - Aktiviert für das Backend die Nutzung von SSL.
  • IPmaskList - Angabe einer IP oder IP Range für die das Bearbeiten durch das BE erlaubt ist.
  • noPHPscriptInclude - verhindert das Einbinden von PHP Scripten wenn sie nicht in typo3/ext/, typo3conf/ext/ oder typo3/sysext/ liegen
  • trustedHostsPattern - TYPO3 nutzt den HTTP header "Host:" zur Generierung von absoluten URLs für 404 Handling, http(s) Enforcement, Password Reset Links u.s.w. Da der Host-Header jedoch vom Client manipuliert werden kann, werden hier erlaubte Hosts festgelegt.
  • warning_email_addr - Email wenn ein Login in das Install-Tool oder 3 backend Logins innerhalb einer Stunde gescheitert sind.
  • warning_mode - Notiz an die angegebene warning_email_addr bei einem Login eines Backend-Users.

Sicherheit bei der Administration

Backup

Eine geeignete Backup-Strategie sollte in jedem Fall integriert werden.

Logfiles überwachen

Events in den Log-Dateien sollten aktiv und auch indirekt wie z.B. durch die Nutzung von fail2ban mit auch Regeln definiert werden können,  ggf. sollte mit einer temporären Sperrung der IP-Adresse oder einee Information an den Administrator reagiert werden.

Absicherung des Servers

Der Administrator ist ebenfalls für die Absicherung der TYPO3 Instanz und des Servers zuständig. Es sollten nur Dienste auf dem Server laufen, die auch wirklich nur für TYPO3 benötigt werden. Auch die Komponenten der Dienste z.B. PHP und Apache selbst ist zu prüfen, nicht jedes Apache Modul und jede PHP Extension ist notwendig. Zusätzliche Software sollte nur der weiteren Absicherung dienen wie z.B. der Einsatz eines PHP Protection System wie Suhosin (http://www.hardened- php.net/suhosin/).

Absicherung der Dateistruktur

Auf File-Ebene innerhalb des Dokument-Root Verzeichnis muss der Zugriff beschränkt werden. Es sollte maximal 2 Benutzer geben: den Benutzer für den Apache HTTP Server (vom Betriebsystem vorgegeben, z. B. www-data) und einen Benutzer der ggf. Dateiuploads und Deployments via SSH oder SFTP vornimmt. Der Root-Benutzer sollte hier auf keinen Fall eingesetzt werden.

Die Verzeichnisse: "fileadmin", "typo3conf", "typo3temp" und "uploads" von TYPO3 sind die einzigen, für die Schreibrechte für den Webserver-User existieren sollten. Alle anderen Verzeichnisse sollten nur Leserechte erhalten. Der Zugriff auf spezielle Datei-Typen durch den Browser lässt sich durch eine entsprechende Apache Konfiguration erlauben oder verbieten.

Directory Indexing verbieten

Über die Apache-Konfiguration sollte auch das Directory Indexing verboten werden und als Schutz gegen Clickjacking auch hier mit dem mod.header Modul von Apache in den HTTP Headern die X-Frame-Options auf SAMEORIGIN oder fixen Domains konfiguriert werden.

Kein privilegierter Zugriff auf die Datenbank

Für die TYPO3 Datenbank wird ein Benutzer eingerichtet dem nur die Privilegien eingeräumt werden, die zum lesen und beschreiben der Datenbank notwendig sind. Die Rechte für MYSQL: FILE, PROCESS, CREATE USER, RELOAD, SHUTDOWN sind z.B. nicht notwendig.

Aktualität

Ein weiteres Puzzle-Teil der Sicherheit: Aktualität. Sowohl das Betriebssystem des Servers, dessen Dienste als auch der TYPO3-Core und dessen Extensions sollten regelmäßig auf stabile Versionen mit Support durch die Entwickler aktualisiert werden. 

Zertifikate

Eine Kommunikation des Servers mit Clients via SSL Zertifikat für Backend User und auch Frontend schafft eine weitere Sicherheitsschicht.

Sicherheit im Backend

Wie bereits erwähnt - muss hier von Anfang an eine klare Rollen Struktur vorgegeben werden. Durch die Zuweisung von Benutzergruppen lässt sich für Benutzer im Backend wie z.B. Redakteure ganz klar definieren, welche Bereiche, Daten und Plugins von TYPO3 für sie erreichbar sind.

Oops! Es ist passiert!

Hinweise dass eine TYPO3 Instanz möglicherweise kompromittiert wurde

An folgenden Aspekten kann sich evtl. ermitteln lassen das die eigene Webseite gehackt wurde:

  • an einer manipulierten Frontseite
  • Im im HTML Source Code ist schädlicher Code enthalten, dies kann ein Javascript-Schipsel sein, dessen eigentliche Funktion nicht klar ersichtlich ist, oder manuell eingefügte Links. 
  • Es finden sich unbekannte Elemente z.B. Binäre Dateien im Content der Webseite wo z.B.  die Web Besucher Dateien zum Download angeboten werden.
  • Es fällt eine unübliche Veränderung des Traffic  auf (entweder mehr oder weniger Traffic als zuvor ). Bei plötzlich auftretender Verringerung des Traffics gibt es möglicherweise Blockierungen von Virenkillern oder Webbrowsern, die den Schadcode erkennen, oder es kann eine htaccess Umleitung existieren.
  • Nicht zu unterschätzen sind Hinweise von Website-Besuchern auf Viren-Warnungen. Durch .htaccess Anpssungen lassen sich teilweise Suchanfragen die von einer speziellen Seite kommen wie z.B. Google zu einer anderen Domain umgeschrieben werden, während direkte Anfragen noch umgehend auf der Webseite landen. 
  • Eine offene Kommunikation über alle Hierarchie-Ebenen vom Administrator bis zum Redakteur lässt mögliche Sicherheitsprobleme oft frühzeitig erkennen und eingrenzen. Deswegen sollte man alle Beteiligten dazu ermutigen, mögliche Probleme immer umgehend anzusprechen, auch wenn sie womöglich nicht notwendigerweise ein Sicherheitsproblem darstellen. 

Vorgehen nach einem erfolgreichen Angriff

Trotz der Tatsache, dass die oben genannten Maßnahmen das Risiko eines erfolgreichen Einbruchs minimieren, kann es doch einmal dazu kommen. Was ist dann zu tun? 

  • Zunächst umgehend die  Webseite offline nehmen.
  • Die Domain, wenn möglich, zu einem anderen Server routen.
  • Dort einen Wartungs-Hinweis anzeigen lassen. 
  • Auf dem kompromittierten Server den Apache Service deaktivieren.
  • Den Zugriff auf den Server von außen ganz verhindern oder keinen anderen Internetzugang als den eigenen zulassen.
  • Auf jeden Fall: Backup des gesamten Quellcodes, der Datenbank und der Logfiles erstellen. Aufbewahren!
  • Analyse der Logfiles und gehackten Dateien um herauszufinden was den Angriff ermöglichte.
  • Schwere des Schadens zu ermitteln.
  • Weitere Security Issues ausschließen - Hier wäre zu prüfen ob ggf. phpshells oder ähnliches installiert wurde oder es fehlende Updates gab.
  • Prüfung auf ein erstelltes Backup vor den Änderungen durch den Angriff. 
  • Die Webseite aus diesem Backup wiederherstellen. Dann Lücke schließen.
  • Alle Passwörter und Access Details sollten geändert werden.
  • Erst danach dann wieder alle Server-Dienste in Betrieb nehmen und die Domain wieder umschalten. 

Je nach Schwere des Angriffs und Ziel der Angreifer sind zudem folgende Punkte zu prüfen und durchzuführen:

  • den Hosting Provider informieren 
  • die Benutzer der Seite informieren
  • und ggf. weitere rechtliche Schritte erwägen

Fazit

TYPO3 besitzt eine sehr große Entwickler Community, die eine sehr große Zahl von Extensions / Plugins entwickelt hat . Die gleiche Community trägt mit ihrem Feedback auch sehr schnell zum Aufdecken möglicher Sicherheitsprobleme bei.

Das TYPO3 Security Team ist eine weitere Instanz, um den zukünftigen Sicherheitsanforderungen und dem aktuellen hohen Sicherheitsstandards auch weiterhin gerecht zu werden.

Die TYPO3 Core-Entwickler haben über die Jahre ein Framework geschaffen, dass auch explizit API und Vorgaben für Entwickler bereitstellt, die zukünftige Entwicklungen in Hinsicht auf bekannte Sicherheitsrisiken von Aufbau und Konvention unterstützt.

Damit ist TYPO3, was seine Sicherheit angeht, sehr stark aufgestellt. Der Rest liegt, wie immer, in der Verantwortung der Entwickler, der Administratoren und der Redakteure.

comments powered by Disqus