Wenn überhaupt, dann benutze von vorneherein preg_match() und gebe dem Client
dann Auskunft darüber ob seine gewählten Benutzerdaten den Zeichenregeln entsprechen,
wenn nicht dann script abbrechen.
Die ganze replace geschichte ist sehr schwammig und sollte man wohl eher für Output benutzen
um gewisse Zeichen umzuwandeln.
Ausserdem solltest du von vorneherein dich mit
Prepared Statements beschäftigen,
denn diese sind grundlegend injectionsicher, egal welcher input vom User kommt.
Dabei muss dann allerdings auf den Output geachtet werden, willst du also später eine
Ausgabe der mit prepared statements hinterlegten Datensätze machen welche unter Umständen auch
HTML oder jeglichen anderen Code enthalten können, achte darauf das dieser "Output" dann dementsprechend
behandelt (bzw nicht behandelt) wird.
Gemeint ist damit, wenn du prepared statements benutzt, kann der Client theorethisch jeglichen kram
als Benutzernamen wählen (soweit nicht vorher behandelt) und dieser würde so wie er es eingegeben
hat als Datensatz in die DB eingetragen jedoch besteht keine möglichkeit die eigentliche Abfrage zu manipulieren
da diese bereits schon vorgefertigt im SQL Server auf die Benutzerwerte wartet.
Würde er nun z.B. als Benutzername <font color="red">HalloIchBins</font> benutzen, und du hättest Später
eine Seite auf der du den Benutzernamen z.B. per echo $username; ausgibst, dann würde auf dieser Seite
in Rot "HalloIchBins" stehen, das gleiche gilt für die weiterverarbeitung in weiteren scripten, auch dort würde exact
das benutzt, was in der DB hinterlegt wird und nutzt du dann an irgendeiner Stelle keine prepared statements mehr
ist die injection vorprogrammiert von daher ist dort sorgfalt angebracht.
Am besten du setzt dich mal 2 Stunden intensiv an die Suchmaschine und informierst dich näher über
die möglichkeiten von Prepared Statements, suchst dir Beispiele raus und wendest diese direkt an.
Replace funktionen sind jedenfalls zumindest für Registrierungseiten oder Loginformulare pfusch und sollten dort
nur bedingte Anwendung finden.
Eine weitere Alternative wären da noch
Stored Procedures,
auch diese sollten grundsätzlich injectionsicher sein.
