4 ms·

I have to second prepared statements. You wont have to change your code too much to use them and they are way too important not to use. They can even lead to sp

I have to second prepared statements. You wont have to change your code too much to use them and they are way too important not to use. They can even lead to speedups if you're going to reuse queries.

iSloth 15y ago
The errors shown on the site was actually from a misguided hack I performed to log all search variables into a database, unfortunately I forgot to apply the correct SQL protection techniques that I normally do throughout the rest of the site and created the vulnerability slaps self on head. Apologies for the confusion I am not actually using a SQL cleaner, in-fact with brutal honesty I don’t actually know what one is. I was using the term to reference my usual methods/techniques for keeping SQL ‘clean’ from injection attempts. I am fairly happy with my current SQL setup and the way it protects from injection, obviously when I code it correctly, however I will certainty look into using fully prepared SQL, currently I do something ‘similar’ using my objects so it would probably be very easy to implement. Thanks for all of the feedback so far and pointing out the flaws, in fact the logs I have gotten from people ‘testing’ my SQL protection has helped a lot!
- eropple 15y ago
  I am fairly happy with my current SQL setup and the way it protects from injection In all seriousness: you shouldn't be, because it clearly doesn't protect in all cases. ("Failed to wrap a query in a magic function to make it sort of safe" is part of "all cases.") You have demonstrated, by neglecting to use your "correct SQL protection techniques," why non-prepared statements are absolutely terrible. You cannot have the error you just did if you train yourself not to use direct SQL queries, regardless of library. Querying via MDB2 or PDO (or doctrine-dbal, which is a superset of PDO) means you have to intentionally and willfully do something very out-of-the-ordinary to pass in raw data as a SQL query, instead of being forced to wrap your queries in some slipshod, maybe-works-maybe-doesn't homegrown function that has not been rigorously tested. Don't reinvent the wheel. Safe SQL queries are a solved problem.
  - iSloth 15y ago
    I do agree that I should consider implementing none direct SQL, however I am 'faily happy' with my current set-up as it does work and protect (when used correctly). I will certainly look at none direct SQL, however I just don't feel it's my number 1 priority at the moment, especially when the template isn't even rendering in some browsers.

iSloth 15y ago

The errors shown on the site was actually from a misguided hack I performed to log all search variables into a database, unfortunately I forgot to apply the correct SQL protection techniques that I normally do throughout the rest of the site and created the vulnerability slaps self on head. Apologies for the confusion I am not actually using a SQL cleaner, in-fact with brutal honesty I don’t actually know what one is. I was using the term to reference my usual methods/techniques for keeping SQL ‘clean’ from injection attempts. I am fairly happy with my current SQL setup and the way it protects from injection, obviously when I code it correctly, however I will certainty look into using fully prepared SQL, currently I do something ‘similar’ using my objects so it would probably be very easy to implement. Thanks for all of the feedback so far and pointing out the flaws, in fact the logs I have gotten from people ‘testing’ my SQL protection has helped a lot!

eropple 15y ago
I am fairly happy with my current SQL setup and the way it protects from injection In all seriousness: you shouldn't be, because it clearly doesn't protect in all cases. ("Failed to wrap a query in a magic function to make it sort of safe" is part of "all cases.") You have demonstrated, by neglecting to use your "correct SQL protection techniques," why non-prepared statements are absolutely terrible. You cannot have the error you just did if you train yourself not to use direct SQL queries, regardless of library. Querying via MDB2 or PDO (or doctrine-dbal, which is a superset of PDO) means you have to intentionally and willfully do something very out-of-the-ordinary to pass in raw data as a SQL query, instead of being forced to wrap your queries in some slipshod, maybe-works-maybe-doesn't homegrown function that has not been rigorously tested. Don't reinvent the wheel. Safe SQL queries are a solved problem.
- iSloth 15y ago
  I do agree that I should consider implementing none direct SQL, however I am 'faily happy' with my current set-up as it does work and protect (when used correctly). I will certainly look at none direct SQL, however I just don't feel it's my number 1 priority at the moment, especially when the template isn't even rendering in some browsers.