>> > That said, I would recommend binding parameters if you can. It's a >> > cleaner way of separating the logic of a query from its data, and >> > theoretically more reliable than mysql_real_escape_string(): >> > >> > http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements >> > >> >> I fail to understand what is happening here. For the sake of context, >> here is the PHP code in TFA: >> $db = new PDO('pgsql:dbname=database'); >> $stmt = $db->prepare("SELECT priv FROM testUsers WHERE >> username=:username AND password=:password"); >> $stmt->bindParam(':username', $user); >> $stmt->bindParam(':password', $pass); >> $stmt->execute(); >> >> What exactly does bindParam do? I read these pages in TFM but I still >> do not understand what exactly is being sent to the database: >> http://il2.php.net/manual/en/function.db2-bind-param.php >> http://il2.php.net/manual/en/function.maxdb-stmt-bind-param.php >> http://il2.php.net/manual/en/mysqli-stmt.bind-param.php >> >> I do not see how there could possibly be a prepared statement for a >> user comment. I am not a programmer by trade, so I may be missing >> something obvious. If so, a link and a friendly RTFM would be great. > > Typically, prepared statements do a couple of things. First, they ensure > that values sent to the DBMS are properly "quoted". You'd be surprised > how difficult a problem that is. Date and string values must be > surrounded by quotes, but numerics shouldn't be. And how they're quoted > depends on the DBMS you're using. So prepared statements take care of > this for you. > Apparently, I missunderstood the meaning of the term "prepared statements". I thought that it meant using values that only came from my code, and no user-entered values. For instance, if the user had to choose between the windows, linux, and mac forums, the code would look like this: switch ($userForum){ case (linux): $sqlForum="linux"; break; case (windows): $sqlForum="windows"; break; case (mac): $sqlForum="mac"; break; This is what I currently do. However, that approach would not work for comments. > The second thing they do is examine the values you're attempting to pass > into the database, and ensure they don't contain SQL injection type > code. This is hard to explain, but it's relatively simple to insert > "code" in place of an actual value, and do malicious things to your > database, or obtain information you don't want users to see (like credit > card numbers). If you're curious, search for "SQL injection" to get more > information and see examples. > I am familiar with SQL injection, I wrote about it here: http://what-is-what.com/what_is/sql_injection.html -- Dotan Cohen http://what-is-what.com http://gibberish.co.il -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
