Announcement

Collapse
No announcement yet.

Field Protection Option

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mistergrey
    replied
    Originally posted by sawjer View Post
    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

    Leave a comment:


  • sawjer
    replied
    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

    Leave a comment:


  • mistergrey
    replied
    Originally posted by sawjer View Post
    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.

    Leave a comment:


  • sawjer
    replied
    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!

    Leave a comment:


  • mistergrey
    replied
    Hi.. Late reply.. I mean protect option for all applicable fields to prevent execution of scripts/ code from fields especially in form fields..

    Leave a comment:


  • tfertil
    replied
    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?

    Leave a comment:


  • mistergrey
    started a topic Field Protection Option

    Field Protection Option

    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?
Working...
X