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

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.

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)