| piVars[]: Das Array, dem Entwickler vertrauen? |
| Jeder Parameter, der aus den „piVars[]“ ausgelesen wird, enthält die pure Nutzereingabe und muss vor der weiteren Verwendung entschärft werden, beispielsweise hinsichtlich SQL-Injections und XSS. Doch nicht nur den Werten der „piVars[]“-Elemente muss misstraut werden, sondern auch die Daseinsberechtigung eines jeden Elements muss überprüft werden: „piVars[]“ kann „Kuckuckseier“ enthalten, denn niemand kann einen böswilligen Hacker daran hindern, beliebig viele weitere Elemente mit der korrekten Prefix-ID in den HTTP-Request aufzunehmen. Deshalb empfiehlt es sich keinesfalls, alle „piVars[]“-Elemente per Schleife in ein SQL-Statement einzubinden, ohne vorher auf unerwartete Schlüssel-Namen geprüft zu haben. |
Backend-Module
In Backend-Modulen stehen keine „piVars[]“ zur Verfügung, statt dessen arbeitet der Entwickler mit „t3lib_div::_GET()“ und Konsorten. Oft benötigte Request-Parameter werden dem Entwickler von Backend-Modulen jedoch praktischerweise auf dem Silbertablett serviert, sofern sein Modul auf der hier üblichen Klasse „t3lib_SCbase“ basiert: Der Inhalt der Request-Parameter „id“ und „CMD“ wird beim Aufruf der Methode „init“ bereit gestellt in den Variablen
- $this->id (Typ-Konvertierung zu Integer ist bereits erfolgt) und
- $this->CMD
Die Kunst des Entschärfens
Nachdem geklärt worden ist, wie in TYPO3-Extensions elegant auf Nutzereingaben zugegriffen werden kann, richten wir nun unser Augenmerk auf das Entschärfen dieser Eingaben, um klassische Verwundbarkeiten zu vermeiden.





![TYPO3: 10 Jahre in 60 Sekunden zusammengefasst [Video]](http://t3n.de/uploads/t3n-news-post-361575_typo3_medium.jpg)

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.
[...] [...]