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 gibt, unter anderem das komplette Archiv aller veröffentlichten Security-Bulletins.

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

Weitere Artikel zu TYPO3

Softlink 2193

Links und Literatur

Das interessiert dich bestimmt auch

Hilfreiche Ressourcen zu TYPO3

Hilfreiche Ressourcen zu TYPO3

TYPO3 ist mit über 500.000 Installationen, einer Community von mehr als 100.000 internationalen Mitgliedern und über...

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)