// 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.





2 Antworten
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.
von Get Variablen - PHP include - TYPO3 Foru… 17.06.2011 (14:06Uhr) 2.
[...] [...]