Tach!
Validierung sollte sich auf die Geschäftslogik beschränken und ist damit nicht sicherheitsrelevant. Wichtiger hingegen ist ...
... nicht nur SQL-Injection zu beachten, sondern den Kontextwechsel generell - in allen, auch anderen Situationen. Code und Daten zu mischen ist in sehr vielen Systemen die Art und Weise, wie sie funktionieren. Programmiersprachen mit eingebetteten String, HTML-Code mit auszugebendem Text, Trennzeichen in Datendateien, alles was mehr ist als nackiger Text. Es darf beim Einfügen von Daten in Code keine Syntaxfehler geben, weil irgendwelche Sonderzeichen nicht korrekt maskiert wurden. Die Injection-Verhinderung ist dabei nur eine Nebenwirkung. Einige denken sich "Sicherheit mach ich später", aber das ist der falsche Ansatz. Das Hauptaugenmerk sollte sein, das Programm fehlerfrei zu gestalten, so dass auch nicht als Angriff gedachte Daten kontextgerecht ausgegeben werden.
Wo tun sich pauschal gesagt weitere Angriffsmethoden und Wegw auf die man als "PHP-Entwichler" schließen kann?
Alles was interne Daten sind, auf die nicht direkt zugegriffen werden soll, sollten sich außerhalb des Documentroot befinden. Konfigurationsdaten, Temp-Verzeichnisse, Log-Verzeichnisse, gegebenenfalls Upload-Verzeichnisse. Leider ist bei zu billigen Hostern keine Möglichkeit vorhanden, neben dem Documentroot Verzeichnisse anzulegen, oder der Vorgang ist für das Zielpublikum zu kompliziert. Deswegen werden die Systeme gern so aufgesetzt, dass ein einfaches Uploaden reicht - alles ins selbe Verzeichnis. Das hat dann den erwähnten Nachteil dass nichtöffentliche Verzeichnisse trotzdem öffentlich sind. Mitunter wird dann auch gern vergessen, in Temp- und Upload-Verzeichnissen das Ausführen von PHP-Dateien (und was der Hoster sonst noch ausführbar gemacht hat) zu untersagen, und die Angreifer können sich dann ihr eigenes Script hochladen und ausführen.
dedlfix.