Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 14

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.

„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

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.

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.

Bitte beachte unsere Community-Richtlinien

Eine Reaktion
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.

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Finde einen Job, den du liebst