OK, I think I follow that but I'm away from the project at the moment and won't get to try it out until later in the week.
I can see a couple of issues. Can probably work around them but would appreciate your thoughts.
1. Indeterminate number of fields - Not only do I not know the nature of the fields at design time, I don't know the number either. So I can't use a static quantity of 3. I think I could get around this with an extra abstraction - e.g. storing them as rows in a column and then pivoting them. Or I could have a create statement to create the basic table (the ID field is ALWAYS present so it could just create the table with that single column) and then a series of alter statements to create the dynamic fields as subsequent operations using something similar to your update statement - except an Alter Add Column.
2. Does this actually prevent injection? (Might be better taking this one to the pms) but couldn't a hacker inject an attack into the values held in tlbUpdate. E.g. an attack into the RowParam field. Ultimately the sql statement is still be produced by concatenation in the Generated SqlString column so I think it's still vulnerable. I'm likely missing a trick there though.
Edit> Also, take a look at my challenge in post 5. I think that might be good enough but I know that, if anyone can inject an attack into it, you can. Obviously, pm me a successful attack - don't post it in the main forum.
Reply With Quote