Anzeige
Anzeige
Software & Entwicklung
Artikel merken

Sicherheitslücken in eigenen und fremden Extensions schließen: TYPO3-Extensions absichern

Im Jahr 2008 hat das TYPO3-Security-Team vor Sicherheitslücken in über 60 TYPO3-Extensions gewarnt. Viele dieser Extensions waren durch SQL-Injections und Cross-Site-Scripting verwundbar. Dieser Artikel soll helfen, die wichtigsten Security-Funktionen von TYPO3 und PHP kennenzulernen, sie effektiv einzusetzen und gefährliche Nutzereingaben angemessen zu entschärfen.

14 Min. Lesezeit
Anzeige
Anzeige

„Vertraue niemals Nutzereingaben!“ Diese goldene Security-Grundregel hat vermutlich jeder PHP-Entwickler irgendwann schon einmal gelesen oder gehört. Doch auch, wenn sich fast alle weiteren Security-Ratschläge auf diesen einen Satz zusammenkürzen lassen, gibt es heute immer noch zu viele leicht vermeidbare Sicherheitslücken in TYPO3-Extensions.

Ruhe vor dem Sturm: Lerne den Feind kennen

Anzeige
Anzeige

Ein Grund hierfür ist sicherlich, dass viele PHP-Entwickler und auch TYPO3-Administratoren noch nicht mit professionellen kriminellen Hackern in Berührung gekommen sind. Sie sind noch nicht mit dieser Unterwelt konfrontiert worden, in der „Experten“ ihre Brötchen damit verdienen, über Lücken in beliebten Websites das neueste Trojaner-Modell auf die Privat-PCs möglichst vieler Website-Besucher einzuschleusen. Damit bauen sie Bot-Netze aus Tausenden von Rechnern auf und vermieten diese für Cyber-Attacken. Selbst wenn auf einer kleinen, privaten Website keine sensiblen Dinge wie Kunden- oder Kreditkartendaten gespeichert sind und der Webmaster einem Angriff gelassen entgegen sehen mag: Er möchte doch eigentlich weder seinen Webspace zu einem offenen Proxy für das Anonymisieren von Cyber-Straftaten umfunktionieren lassen, noch den hart erarbeiteten Google-Pagerank unfreiwillig an eine zwielichtige Website durchreichen.

Professionelle Web-Kriminelle suchen gezielt nach neuen oder nutzen bekannte Sicherheitslücken in verbreiteten Web-Applikationen. Mit möglichst geringem Aufwand gilt es, eine Vielzahl von Websites gleichzeitig zu hacken. Auf diesen können dann an unauffälligen Orten „Web-Shells“ installiert werden, die Hintereingänge zum Webspace öffnen. Das geschieht oft unauffällig, der tatsächliche Zeitpunkt lässt sich auch bei gezielter Suche in Webserver-Logfiles nur schwer finden. Es passiert nicht selten, dass eine installierte Hintertür monatelang unbemerkt und ungenutzt bleibt, bis sie letztendlich zu einem günstigen Zeitpunkt ihren dunklen Zweck erfüllt.

Anzeige
Anzeige

Lücken locken

Jede beliebte TYPO3-Extension mit einer Sicherheitslücke ist daher potenziell ein gefundenes Fressen für böswillige Hacker. Ihnen fällt das Aufspüren von Schwachstellen auch ohne Kenntnis des betreffenden Quellcodes nicht schwer, obwohl dieser in unserem Fall via TYPO3 Extension Repository sowieso frei einsehbar wäre. In 2008 blieb ein paralleler Angriff auf viele Webserver mit TYPO3-Installationen bisher glücklicherweise aus, aber in der ersten Jahreshälfte 2007 konnte das TYPO3-Security-Team aus Berichten betroffener Administratoren erfahren, wie so etwas ablaufen kann [1]. Auch wenn wahrscheinlich eine mit TYPO3 nicht verwandte Web-Applikation das Haupt-Einfallstor bot, gibt es Belege dafür, dass auch eine SQL-Injection-Lücke in einer TYPO3-Extension zum Einbruch genutzt worden ist.

Anzeige
Anzeige

Stecken Sicherheitslücken nun vor allem in den Extensions von unerfahrenen Extension-Entwicklern? Tendenziell ist dies sicherlich richtig, aber zu den größten Gegenspielern von sicherer Software-Architektur zählen eben nicht nur Unerfahrenheit, sondern auch Bequemlichkeit und Zeitdruck. Davon ist der Arbeitsalltag beinahe jedes Entwicklers beeinflusst, gleiches gilt für Administratoren.

Unangemessen bequem agiert also nicht nur ein Extension-Entwickler, wenn er Checks zur Sicherheit seiner TYPO3-Extension entfallen lässt. Auch der Administrator einer TYPO3-Website handelt fahrlässig, wenn er eine Extension nutzt, aber nicht durch einen Blick in den Quellcode überprüft, wie sorgfältig diese konzipiert worden ist.

Anzeige
Anzeige

Pure Eingebung

„Vertraue niemals Nutzereingaben!“ – kaum ein Entwickler dürfte beim Klang dieser Worte Herzklopfen bekommen und voller Tatendrang zur Tastatur greifen. So wenig reizvoll die Umsetzung dieser Anforderung sein mag, so elementar wichtig und notwendig ist dieser Schritt. Und wer sich zusammenreißt und die Pflichten erledigen will, muss sich zunächst eine Frage beantworten, die gar nicht mal so trivial ist: Was sind eigentlich Nutzereingaben? Wo fangen sie an, wo hören sie auf? Viele werden beim Gedanken an Nutzereingaben sofort ein HTML-Adressformular oder die Maske einer Suchfunktion vor ihrem geistigen Auge sehen. Hilfreicher ist es allerdings, zunächst mal eine ungewohnte Sichtweise einzunehmen und einen Schritt zurückzugehen.

Relativ unbeachtet unter der schönen bunten Oberfläche des WWW befindet sich das Hypertext Transport Protocol (HTTP), ohne das Browser und Webserver niemals Kommunikationspartner sein könnten und das WWW nicht existieren würde. Grundlegendes Wissen über HTTP-Requests ist sehr nützlich, um die Typenvielfalt existierender Verwundbarkeiten, zum Beispiel HTTP-Response-Splitting oder Session-Hijacking, besser zu verstehen und zu vermeiden. Die wichtigen Aspekte von HTTP sind dabei relativ simpel.

Einen HTTP-Request ganz ohne Web-Browser selbst zu erstellen, ist recht unkompliziert möglich, beispielsweise über „telnet“ oder „PuTTY“. Tut man dies, bekommt man vor Augen geführt, dass ein relativ großer Anteil eines HTTP-Requests vom Nutzer frei modifiziert werden kann, ohne dass der Webserver das für anstößig hält und mit einem „Bad Request Error“ antwortet.

Anzeige
Anzeige

Es dürfte nicht überraschen, dass sämtliche GET- und POST-Parameter beliebig gestaltet werden können, unabhängig davon, ob sie vom Typ „hidden“ sind. Auch der „Host“ und der absolute Pfad (zusammen bilden sie die URI) sind frei wählbar. Das mag zwar banal klingen, hat aber Auswirkungen auf einige Elemente des superglobalen PHP-Arrays „$_SERVER[]“, was durchaus zu Sicherheitslücken führen kann.

Beispielsweise wird damit der Inhalt des Array-Elements mit dem Key „PHP_SELF“ zum potenziellen Einfallstor für Cross-Site-Scripting, sofern dieser ungefiltert in die HTML-Seite geschrieben wird. Dies kann beispielsweise im Rahmen des „action“-Attributs eines HTML-Formular passieren. Vorsicht geboten ist auch bei den Werten der Header-Felder „User-Agent“, „Referer“ und „Cookie“. Der Inhalt kann vom Nutzer so verändert werden, dass die Felder böswillige Zeichenfolgen enthalten, die dann auf PHP-Ebene auch im Array „$_SERVER“ landen. Ein direkter Zugriff auf dieses Array ist unter TYPO3 übrigens nicht empfehlenswert. Statt dessen sollte die statische Methode „getIndpEnv()“ der Klasse „t3lib_div“ genutzt werden, die eine Webserver-Abstraktionsebene einzieht. Doch befreit „getIndpEnv()“ nicht von der Pflicht, die Nutzereingaben zu entschärfen.

Als Extension-Entwickler hat man im Alltag vor allem mit den GET- und POST-Parametern zu tun, die im folgenden der Einfachheit halber als Request-Variablen bezeichnet werden. Sie stehen in den PHP-Arrays „$_GET[]“ und „$_POST[]“ zur Verfügung, erfahrene Extension-Entwickler verwenden diese Arrays jedoch nicht.

Anzeige
Anzeige

Zusammenfassend kann man sagen, dass die Inhalte der PHP-Superglobals „$_GET[]“, „$_POST[]“ und „$_COOKIE[]“ komplett unter der Kontrolle des Users stehen, teilweise gilt dies auch
für „$_SERVER[]“. Das Array „$_REQUEST[]“ wird im Rahmen von
TYPO3-Extensions übrigens gar nicht benötigt. Es gibt keinen Grund es
zu benutzen, auch im TYPO3-Core wird es nicht verwendet.

Nutzereingaben an Bord holen

Die TYPO3-Coding-Guidelines empfehlen Entwicklern, die in ihrer Extension beispielsweise auf den Inhalt des Formularfelds „first_name“ zugreifen wollen, dies mit Hilfe von „t3lib_div::_POST(‚first_name‘)“ zu tun, obwohl sie stattdessen auch einfach „$_POST[‚first_name‘]“ verwenden könnten. Um diese Empfehlung zu erklären, muss man etwas ausholen.

Mit Hilfe der Option „magic_quotes_gpc“ kann der PHP-Interpreter so konfiguriert werden, dass der Funktionsumfang von „addslahes()“ automatisch auf alle Request-Variablen angewendet wird, um so SQL-Injections zu verhindern.

Anzeige
Anzeige

Der Sinn dieser Konfigurationsoption ist bei Sicherheitsexperten jedoch derart umstritten, dass sie gemieden werden sollte und in PHP 6 nicht mehr enthalten sein wird [2]. Da eine Web-Applikation wie TYPO3 keinen Einfluss darauf hat, ob der Administrator „Magic Quotes“ aktiviert hat, muss der TYPO3-Core dafür sorgen, dass die Request-Variablen in jedem Fall im erwarteten Format vorliegen.

Folgende Lösung nutzt TYPO3: Falls „magic_quotes_gpc“ inaktiv ist, wird einfach simuliert, dass es aktiv ist. Sowohl zu Beginn der Frontend-Page-Generierung als auch der Backend-Page-Generierung wird dafür gesorgt, dass alle Elemente der PHP-Arrays „$_GET[]“ und „$_POST[]“ durch sich selbst überschrieben werden, nachdem „addslashes()“ auf sie angewendet worden ist. Der Grund hierfür ist, dass genau die hinter „addslashes()“ steckende Funktionalität auch im Falle von aktivierten „Magic quotes“ zur Anwendung kommt.

„addslashes()“ bietet aber, wie später noch deutlich wird, nicht immer einen wirksamen Schutz vor SQL-Injections. Um den Inhalt von „$_POST[‚first_name‘]“ zu schützen, müsste deshalb – unnötig umständlich – zunächst „stripslashes()“ darauf angewendet werden, um danach noch „quoteStr()“ zur Entschärfung zu nutzen.

Anzeige
Anzeige

Deshalb kann der direkte Zugriff auf Nutzereingaben in TYPO3-Extensions über die PHP-Superglobals $_GET[] und $_POST[] nicht empfohlen
werden. Einfacher und weniger fehleranfällig ist hier allemal, die drei von TYPO3 bereitgestellten statischen Methoden zu verwenden:

  • t3lib_div::_GET()
  • t3lib_div::_POST()
  • t3lib_div::_GP()

Darüber bekommt man die Werte der Request-Variablen ohne störende „Magic Quotes“ frei Haus geliefert. Bei der Methode „t3lib_div::_GP()“ erhalten POST-Parameter gegenüber gleichnamigen GET-Parametern den Vorzug. Die Nutzung der Methode bietet sich an, wenn man unabhängig vom tatsächlichen Request-Typ bleiben möchte. Aus Sicherheitsperspektive ist es jedoch besser, sich bei Formularen konsequent auf den Request-Typ „POST“ zu verlassen und daher „t3lib_div::_POST()“ zu verwenden. Somit wird ein Angriff via Cross-Site-Request-Forgery (CSRF) schwieriger: Böswillig manipulierte URIs, die vom ahnungslosen Opfer beispielsweise beim Lesen einer E-Mail angeklickt werden, können dann nicht mehr ohne Weiteres das Versenden eines ausgefüllten Formulars per GET-Parameter imitieren.

Spezialfall Frontend-Plugins

In Frontend-Plugins nutzt der Extension-Entwickler Methoden wie „t3lib_div::_GET()“ nur in Ausnahmefällen, da TYPO3-Frontend-Plugins auf der Klasse „tslib_pibase“ basieren. Daraus erbt man mit dem Array „piVars[]“ eine komfortable Zugriffsform auf Plugin-spezifische Nutzereingaben.

Anzeige
Anzeige

Da mehrere Frontent-Plugins auf einer Frontend-Seite kombiniert werden können, ist Ordnung höchstes Gebot: Zwischen den Parametern verschiedener Plugins bzw. Extensions darf es keine Namenskonflikte geben. Deshalb hat jedes Frontend-Plugin eine einzigartige Prefix-ID: „$this->prefixId“. Eine Request-Variable wird nur dann in das Array „piVars[]“ eines Frontend-Plugins aufgenommen, wenn ihr erstes Namensglied mit dem Wert der Prefix-ID übereinstimmt.

Im Array „piVars[]“ eines jeden Frontend-Plugins findet sich daher nur eine Auswahl der vorhandenen POST- und GET-Parameter. Bei Namensgleichheit hat POST Vorrang, ähnlich wie bei „t3lib_div::_GP()“. Es gibt für den Entwickler leider bisher keine elegante Möglichkeit zu bestimmen, ob ein Element in „piVars[]“ ursprünglich aus den GET-Variablen oder den POST-Variablen stammt. Dies wäre hinsichtlich der Vermeidung von CSRF nützlich.

Manchmal ist es nötig, aus einem Frontend-Plugin auf die Nutzer-Parameter eines anderen aktiven Frontend-Plugins zuzugreifen. In einem derartigen Fall muss auf „t3lib_div::_GP()“ oder ihre Pendants zurückgegriffen werden.

piVars[]: Das Array, dem Entwickler vertrauen?
Jeder Parameter, der aus den „piVars[]“ ausgelesen wird, enthält die pure Nutzereingabe und muss vor der weiteren Verwendung entschärft werden, beispielsweise hinsichtlich SQL-Injections und XSS. Doch nicht nur den Werten der „piVars[]“-Elemente muss misstraut werden, sondern auch die Daseinsberechtigung eines jeden Elements muss überprüft werden: „piVars[]“ kann „Kuckuckseier“ enthalten, denn niemand kann einen böswilligen Hacker daran hindern, beliebig viele weitere Elemente mit der korrekten Prefix-ID in den HTTP-Request aufzunehmen. Deshalb empfiehlt es sich keinesfalls, alle „piVars[]“-Elemente per Schleife in ein SQL-Statement einzubinden, ohne vorher auf unerwartete Schlüssel-Namen geprüft zu haben.

Backend-Module

In Backend-Modulen stehen keine „piVars[]“ zur Verfügung, statt dessen arbeitet der Entwickler mit „t3lib_div::_GET()“ und Konsorten. Oft benötigte Request-Parameter werden dem Entwickler von Backend-Modulen jedoch praktischerweise auf dem Silbertablett serviert, sofern sein Modul auf der hier üblichen Klasse „t3lib_SCbase“ basiert: Der Inhalt der Request-Parameter „id“ und „CMD“ wird beim Aufruf der Methode „init“ bereit gestellt in den Variablen

  • $this->id (Typ-Konvertierung zu Integer ist bereits erfolgt) und
  • $this->CMD

Die Kunst des Entschärfens

Nachdem geklärt worden ist, wie in TYPO3-Extensions elegant auf Nutzereingaben zugegriffen werden kann, richten wir nun unser Augenmerk auf das Entschärfen dieser Eingaben, um klassische Verwundbarkeiten zu vermeiden.

Böswillige Nutzereingaben können, wenn man sie vertrauensvoll gewähren lasst, in vielerlei Hinsicht für Ärger sorgen. Die Mehrzahl der verbreiteten Verwundbarkeitstypen, etwa „File Inclusion“, „Path Traversal“, „Code Execution“ oder „Information Disclosure“, lassen sich auf unzureichend überprüfte Eingaben zurückführen.

Die Herausforderung bei der Entschärfung von Nutzereingaben besteht darin, im jeweiligen Kontext die jeweils gefährlichen Zeichen oder Zeichenfolgen zu erkennen. Dazu gehören unter anderem Newline-Zeichen, Backticks, Null-Bytes, Anführungszeichen und spitze Klammern. Durch die Vielfalt vorhandener Zeichensätze und Enkodierungsformen können Zeichen mit der gleichen Bedeutung jedoch in unterschiedlichen Varianten in Erscheinung treten.

Im folgenden konzentrieren wir uns auf die in TYPO3-Extensions häufig vorzufindenden „Klassiker“: SQL-Injections und Cross Site Scripting (XSS).

SQL-Injections ausschließen

Bei einer Datenbankabfrage können Nutzereingaben SQL-Injections Tür und Tor öffnen. Deshalb muss verhindert werden, dass jegliche Art von gefährlichen Zeichen und Zeichenfolgen ungefiltert in den Abfrage-String gelangen können. TYPO3 stellt in der Klasse „t3lib_db“ Methoden für Datenbank-Operationen bereit, die dabei helfen können. Um dem Datenbank-Abstraktions-Layer von TYPO3 keine Steine in den Weg zu legen, sollten Extension-Entwickler für die Datenbank-Kommunikation ausnahmslos auf diese Methoden zurückgreifen.

Einen kompletten Schutz vor SQL-Injections bietet „exec_INSERTquery()“. Der Schutz ist aktiv, solange man den optionalen Parameter „$no_quote_fields“ nicht explizit auf „true“ setzt. „exec_UPDATEquery()“ bietet einen ähnlichen Schutz, der aber nicht den Inhalt des Parameters „$where“ einschließt. Alle anderen Methoden, unter ihnen die verschiedenen Varianten für „SELECT“-Abfragen, können das aus strukturellen Gründen nicht leisten und überlassen dem Entwickler die Verantwortung für die Entschärfung.

Werden Nutzereingaben vom Typ „String“ verwendet, wie es beispielsweise in einer Volltextsuche oder beim Speichern von Adressdaten der Fall ist, entschärft man gefährliche Zeichen, zum Beispiel alle Arten von Anführungszeichen, durch vorangestellte Backslashes. Die Klasse „t3lib_db“ bietet zu diesem Zweck die Methoden „quoteStr()“ und „fullQuoteStr()“ an. Letztere setzt an den Anfang und das Ende des Strings ein einfaches Anführungszeichen. Wenn MySQL das verwendete Datenbank-System ist, greifen beide Methoden auf die Dienste der PHP-Funktion „mysql_real_escape_string()“ zurück. Diese berücksichtigt den Zeichensatz der aktuellen MySQL-Datenbankverbindung und ist Unicode-fähig. Ohne ihre Hilfe wäre übrigens auch das Ablegen von Binärdaten in der Datenbank unmöglich.

mysql_real_escape_string() versus addslashes()
Diese beiden PHP-Funktionen mögen sich auf den ersten Blick grundsätzlich ähneln. Die Funktion „addslashes()“ ist jedoch durch Unzulänglichkeiten in Verbindung mit ungewöhnlichen Zeichensätzen in Verruf geraten, wie PHP-Security-Experte Chris Shiflett in einem Blog-Eintrag herausarbeitet: SQL-Injections lassen sich durch „addslashes()“ nicht immer verhindern, deshalb ist die Funktion „mysql_real_escape_string()“ eindeutig vorzuziehen.

Ein String-Wert sollte unbedingt auch auf eine plausible Länge hin geprüft werden. Ist ein String länger als das in der Datenbanktabelle dafür vorgesehene Feld, kann es unter Umständen zu Sicherheitslücken kommen, wie PHP-Sicherheitsexperte Stefan Esser in seinem Blogeintrag „MySQL and SQL Column Truncation Vulnerabilities“ beschreibt [3].

Oft wird es sich bei den in Datenbankabfragen einzubettenden Nutzerangaben nur um rein numerische IDs handeln, die zum Beispiel in Einzelansichten den anzuzeigenden Datensatz angeben. Hier bietet sich das Entschärfen per Typ-Konvertierung an. Alle GET- und POST-Variablen stellt PHP zunächst als Datentyp „String“ bereit, die Verwendung der Funktion „intval()“ oder eine Typwandlung über „(int)“ zwingt Nutzereingaben ein Integer-Dasein auf (analog kann ein String mit „floatval()“ zur Fließkommazahl konvertiert werden).
Zusätzlich sollte (zum Beispiel per „if()“-Abfrage) geprüft werden, ob Integer-Werte in einem gültigen Bereich liegen. Oftmals werden zum Beispiel positive Integer-Werte erwartet, ein böswilliger Nutzer könnte statt dessen auch negative Werte zum Webserver senden.

Auch per TypoScript können mit Hilfe des Objekts „CONTENT“ Datenbankabfragen gestaltet werden, und auch dort müssen Nutzereingaben, die etwa über „GPvar“ eingebunden werden, entschärft werden. Zum Erzwingen von Integer-Werten steht per „stdWrap“ die Eigenschaft „intval“ zur Verfügung, doch es gibt derzeit per TypoScript keinerlei vorgegebene Möglichkeit, über eine „stdWrap“-Eigenschaft „quoteStr()“ zu nutzen. Um dies zu tun, muss über „stdWrap“ eine nutzerdefinierte PHP-Funktion eingebunden und aufgerufen werden [4].

Code-Beispiele zum Vermeiden von SQL-Injections
 // String entschärfen mit Längencheck und quoteString
$first_name = $this->piVars[''first_name'];
if (mb_strlen( $first_name ) > 50) { $first_name = mb_substr( $first_name, 0, 50 ); }
$first_name = $TYPO3_DB->quoteStr( $first_name, 'tx_human' );
$res = $TYPO3_DB->exec_SELECTquery( '*', 'tx_human', 'first_name =\''. $first_name . '\'' ); 

// String entschärfen mit fullQuoteString (zur Vereinfachung ohne Längencheck)
$first_name = $TYPO3_DB->fullQuoteStr( $this->piVars['first_name'], 'tx_human' );
$res = $TYPO3_DB->exec_SELECTquery( '*', 'tx_human', 'first_name ='. $first_name ); 

// Erzwingen eines Integer-Werts und Plausibilitäts-Check des gültigen Bereichs
$max_age = intval( $this->piVars['max_age']);
if ($max_age < 0 || $max_age > 150) { $max_age = 0; }
$res = $TYPO3_DB->exec_SELECTquery( '*', 'tx_humans', 'human_age <= '. $max_age);

Listing 1

XSS blockieren

Wenn Nutzereingaben ungefiltert in die HTML-Seite eingebettet werden, wird Cross-Site-Scripting (XSS) möglich: Die Webseite kann vom Angreifer mit unerwünschten HTML-Strukturen oder JavaScript-Code angereichert werden. Ziele von XSS-Angriffen können vielfältig sein: Vom Cookie-Diebstahl, mit der ein unbefugter Dritter eventuell eine bestehende Session kapern kann („Session Hijacking“), bis zum „Website Defacement“ ist vieles möglich.

Im Gegensatz zur Vereitelung von SQL-Injections gibt es beim Aufbau eines XSS-Schutzes keine eindeutige, immer gleiche Vorgehensweise, sondern mehrere Varianten der Vereitelung, die je nach Zielsetzung auszuwählen sind: Im einfachsten Fall gibt keinen Grund, vom Nutzer hinzugefügte HTML-Tags zu erlauben: Ein Feld in einem Adressformular namens „first_name“ soll stets nur Vornamen enthalten. Sämtliche HTML-Tags sind unerwünscht und müssen deshalb entfernt werden. Hierfür kann die PHP-Funktion „strip_tags()“ verwendet werden, ohne den zweiten, optionalen Parameter für die Benennung erlaubter Tags zu nutzen.

Falls dem Nutzer in einem Eingabefeld eines Forums einige elementare HTML-Tags zur Text-Formatierung erlaubt sein sollen, kann der PHP-Funktion „strip_tags()“ bei Aufruf ein String mit erlaubten Tags übergeben werden. Allerdings bleiben damit auch alle innerhalb der Tags enthaltenen HTML-Attribute samt eventuell gefährlichem Script-Code übrig. Also ist noch ein zweiter Schritt nötig, um die Attribute zu entschärfen. Alternativ könnte man hier auf einen BBCode-Parser ausweichen.

Wenn in einem Support-Forum HTML- oder JavaScript-Code präsentiert und diskutiert werden soll, also Quellcode-Listings lesbar sein sollen, bietet sich die Behandlung mit den PHP-Funktionen „htmlspecialchars()“ oder „htmlentities()“ an. Hierbei werden unter anderem die Zeichen „<“ und „>“ umgewandelt, die jedes HTML-Tag umgeben.

Der TYPO3-Core bietet zusätzlich zwei Methoden an, die dabei helfen sollen, Cross-Site-Scripting zu verhindern: In der Klasse „tslib_content“ befindet sich die Methode „removeBadHTML()“. Diese Methode kann von TypoScript aus über „stdWrap“ genutzt werden, sie ist prinzipiell auch vom eigenen PHP-Code aus aufrufbar. Weil sie längere Zeit nicht gepflegt worden ist, bietet sie keinen sicheren Schutz vor heutigen XSS-Attacken. Auf TypoScript-Ebene sollten Entwickler anstelle von „removeBadHTML“ besser über „stdWrap“ die Eigenschaft „htmlspecialchars“ nutzen oder eine nutzerdefinierte PHP-Funktion einbinden und aufrufen.

Unabhängig davon existiert seit TYPO3 4.2 die Klasse „RemoveXSS“, die über „t3lib_div::removeXSS()“ aufgerufen werden kann. Die Funktionalität dieser Klasse besteht darin, gefährliche Schlüsselworte durch Hinzufügen einiger Zeichen so zu modifizieren, dass diese von der JavaScript-Engine oder dem HTML-Parser nicht mehr erfolgreich interpretiert werden können. Momentan gibt es Bestrebungen, die Zuverlässigkeit dieser Klasse zu verbessern, da es hierzu Problemmeldungen im TYPO3-Bugtracker gibt [5]. Extension-Entwickler, deren Extensions auch mit älteren TYPO3-Releases laufen sollen, stehen vor der Entscheidung, ob sie die Klasse in ihre Extensions einbetten sollen.

Darüber hinaus gibt es eine Vielzahl externer PHP-Projekte, die sich mit dem Abblocken von XSS beschäftigen, beispielsweise HTMLPurifier. Perfekte Tools zu diesem Zweck wird es wahrscheinlich nie geben. Sie befinden sich in ständiger Weiterentwicklung, bereits ein kleiner Bug kann eine Sicherheitslücke zur Folge haben. Qualität kann hier wohl nur dann sichergestellt werden, wenn die Tools kontinuierlich gepflegt werden, um bezüglich neuer HTML-Elemente, XSS-Angriffstechniken und Browser-Spezifika ihren „Biss“ nicht zu verlieren. Zudem sind sie hinreichend komplex, sodass ihre Zuverlässigkeit eigentlich ständig getestet werden muss. Derartige Tests können nur von Sicherheitsexperten erstellt und gepflegt werden.

Code-Beispiele zum Vermeiden von XSS
 // Keinerlei HTML erlauben
print '<p>'. strip_tags( $this->piVars['first_name'] ) . '</p>';

//abgesehen vom <em>- und <i>-Tag kein HTML erlauben (unsicher wegen beliebiger HTML-Attribute)
print '<p>' . strip_tags( $this->piVars['about_me'], '<em><i>' ) . '</p>';

//zusätzlich RemoveXSS anwenden, um Attribute zu entschärfen
print '<p>' . t3lib_div::removeXSS( strip_tags( $this->piVars['about_me'], '<em>' ) ) . '</p>';

//Generierung einer Sourcecode-Ansicht
print '<code>' . htmlspecialchars( $this->piVars['html_code_example']) . '</code>';

//RemoveXSS nutzen, um gefährliche Zeichenfolgen zu entstellen
print t3lib_div::removeXSS( $this->piVars['about_me'] );

Listing 2

Was tun, wenn’s brennt?

Stillschweigend behobene Sicherheitslücken, vor denen die breite Öffentlichkeit niemals gewarnt worden ist, sind ein gefundenes Fressen für böswillige Hacker. Nur per offiziellem Security-Bulletin ist gewährleistet, dass so viele Nutzer einer Extension wie möglich ein zeitnahes Update auf eine abgesicherte Version der Extension durchführen können. Für den Fall, dass jemand in einer eigenen oder in einer fremden TYPO3-Extension eine Sicherheitslücke entdeckt, sollte er sich direkt per E-Mail an das TYPO3-Security-Team wenden (security@typo3.org). Das Team kontaktiert dann den Extension-Autor, der hoffentlich seine aktuelle E-Mail-Adresse im TER gepflegt hat, und informiert ihn über die gefundene Lücke. Anschließend koordiniert das Team alle weiteren Schritte zusammen mit dem Autor. Die im Oktober 2008 erstmals veröffentlichte Extension-Security-Policy beschreibt die Vorgehensweise und die Erwartungen des Security-Teams an die Kooperation mit den Extension-Entwicklern bezüglich gemeldeter Sicherheitslücken detailliert. Sie ist auf der Website des Security-Teams zu finden [6], wo es auch weiteres Informationsmaterial rund um den sicheren Betrieb von TYPO3 gibt, unter anderem das komplette Archiv aller veröffentlichten Security-Bulletins.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Ein Kommentar
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

wir

Ein CSRF-Angriff kann nicht dadurch verhindert werden, dass Requests, die zu einer Veränderung von Daten führen, nur per HTTP-POST akzeptiert werden. Auch per HTTP-POST kann ohne weiteres ein gefälschter Request abgesetzt werden. Dazu erstellt der Angreifer eine Seite, auf die er das Opfer lockt. Dort wird der manipulierte Request entweder mittels einer clientseitigen Skriptsprache wie zum Beispiel Javascript erzeugt oder der Angreifer bringt das Opfer dazu, auf einen Button oder ein Bild zu klicken, wodurch der Request abgesetzt wird. Wählt der Angreifer als Ziel (target-Parameter) des Formulars einen unsichtbaren Frame oder Inlineframe, sind auch hier die Chancen gering, dass das Opfer den Angriff bemerkt. (http://de.wikipedia.org/wiki/Cross-Site_Request_Forgery#Nur_HTTP-Post_akzeptieren)

Was mich aber interessieren würde, ist ob TYPO3 Funktionen bereitstellt um Canaries in Formulare einzufügen.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige