-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
SQL Injection -- prevention.
- Thread starter Al Neri
- Start date
http://en.wikibooks.org/wiki/Programming😛HP:SQL_Injection
imported_quasi
Member
I've read that generally speaking, placeholders are the best way to avoid injection attacks. Then again, it depends on the language you're using and such. If you're using Perl, I would use placeholders. I'm not sure PHP supports them, but it does have built-in quoting functions that are your best bet.
The Wikipedia article is actually a solid reference: http://en.wikipedia.org/wiki/SQL_injection
It has solutions for most languages you'd be using a DB with.
The Wikipedia article is actually a solid reference: http://en.wikipedia.org/wiki/SQL_injection
It has solutions for most languages you'd be using a DB with.
I think he must be using a regex and that's probably safe enough, but call me paranoid, I just don't like unknown input going into my db without using a prepared statement or the escape_string function. Besides, if in the future he decides to allow quotes to be included in the jokes, he doesn't have to worry about remembering to fix his input sanitation.
Prepared statements and stored procedures are your friend.
You'd write your SQL like "SELECT Widget FROM Gizmos WHERE WidgetID = ? AND Price < ?" and then pass your parameters in using your DB's parameter interface.
If you prefer to make dynamic SQL in real time, and are willing to accept the massive performance hit, then you should take care to escape any user input in the way prescribed by your DB. The classic way of doing this in MySQL is using mysql_real_escape_string. Although, there is some evidence that this does not provide complete protection, as it doesn't properly handle extended character sets.
You'd write your SQL like "SELECT Widget FROM Gizmos WHERE WidgetID = ? AND Price < ?" and then pass your parameters in using your DB's parameter interface.
If you prefer to make dynamic SQL in real time, and are willing to accept the massive performance hit, then you should take care to escape any user input in the way prescribed by your DB. The classic way of doing this in MySQL is using mysql_real_escape_string. Although, there is some evidence that this does not provide complete protection, as it doesn't properly handle extended character sets.
imported_LoKe
Lifer
He's kinda right. I've seen a few websites use Javascript on the form itself to allow only certain characters. All you'd have to do is make your own and do http://site.com/target.php and input your values that way.
Hopefully, that javascript is just an aid to be sure the average user is putting in the correct info and real validation goes on server side. I mean you're doing the same thing using just combo boxes and restricting input to selectable options, but that doesn't mean it's worth a damn for validation. I would hope the javascript is being used for the same sort of purpose.
imported_LoKe
Lifer
You'd be surprised how common it is.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
