von Henning Pingel, 02.12.2008

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

Aus dem
t3n Magazin Nr. 14

Jetzt kaufen

Unabhängig davon existiert seit 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.

Seite:  1 2 3 4 5 6 7 8 9 10 11 12 13

Empfohlene Artikel

2 Antworten

  1. von wir 12.04.2010 (20:42Uhr) 1.

    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.

  2. von Get Variablen - PHP include - TYPO3 Foru… 17.06.2011 (14:06Uhr) 2.

    [...] [...]

Deine Meinung


(wird nicht veröffentlicht)