nicht angemeldet
Hi,
Alle Variablen vom User (post, get etc.) werden vorher per addslashes(); maskiert.
Das reicht nicht, aber das ist auch nicht das Problem.
Was mich bei fast allen Anti-SQL-Injections-Tutorials ($PHP/manual/en/security.database.sql-injection.php ist da eine zwar erfreuliche aber auch noch nicht weit genug gehende Ausnahme), die ich eben auf dis Schnelle durchging stört, ist der Umstand, das niemand darauf eingeht, das das Hauptproblem darin besteht, jeden Mist zuzulassen und dann rauszusieben, was man _nicht_ haben möchte. Das ist verkehrtherum.
Richtig herum wäre es nur das zuzulassen, was man benötigt. Erwartet man eine Nummer, prüft man, ob eine Nummer angekommen ist, erwartet man einen String, der nur aus Buchstaben besteht, schaut man anch, ob der auch nur aus Buchstaben besteht. Was eine Nummer ist oder ein Buchstabe bestimmst Du dabei und nicht irgendjemand anderes.
Im speziellem Beispiel oben wären das $userdb und $username. Ich habe jetzt nicht in den Code geschaut, nehme aber an, das hier nur $username von außen kommt. Ein Benutzername benötigt numal nur Buchstaben. Ideal wäre hier ein Beschränkung auf ASCII, wenn man sich unsicher ist wie die DB z.B. auf UTF-16 reagiert.
Problematisch bei einem Board sind natürlich die einzelnen Postings, da mag sich keiner irgendwelchen Beschränkungen unterwerfen lassen und auch UTF-8 ist hier ein praktische Erfindung. Trotzdem kannst und sollst Du auch genauso verfahren: nur das an Zeichen zulassen, was Du geprüft und als ungefährlich eingestuft hast. Als ungefährlich gilt natürlich auch, was Du sicher(!) entschärfen kannst. Alle DB-spezifischen PHP-Funktionen gelten hier _nur_ für die zur Drucklegung aktuellen Versionen eben jener spezifischen DB.
Wirklich sicher sind hier eigentlich nur Mappings auf ASCII wie z.B. base64() o.ä., wie auch in einigen Artikeln tatsächlich vorgeschlagen. Aber sowas kostet natürlich nicht nur Rechenzeit (die man zur Not auch mit ordentlich Chuzpe und ein wenig Javascript auf den Client abwälzen könnte ;-) sondern selbstverständlich auch 30% mehr Platz. Es ist dann aber auch völlig egal, welche Codierung vorne reingeht und welche DB hinten dran hängt.
so short
Christoph Zurnieden