On the pro side for quoting int types it would stop the 1=1 type injections. But at the same time these could be filtered out on the PHP side if we know the column needs to be an int.
I actually rely on that syntax for finding bugs during dev. If I end up with a 1= in my query, I get an error and know something is wrong. We go to a lot of trouble to ensure we use that syntax.
To be honest, that is not the only problem, I've seen SQL injection on the table names too. A true processor for this would be able to replace table and column names correctly.
++ yes. If you have tables partitioned by date and have to build a table name from get vars, you could write bad code that relied too much on user input. I always run date vars through date(FORMAT, strotime(input)) to be sure I get a sane date format. But, the 19 yr old kid learning to program won't. I know I didn't in the 90s.
2. Have a NoSQL, OO type interface too (hard to SQL inject when there is no SQL). I'm thinking similar to NDBAPI but maybe a bit more human-friendly.
I think getting HandlerSocket, or something like it in the drizzle interface would be great.
3. Make the PHP module use the SELECT EXECUTE() syntax with user vars for prepared statements. I'm not sure if you can inject using that, will have to play, if you can it shouldn't be too hard to make a safer version of it.
I don't know this syntax. link? Brian. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
