Dass Benutzereingaben kontrolliert und gefiltert werden müssen ist nicht neu. Machen wir bei allen unseren Scripten so. Meistens werden die Daten bei der Ausgabe an den Browser mit Hilfe von htmlentities() "gesichert". Alles, was möglich ist, wird dabei in HTML-Entities umgewandelt. > wird zu >, " wird zu ", und so weiter.
Als wir das Kommentar-Script seinerzeit entwickelten, haben wir die Umwandlung an den Anfang gesetzt - die Daten kamen so schon konvertiert in der Datenbank an. Irgendwann zwischen damals und heute haben wir htmlentities() durch strip_tags() ausgetauscht. Warum, weiß keiner mehr so genau. Normalerweise verwenden wir eine Kombination aus beiden Funktionen, um ganz sicher zu gehen.
strip_tags() allein zu verwenden, sollte sich als großer Fehler herausstellen. strip_tags() entfernt, wie der Name schon sagt, HTML-Tags und auch PHP-Tags. Alles andere - JavaScript-Code oder CSS-Styles zum Beispiel - bleibt bestehen. Resultat war, dass Nutzer sich bei uns meldeten. Hacker hätten Code eingeschleust und die gesamte Seite zu einem Link gemacht. Über den Admin-Bereich konnte der Kommentar noch nicht einmal gelöscht werden, da das Script gar nicht mehr auf die anderen Links reagierte.
Das Update und Veröffentlichung im Forum war schnell erledigt. Schließlich haben wir ja schon Erfahrung damit. 
Allerdings setze ich normalerweise html_entities erst bei der Ausgabe ein, und nur das notwendige mysql_escape_string zu Beginn, vor dem Speichern in der DB.
> vor der Eingabe in die SQL-Datenbank
> (z.B. mysql_escape_string)?
Nein, soll es nicht.
Die Prämisse war und ist, von vornherein jeden Schnipsel HTML-Code zu entfernen. Das ist möglicherweise etwas zu restriktiv, aber aufweichen kann man das immer noch.
> Codeschnipseln ist es recht praktisch wenn die
> Benutzer auch dementsprechende Zeichen verwenden
> können.
Yep, es wird der Zeitpunkt kommen, an dem genau das ein Problem hier sein wird. Zwar nur ein kleines, aber immerhin.