SQL Injection Protection

Protect your website in case someone attempts to hack them using the macro sc_sql_injection().
It implements SQL Injection Protection code in Scriptcase text boxes.

http://downloads.scriptcase.net/downloads/v5/manual/en_us/webhelp/manual_mp/80-Apendice/08-Programacao/01-Macro_sc/00-macros_sc.htm#sc_sql_injection

sc_sql_injection (field/variable)

Protects the field/variable against “sql injection”.

Macro used for protection against “sql injection” in commands generated by the developer (macros: sc_lookup, sc_select or sc_exec_sql).

Note that all database accesses, generated for the Scriptcase, have protection against “sql injection”.

Ex1: Protecting a local variable:
$field_protect = sc_sql_injection({my_field});

Ex2: Protecting an user variable:
$field_protect = sc_sql_injection($my_var);

Re: SQL Injection Protection

http://downloads.scriptcase.net/downloads/v5/manual/en_us/webhelp/manual_mp/28-Macros/00-macros_sc.htm#sc_sql_injection

Re: SQL Injection Protection

I don’t know what you mean that the Update side is “done directly with DB (not using SQL statements)” – I guess you mean that you are using prepared statements, since I doubt you are getting low-level access to the MySQL storage engine via ODBC! Anyway, I do see that you are escaping strings on the Update side. That’s great, but that’s half the battle. Imagine if someone can arbitrarily inject SQL into the lookup side to read records they shouldn’t read, then the result gets either sent back to them via SMTP or written to a customer db record that they can access.

Having separate user with limited privileges is a common practice. But even if you will have such a user, it won’t protect you from SQL injection attacks.