Hallo! Das replace(..., "'", "''") ist die EINZIGE wirksame Medizin gegen SQL-Injection, aber ...
> > > > Replace von Apostrophen ist kein Mittel zur Fehlerbehebung, sondern > zum > > Fehlerkaschieren. > > Das sehe ich anders... > Es macht genau das was parametrisierte Kommandos machen, nicht mehr und > nicht weniger... Es sorgt daf�r, dass der String ganz als String in der > Abfrage ankommt und nicht teilweise als SQL-Befehle interpretiert > wird.... ... warum das selber machen, wenn ADO das erledigt? Der elegantere Weg ist also der �ber ADO mit parametrisierten Befehlsabfragen bzw. Prozeduren und Methodenaufrufen. Jegliches Zusammenstellen eines SQL-Befehls in VBScript ist nicht nur gef�hrlich, sondern auch fehleranf�llig und nicht sehr performant. Naja, deshalb w�rde ich das "replace ..." trotzdem nicht als Fehlerkaschieren bezeichnen. Es ist einfach nur nicht konsequent. > > IsNumeric, IsDate - die Abh�ngigkeiten von der LocaleId haben wir > schon > > zur > > Gen�ge diskutiert. Auch das erledigt ADO: Man kann eine Zeichenkette als Parameter an ein Datumsfeld �bergeben und ADO wandelt den Wert korrekt um und zwar entsprechend dem Datenbankformat (darauf kommt es an, der SQL Server schert sich nicht um die LocaleId). Auch hier braucht es also kein VBScript. ADO reicht. > Soll das ein Gegenargument sein? > Wo ist der Unterschied zwischen > - <%@LCID=1031%> setzen und isDate verwenden > und > - Regular Expressions, die sich immer auf ein bestimmtes Format bezieht, > aber nicht mit dem austauschen einer Nummer umgestellt werden k�nnen > verwenden? > > isDate zeigt auch bei nicht existierendem Datum(z.B. 29.02.2001) einen > Fehler an, wovon man bei RE nur tr�umen kann... > Ich verstehe also Deine Argumente nicht... Die Regular Expressions sind eine tolle M�glichkeit zur Validierung. Ich setze sie sowohl im Browser als auch auf dem Server ein. Der Hauptschutz gegen SQL Injection ist aber konsequenter Einsatz von ADO, also StoredProcedures mit Parametern. Regular Expressions helfen dem Anwender am Client, m�ssen aber im Hinblick auf die Sicherheit auch immer am Server ausgef�hrt werden. Bis vor kurzem hatte ich noch ein "<input type=hidden ...>" in den Formularen, um Anzuzeigen, ob die Daten clientseitig mit JavaScript/Regular Expressions validiert wurden. Die Pr�fung auf dem Server habe ich mir gespart, wenn sie bereits auf dem Client erfolgt ist. Inzwischen werden die Daten immer zus�tzlich auf dem Server mit der gleichen Regular Expression wie im Client validiert. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
