>Your code is proving that macrosubstitution cannot execute multiple lines of >code. As long as you execute commands on VFP data AND the literal value does >not implies multiple lines that's ok.
Right, which in turn proves that if you use macro substitution to execute concatenated SQL statements in VFP, you cannot construct a statement that can damage your data. Which in turn supports my contention that one size does not fit all when it comes to effective secure code--a contention that was already supported when I demonstrated that use of ? parameters for SQL only makes sense in monolithic apps. >"Select * From Users where username = '" + varUsername + "' And password = '>" + varPassword + "'" >Let's suppose the user enters [admin' &&] as username (drop the brackets,> I've put them just to isolate the string in this text). Not sure where you're going with that. You can't concatenate anything containing "&&" to a string in VFP. That surprised me, frankly, but you can't. It won't work; you'll get "Command contains unrecognized phrase/keyword": myvar = "Select * From Users where username = '" && ok myvar = myvar + "admin' &&" && Error! myvar = myvar + "admin'" && ok myvar = myvar + " &&" && Error! myvar = "" && ok myvar = myvar + "&&" && Error! Also, it's insane to let users construct their own SQL commands, or to allow them to select a table like "users" or a field like "password" from a list of things that can be returned to them. So the example is not going to occur in the wild unless the application was written by an idiot. When users log into my app, they fill in blanks for username and password, and the app executes: "SELECT userid FROM users WHERE login == '" + mylogin + "' AND password == '" + mypassword "'" The user doesn't see the results of this; the app uses the userid value internally to determine what things the user can access. If the user inserts CHR(0) or something else into the login, it just won't match anything in the users table and s/he won't get in. That's it; end of story. I'm not arguing that SQL injection doesn't happen. I'm arguing that use of ? parameters is not a viable solution in all situations, and is not necessary in many situations. I am arguing, instead, that if you do not let users insert SQL command terms into an expression, by controlling the tables the user can query and the fields that can be returned, and by validating what they do enter, at the GUI or business object level, then you can be secure without ever using a single ?, which means you don't have to bend your design out of shape in order to be in a position to use ? parameters. There are no panaceas in life, or in programming. There are no "best practices" that are not less than best in at least some situations. Flexibility and creativity are to be valued. That is the general argument I am making; use of ? parameters is just one of many millions of examples where my argument holds true. Ken Dibble www.stic-cil.org _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
