Tach!
Und das heißt eben daß ein per HTTP eingereichtes Statement schon aus der Kontrollstruktur herausfallen muss und gar nicht erst am DB-Server ankommen darf.
Das würde bedeuten, dass man erst noch einen SQL-Parser schreiben müsste, um den ankommenden Wert als SQL-Statement-Teil zu erkennen. Das wäre zu viel Aufwand.
Für mich gibt es zwei generelle Lösungswege. Der eine wäre das Prüfen der Parameter auf fachlich gültige Werte. Das geht bei Sprachen und anderen Arten von Daten noch recht gut, wenn diese in der Anwendung einen festgelegten Werteumfang haben, gegen den man prüfen kann. Musterprüfungen und Prüfungen auf Datentyp oder andere konkret formulierbare Kriterien sind da inbegriffen. Bei freien Eingaben, zum Beispiel wenn nach beliebigen Suchbegriffen gesucht werden können soll, kann man eine Prüfung nur beschränkt vornehmen, wenn überhaupt. Da bleibt dann als zweite Variante, dass man sich nur auf die korrekte Maskierung (oder Prepared Statement) verlässt. Die Abfrage wird dann syntaktisch einwandfrei durchlaufen und nur kein (gescheites) Ergebnis liefern. Aber daran war der Angreifer ja sowieso nicht interessiert.
Vielmehr muss das Statement auf dem Server liegen und wird allenfalls mit Platzhaltern gefüttert die diesem Kontext entsprechend geprüft und behandelt wurden.
Ja, so war das ja auch vorgesehen. Angriffe halten sich aber nicht daran und probieren es trotzdem mit Statementbestandteilen über reguläre Parameter.
dedlfix.