Scriptcase has sc_sql_injection() macro to protect a field from code injection attacks. However, it is quite a job to use the said macro for each of the fields to fully protect an application. Why not just have a PROTECT OPTION to each field in its properties that can be enabled/disabled as necessary?
Hi Mistergrey,
From the Macros documentation: Note: that all database accesses, generated for the Scriptcase, have protection against “sql injection”.
So IMHO sc_sql_injection is to protect the SQL sentences that you create using input from the user, not the ones ScriptCase generates to load/update/insert/delete. Is this what you mean?
Hi… Late reply… I mean protect option for all applicable fields to prevent execution of scripts/ code from fields especially in form fields…
Hi
How can scriptcase find out, if an entry is for the database? Does it understand when the input is passed to a local variable and this local variable is then used in a sql statement.
With the above information alone, it is unclear if criptcase can in all possible situations automaticaly add sql injection. More clarification is welcome!
Hi,
I think SC knows if a field entry is for database or not. If you will create a form app based on a table, SC will create a form app with fields that correspond to the columns in the database. This is also evident when you sync a form app with its database table. if you want to add a field to a form that has no corresponding column in the database table, it would appear differently compared with the other fields that have corresponding columns in the database table.
Thank you MrGrey
If I understand you correctly:
All entries that are entered into a virtual field (a field that is added with “add Field”) must have an explicit sql injection added, as scriptcase has no direct knowledge to what db table it belongs
Hi,
No not the virtual field (a field that is added with “add Field”). It’s the actual field (a field with a corresponding column in a database table) that should have an explicit sql injection added