On Mon, 16 Jan 2012 19:34:09 -0800, Haluk Karamete wrote: >I understand some ways are better than others in this one, and it >looks like the PDO based implementations shine the most as far as SQL >Injection. PDO is one way (and happens to be the one I prefer), but there are others. Essentially, you are best validating your inputs (always!) and then using prepared statements where possible. See here for some options: http://bobby-tables.com/php.html >But would not the following be good enough - without implementing a >PDO solution? >[...] You should always validate your inputs anyway, but whereas a "PDO solution" (by which I infer you mean using prepared statements) is safest simply because it forces you to use safe practices, you can still build safe SQL statements by using mysql(i)_real_escape_string(). Equally, you can bollocks up a prepared statement by building it with string appends for some parameters that should instead be bound. Use common sense, use the appropriate tool for the job, but err on the side of caution and use prepared statements in preference to dynamic SQL where appropriate. (And where I need to use dynamic SQL, e.g. some searches, I often do so by building sets of parameters to apply to the prepared statement for the dynamic SQL) >[...] >4- check the magic_quotes_gpc and do the stripslashes and then the >mysqli_real_escape_string() and the htmlentities. htmlentities() and htmlspecialchars() are for writing safe HTML, and are not concerned with SQL injection. You should use them, but only when writing output to HTML (e.g. don't use them for plain text or XML) and certainly they have no place in writing to a database except in specific circumstances (like where you're storing HTML in the database, not text). >5- and on top pf all this, I also check for the specific occurrences >of these following words; if any exist, I just do not execute that SQL >query. > and that list is >sysobjects, >syscolumns, >systypes, >EXEC(@, >CHAR(, >exec%20, >DECLARE%20@, >wscript. >CAST( >CONVERT( A nice-to-have if you're going to try to detect an attack, but otherwise not required if you have the bases covered with prepared statements or properly escaped data. Realise that this is a short list and incomplete, and can never be complete. I would not rely on it to safe-guard anything; it can only be used as an indication of a *possible* attack (but it will also prevent someone submitting perfectly good code to a forum, for example). >[...] >These may raise a false negative on some valid user input that's >coming from a textarea where the data type is string, and an accepted >char length is big enough to create some havoc in the db, so be it, I >reject that input. Which may be fine in your application, but why stop legitimate data for no good reason? >My question even after all these are there still ways to break in? >[...] Yes :) -- Ross McKay, Toronto, NSW Australia "Pay no attention to that man behind the curtain" - Wizard of Oz -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
