Einen kompletten Schutz vor SQL-Injections bietet „exec_INSERTquery()“. Der Schutz ist aktiv, solange man den optionalen Parameter „$no_quote_fields“ nicht explizit auf „true“ setzt. „exec_UPDATEquery()“ bietet einen ähnlichen Schutz, der aber nicht den Inhalt des Parameters „$where“ einschließt. Alle anderen Methoden, unter ihnen die verschiedenen Varianten für „SELECT“-Abfragen, können das aus strukturellen Gründen nicht leisten und überlassen dem Entwickler die Verantwortung für die Entschärfung.
Werden Nutzereingaben vom Typ „String“ verwendet, wie es beispielsweise in einer Volltextsuche oder beim Speichern von Adressdaten der Fall ist, entschärft man gefährliche Zeichen, zum Beispiel alle Arten von Anführungszeichen, durch vorangestellte Backslashes. Die Klasse „t3lib_db“ bietet zu diesem Zweck die Methoden „quoteStr()“ und „fullQuoteStr()“ an. Letztere setzt an den Anfang und das Ende des Strings ein einfaches Anführungszeichen. Wenn MySQL das verwendete Datenbank-System ist, greifen beide Methoden auf die Dienste der PHP-Funktion „mysql_real_escape_string()“ zurück. Diese berücksichtigt den Zeichensatz der aktuellen MySQL-Datenbankverbindung und ist Unicode-fähig. Ohne ihre Hilfe wäre übrigens auch das Ablegen von Binärdaten in der Datenbank unmöglich.
| mysql_real_escape_string() versus addslashes() |
| Diese beiden PHP-Funktionen mögen sich auf den ersten Blick grundsätzlich ähneln. Die Funktion „addslashes()“ ist jedoch durch Unzulänglichkeiten in Verbindung mit ungewöhnlichen Zeichensätzen in Verruf geraten, wie PHP-Security-Experte Chris Shiflett in einem Blog-Eintrag herausarbeitet: SQL-Injections lassen sich durch „addslashes()“ nicht immer verhindern, deshalb ist die Funktion „mysql_real_escape_string()“ eindeutig vorzuziehen. |
Ein String-Wert sollte unbedingt auch auf eine plausible Länge hin geprüft werden. Ist ein String länger als das in der Datenbanktabelle dafür vorgesehene Feld, kann es unter Umständen zu Sicherheitslücken kommen, wie PHP-Sicherheitsexperte Stefan Esser in seinem Blogeintrag „MySQL and SQL Column Truncation Vulnerabilities“ beschreibt [3].
Oft wird es sich bei den in Datenbankabfragen einzubettenden Nutzerangaben nur um rein numerische IDs handeln, die zum Beispiel in Einzelansichten den anzuzeigenden Datensatz angeben. Hier bietet sich das Entschärfen per Typ-Konvertierung an. Alle GET- und POST-Variablen stellt PHP zunächst als Datentyp „String“ bereit, die Verwendung der Funktion „intval()“ oder eine Typwandlung über „(int)“ zwingt Nutzereingaben ein Integer-Dasein auf (analog kann ein String mit „floatval()“ zur Fließkommazahl konvertiert werden). Zusätzlich sollte (zum Beispiel per „if()“-Abfrage) geprüft werden, ob Integer-Werte in einem gültigen Bereich liegen. Oftmals werden zum Beispiel positive Integer-Werte erwartet, ein böswilliger Nutzer könnte statt dessen auch negative Werte zum Webserver senden.





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