Hallo ich habe da mal ne dumme Anfängerfrage!
Ich möchte bzw. ich entwickle gerade eine einfache Extension, bei der eingeloggte FE-User über FE-Formulare Daten eingeben, die anschließend in einer DB-Tabelle gespeichert werden sollen. Gibt es bestimmte Verfahrensweisen wie ich vorgehen muss, um Probleme wie etwa SQL Injection zu vermeiden?
Momentan ist es noch so, dass die Daten ähnlich wie bei der tt_news-Extension über Eingabemasken im BE eingegeben werden können, die über ein FE-Plugin in einer ListView im FE angezeigt werden. Wird ein Datensatz in dieser ListView angeklickt, gelangt man in die SingleView, die auf der selben Seite angezeigt wird. Die übergebene URL sieht so aus:
http://xxxxx/index.php?id=38&tx_meineExtension_pi1[showUid]=6&cHash=f7215c908f
Die nach [showUid] zu sehende "6" ist die UID des Datensatzes. Ist es dadurch nicht möglich auch in andere Datensätze zu schreiben, weil man die UID sehen und andere UIDs erraten kann? Wenn ja, wie kann ich das verhindern?
Selects, Inserts, Updates usw. möchte ich mit der Wrapper-Klasse “t3lib_DB” ($TYPO3_DB) realisieren. Im Falle der Selects tue ich dies bereits! Stimmt es, dass allein durch die Verwendung dieser Wrapper-Klasse "SQL Injections" verhindert werden können???
mfg therisingsun ;-)
Hallo,
zum Lesen: http://typo3.org/documentation/document-library/core-documentation/doc_core_cgl/4.1.0/view/
zum ID-Raten: Naja was ist daran das Problem, index.php?id=1234, da kann man auch jede Seite "erraten".
Wenn du sicher gehen willst, dass das nur auf der Seite funktioniert wie du willst kannst du ja noch einen 2. Parameter an die URL anhängen, der ein md5-Schlüssel aus der uid und noch was anderem (nicht erratbarem) ist.
zu den wrappern: Nur diese zu verwenden verhindert keine SQL-Injection!
georg
Erstmal Danke für die Antwort!
Ich habe mir die Seite mal durchgelesen aber so richtig durchblicken tue ich immer noch nicht. Vielleicht kannst Du oder jmd anderes mir ja weiterhelfen.
Auf der Seite steht, dass man die Funktionen t3lib::_GET(), t3lib::_POST() oder t3lib::GP() verwenden soll, da diese Funktionen immer Werte liefern, wo die Quotes nicht escaped sind. Dies geschieht durch die Funktionen stripSlashesOnArray() bzw. stripSlashes(), die innerhalb der oben genannten Funktionen aufgerufen werden und alle Backslashes entfernen. Richtig?
In meinem schlauen Buch "Typo3 für Entwickler" steht nun weiterhin, dass diese Funktionen automatisch verwendet werden, sofern das eigene Plugin von tslib_pibase erbt. (Ist in meinem Fall so!) Die Variablen stehen in diesem Fall als $this->piVars zur Verfügung. (Stimmt! Wie/wo das geschieht habe ich noch nicht herausfinden können)
Um SQL-Injections zu vermeiden steht darüberhinaus im besagten Buch als auch auf der von Dir geposteten Seite, dass die Funktionen $GLOBALS['TYPO3_DB']->quoteStr() für alle in Quotes übergebenen Variablen und intval() für alle numerischen Variablen verwendet werden sollen. (ich hoffe das stimmt auch noch!)
Außerdem sollen immer Quotes um die Werte gesetzt werden, es sei denn es sind numerische Werte.
Aus den entsprechenden Klassen weiß ich, dass quoteStr() die PHP-Funktionen mysql_real_escape_string() bzw. mysql_escape_string() verwendet, um die Backslashes vor bestimmten Zeichen zu setzen, sie also zu "escapen". Richtig?
Nun die große Fragen:
Weiterhin finde ich irritierend, dass innerhalb der Funktionen INSERT/UPDATEquery() vor dem Aufruf der Funktion fullQuoteArray() bzw. fullQuoteStr() folgender Hinweis steht: // Table and fieldnames should be "SQL-injection-safe" when supplied to this function (contrary to values in the arrays which may be insecure). Innerhalb der letztgenannten Funktionen wird nämlich wieder mysql_real_escape_string() aufgerufen, die doch eigentlich für das "escapen" zuständig ist. Warum soll ich diese Funktion denn vorher (gemeint ist der Einsatz bei den Werten, die man über Formularfelder geholt hat)schon mal bemühen?
Ich verstehe gerade gar nix mehr!
Hmmm kann mich keiner aufklären oder ist die Antwort so nahe liegend, dass keiner Lust hat einem Anfänger auf die Sprünge zu helfen?