sql := "UPDATE tpages SET content='"+@Abstract([Abbrev];7900;"";body)+"' WHERE exlink='"+@Text(@DocumentUniqueID)+"'";
Danke für die sehr detaillierte Hilfe.
Ein bischen eine andere Frage (hoffe das wird nicht als Thread-Hijacking angesehen).
Ist das wirklich sicher.
Bin nicht wirklich ein SQL Guru, aber kann ein böser Mensch nicht vielleicht über bestimmte klevere Zeichen-Kombinationen Dinge in der Datenbank anrichten, die der Programmierer nicht will?
z.B. in das Textfeld:
"*"; UPDATE tpages SET content="**"
Der SQL Befehl könnte dann heissen:
UPDATE tpages SET content="*";
UPDATE tpages SET content="**" WHERE exlink="432234def8347598732";
Der content-Wert wäre dann * in fast allen Tupeln ausser in einer und dort "**".
Wie gesagt. Kann mich irren, ob das so wirklich funktioniert, habe ich nicht getestet.
Jedenfalls gibt es Situationen, wo RDBMS SQL Statements aus einem Programm so manipuliert werden können.
In JDBC gibt es sowas wie Prepared Statements, wo man sich davor schützen kann. Gibt es das in ODBC nicht?
Gruß Axel
Das Ganze läßt sich halt nur verhindern, wenn man solche Abfragen, bzw. die Argumente, die ermittelt werden, vorher genau überprüft.
In JDBC gibt es sowas wie PreparedStatements. Quasi präkompiliertes SQL.
http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html
Da gibt es dieses low-level Probleme nicht.
z.B:
1 PreparedStatement updateSales = con.prepareStatement(
"UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ? ");
2 updateSales.setInt(1, 75);
3 updateSales.setString(2, "Colombian");
4 updateSales.executeUpdate():
Selbst wenn man jetzt statt Zeile 3 sagen würde:
updateSales.setString(2, "\"Colombian\"; UPDATE COFFEES SET SALES =\"Colombian\");
würde das in der Runtime nicht akzeptiert.
Datenbank APIs auf noch höheren Level wie Hibernate, Entity EJB, JDO, iBatis, uvam sind auch gegen solche Zugriffe vom Framework aus geschützt.
Existiert in ODBC wirklich nicht sowas wie Prepared Statements?
Axel