FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Sanitising input
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Sanitising input [message #172117 is a reply to message #172115] Mon, 31 January 2011 04:12 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 1/30/2011 10:43 PM, Ross McKay wrote:
> On Sun, 30 Jan 2011 16:50:15 -0500, Jerry Stuckle wrote:
>
>> No, that is not the "only way".
>
> Sure, but I reckon it's the OP's best bet (as I stated).
>
>> First of all, it is necessary to include outside data. How, for
>> instance, are you going to get the customer's name if you don't allow
>> outside data?
>
> There is absolutely no need to include "outside data" in an SQL query.
> You can have placeholders in the query and use a prepared statement,
> which is what http://bobby-tables.com/ is advocating.
>
>> And properly escaping strings protects against attacks just as well as
>> using parameterized statements does.
>
> Absolutely, when done correctly, and never omitted when required, and...
> or you can just follow a policy of using prepared statements to present
> varying and user-submitted data to the database. I reckon the OP wants
> to know how not to shoot him/herself in the foot, and I reckon prepared
> statements is the easiest way to prevent that shot.
>
> And when it comes to PHP and its myriad ways to submit queries to the
> different databases, I personally prefer to use something like PDO that
> presents a largely consistent interface for doing that across the
> different databases.
>
> Utilising prepared statements is similar enough across PHP/PDO, ADO,
> Java, and .NET that one only needs to understand the basics of using
> prepared statements to be capable of writing safe database code on each
> of those platforms.
>
> No need to remember that mysql_escape_string() is damaged and that
> mysql_real_escape_string() is the safe one, as compared to
> mysqli_escape_string() which is safe because it's an alias of
> mysqli_real_escape_string(), and that pg_escape_string() is safe and
> there isn't a pg_real_escape_string(), and that you might need to use
> addslashes() for an ODBC database connection e.g. to Access or MSSQL,
> etc.
>
> Albeit if using PDO, you can probably use the quote() function on the
> connection for many databases (but not ODBC connections), and not be
> concerned about such guff... but even the manual page for that function
> advises the use of prepared statements instead:
>
> http://au2.php.net/manual/en/pdo.quote.php
>
> Once the OP becomes expert, they can happily seek out the use-case
> appropriate escaping mechanism if they want. But the simple answer to
> the OP is for databases, just use prepared statements and you won't come
> unstuck.

Except there is a tremendous amount of overhead in PDO - I've had two
sites I have had to rewrite without it to get respectable performance.

And bound parameters are not without their own overhead, either.

Not to say you shouldn't use PDO or bound parameters - they have their
uses. But a good programmer understands the different ways of doing
things and the advantages and disadvantages of each, instead of just
saying "this is the best way for you". It may or may not be the "best
way".

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Only SPAM!!!
Next Topic: What *tasks* are hard for PHP?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Nov 27 02:48:37 GMT 2024

Total time taken to generate the page: 0.05066 seconds